Playing with proot and cross builds

[Joakim Tjernlund]

Just tried to map in my Gentoo cross ppc toolchain into proot:

## cd to root FS of Gentoo ppc stage 3
cp /etc/env.d/05gcc-powerpc-g2.19-linux-gnu etc/env.d/
cp /etc/env.d/gcc/config-powerpc-g2.19-linux-gnu etc/env.d/gcc
cp /etc/env.d/gcc/powerpc-g2.19-linux-gnu-4.8.4 etc/env.d/gcc
cp /etc/env.d/binutils/powerpc-g2.19-linux-gnu-2.24 etc/env.d/binutils/
cp /etc/env.d/binutils/config-powerpc-g2.19-linux-gnu etc/env.d/binutils/
ln -s / /usr/powerpc-g2.19-linux-gnu

proot -S $PWD -q qemu-ppc -b /bin/bash -b /usr/x86_64-pc-linux-gnu/powerpc-g2.19-linux-gnu/ -b
/usr/lib64/binutils/powerpc-g2.19-linux-gnu/ -b /usr/libexec/gcc/powerpc-g2.19-linux-gnu -b
/usr/lib/gcc/powerpc-g2.19-linux-gnu /bin/bash

Now I can build hello world with my cross gcc inside proot:
# > powerpc-g2.19-linux-gnu-gcc tst.c
# > ./a.out
Hello world!

Not sure this will lead to anything though

Jocke

PS:
Is there a mail archive somewhere?

[Sergii Pylypenko]

Mail archives are here: https://groups.google.com/forum/#!forum/proot_me

--

---
You received this message because you are subscribed to the Google Groups "PRoot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proot_me+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cdc]

Well, this can lead you far :) Some of my team-mates use PRoot this
way to build dozens of packages. IIRC, the setup for g++ requires
2-or-3 more bindings.


> Jocke

Thanks for having shared this setup.
Cédric.

[cdc]

On Fri, May 29, 2015 at 04:43:28PM +0200, cdc wrote:
> > Now I can build hello world with my cross gcc inside proot:
> > # > powerpc-g2.19-linux-gnu-gcc tst.c
> > # > ./a.out
> > Hello world!
> >
> > Not sure this will lead to anything though
>
> Well, this can lead you far :) Some of my team-mates use PRoot this
> way to build dozens of packages. IIRC, the setup for g++ requires
> 2-or-3 more bindings.

Something came back to my mind: they also bind all binaries from /bin
but "uname". This typically improves extract/configure/archive
performance a lot.

[Joakim Tjernlund]

On Fri, 2015-05-29 at 16:46 +0200, cdc wrote:
> On Fri, May 29, 2015 at 04:43:28PM +0200, cdc wrote:
> > > Now I can build hello world with my cross gcc inside proot:
> > > # > powerpc-g2.19-linux-gnu-gcc tst.c
> > > # > ./a.out
> > > Hello world!
> > >
> > > Not sure this will lead to anything though
> >
> > Well, this can lead you far :) Some of my team-mates use PRoot this
> > way to build dozens of packages. IIRC, the setup for g++ requires
> > 2-or-3 more bindings.

:) I sent this because I think this can be very useful. I think you should add
such examples to the web page so people catch on.

>
> Something came back to my mind: they also bind all binaries from /bin
> but "uname". This typically improves extract/configure/archive
> performance a lot.

Ah, I will try that. But wait, what if you install new progs into /bin then ?
Perhaps they set ROOT=/somewhereelse ?

Would be great if you could share the g++ bindings too:)
What about perl and python ? Can they be bound too so autotools/emerge go faster?

Instead of
ln -s / /usr/powerpc-g2.19-linux-gnu
I tried passing -b /usr/powerpc-g2.19-linux-gnu/:/ but that confuse proot, should it?

[cdc]

On Fri, May 29, 2015 at 02:52:50PM +0000, Joakim Tjernlund wrote:
> Ah, I will try that. But wait, what if you install new progs into /bin then ?

Note: usually, I assume PRoot is *not* running as *real* root, which
is the recommended way.

Regarding your first question; this will fail and report a "permission
denied" error. For example:

user@host-shell$ proot -b /bin/true -q [...]
user@guest-shell$ cp whatever /bin/true
cp: cannot create regular file ‘/bin/true’: Permission denied

even when faking root privileges:

user@host-shell$ proot -b /bin/true -q [...] -0
root@guest-shell# cp whatever /bin/true
cp: cannot create regular file ‘/bin/true’: Permission denied

So no worry for the host system. By the way, files created for
packages are usually installed in a temporary directory.

> Perhaps they set ROOT=/somewhereelse ?

Yes (ex. RPM_BUILD_ROOT for RPM).

> Would be great if you could share the g++ bindings too:)

I can't find the script that contains these bindings anymore. Anyway
you should be able to deduce them before I get my hands on this lost
script :)

> What about perl and python ? Can they be bound too so autotools/emerge go faster?

That's a good idea (I tested something like that with success a long
time ago), and it is quite easy:

proot -b $(which perl) $(perl -e 'foreach (@INC) { print " -b $_" }') [...]

> Instead of
> ln -s / /usr/powerpc-g2.19-linux-gnu
> I tried passing -b /usr/powerpc-g2.19-linux-gnu/:/ but that confuse proot, should it?

As of my understanding your guest rootfs lies in
"/usr/powerpc-g2.19-linux-gnu" too (from the host point-of-view), and
you have to do such a link because croos-tools use a hard-coded
sysroot ("/usr/powerpc-g2.19-linux-gnu"). There are two solutions:

- either specify --sysroot=/ to cross-tools (compiler, linker, ...)

- or bind "/usr/powerpc-g2.19-linux-gnu/" exactly to the same
location, ie: "-b /usr/powerpc-g2.19-linux-gnu/"

Note: technically "-b /usr/powerpc-g2.19-linux-gnu/:/ is exactly the
same as "-r /usr/powerpc-g2.19-linux-gnu/", so maybe the
confusion is expected ;)

Cédric.

[Joakim Tjernlund]

On Fri, 2015-05-29 at 19:22 +0200, cdc wrote:
> On Fri, May 29, 2015 at 02:52:50PM +0000, Joakim Tjernlund wrote:
> >
> > What about perl and python ? Can they be bound too so autotools/emerge go faster?
>
> That's a good idea (I tested something like that with success a long
> time ago), and it is quite easy:
>
> proot -b $(which perl) $(perl -e 'foreach (@INC) { print " -b $_" }') [...]

Nice :)

>
>
> > Instead of
> > ln -s / /usr/powerpc-g2.19-linux-gnu
> > I tried passing -b /usr/powerpc-g2.19-linux-gnu/:/ but that confuse proot, should it?
>
> As of my understanding your guest rootfs lies in
> "/usr/powerpc-g2.19-linux-gnu" too (from the host point-of-view), and
> you have to do such a link because croos-tools use a hard-coded
> sysroot ("/usr/powerpc-g2.19-linux-gnu"). There are two solutions:
>
> - either specify --sysroot=/ to cross-tools (compiler, linker, ...)

Passing --sysroot does not always work as som pkgs kills CFLAGS etc.
it is way better to remap sysroot(/usr/powerpc-g2.19-linux-gnu) to some other
dir where you currently build.

>
> - or bind "/usr/powerpc-g2.19-linux-gnu/" exactly to the same
> location, ie: "-b /usr/powerpc-g2.19-linux-gnu/"
>
> Note: technically "-b /usr/powerpc-g2.19-linux-gnu/:/ is exactly the
> same as "-r /usr/powerpc-g2.19-linux-gnu/", so maybe the
> confusion is expected ;)

It is ? Big surprise to me, I would expect -b /usr/powerpc-g2.19-linux-gnu/:/ mean
the same as "ln -s / /usr/powerpc-g2.19-linux-gnu", that is, guest /usr/powerpc-g2.19-linux-gnu
would be remapped to guest / without interfering with any -r

Jocke

[cdc]

On Mon, Jun 01, 2015 at 11:17:16AM +0000, Joakim Tjernlund wrote:
> It is ? Big surprise to me, I would expect -b /usr/powerpc-g2.19-linux-gnu/:/ mean
> the same as "ln -s / /usr/powerpc-g2.19-linux-gnu", that is, guest /usr/powerpc-g2.19-linux-gnu
> would be remapped to guest / without interfering with any -r

Actually "-b /usr/powerpc-g2.19-linux-gnu/:/" remaps
/usr/powerpc-g2.19-linux-gnu (from the host/actual rootfs) over /
(into the guest/virtual rootfs), that's why "-r path/to/rootfs" is
equivalent to "-b path/to/rootfs:/".

If you wish to remap a given path *from* the guest/virtual rootfs, you
have to specify its host/actual path as a source for the -b option.
For example:

-b path/to/rootfs/from:/to

is equivalent to execute "ln -s /from /to" *from* the prooted
environment.

Regards,
Cédric.