Hi,

we've been experimenting with using fakechroot on amd64 for an armel
chroot (to build an armel root filesystem for an embeded device as
user). And we found 3 problems:

1) /lib/ld-linux.so.3 not found

The armel binaries use a different ld.so which is only found INSIDE
the chroot. The exec call (kernel actually) only looks OUTSIDE the
chroot. So it tries to find the armel ld.so on the amd64 system and
fails.

What it should do is to call '$CHROOT/lib/ld-linux.so.3 arg[0] arg[1]
...'. This would involve parsing the elf file to extract the ld.so
string and prefixing it with the chroot path. This would also solve
the problem of incompatibilities between the system ld.so and the
chroot libs.

2) LD_PRELOAD=libfakechroot.so fails

By default LD_LIBRARY_PATH in a chroot will be set to (from memory)

  /usr/lib/fakechroot:/usr/lib32/fakechroot:$CHROOT/lib:$CHROOT/usr/lib

Now the problem is that /usr/lib/fakechroot/libfakechroot.so is amd64 and
/usr/lib32/fakechroot/libfakechroot.so is i386. But what we need is
armel, specifically $CHROOT/usr/lib/fakechroot/libfakechroot.so from
the libfakechroot installed in the chroot.

What I propose is to parse LD_LIBRARY_PATH and to add each entry again
but prefixed with $CHROOT.

3) LD_LIBRARY_PATH is hardcoded to the native and biarch architecture

When executing an armel binary the armel libfakechroot.so can not be
loaded because the LD_LIBRARY_PATH is too narrow. The fakechroot
binary hardcodes the path to /usr/lib/fakechroot:/usr/lib32/fakechroot
(or equivalent for other archs). Since my system is setup for armel
binaries too it shuld also include
/usr/arm-linux-gnueabi/lib/fakechroot. In general it should parse
/etc/ld.so.conf and for each dir it should check $DIR/fakechroot.

Alternatively (and for future multiarch packages) the fakechroot
package could drop a file in /etc/fakechroot/<arch>.conf listing the
directory to add to LD_LIBRARY_PATH. Installing fakechroot:armel would
then add the armel library dir. But that would be less flexible.

There is already another bugreport that fakechroot should parse
$CHROOT/etc/ld.so.conf when chrooting so option 1 would result in some
reusable code. It could then also add $CHROOT/$DIR/fakechroot to
LD_LIBRARY_PATH in the same pass. That would solve problem 2 in a
better way I think.

MfG
	Goswin

PS: debian/rules should use dh $@ --parallel

Hi,

if you want to execute armel on x86_64, then you probably use qemu-user
mode emulation?

if so, qemu-user will look in /etc/qemu-binfmt/arm/ for a root
filesystem that also includes an armel ld-linux.so.3. So to solve your
problem, you would place a armel rootfs (or at least the shared
libraries) in /etc/qemu-binfmt/arm/.

This process is very tedious and it's downsides have been discussed
here: [1]

A solution would be to do as you suggested and pass over the $CHROOT
directory to be used as the source of /lib/ld-linux.so.3. Using
qemu-user(1) this can be done with the -L commandline argument to it.

Unfortunately, qemu-arm is called transparently by the binfmt mechanism,
so there is no way to pass a commandline argument to it. Hence it was
proposed to introduce an environment variable that would qemu-user know
of the $CHROOT directory it shall search for shared libraries here: [2]

Does this answer your question or solve your problem?

I can not reproduce your problem. I have libfakeroot-sysv.so and
libfakechroot.so shared libraries in /usr/lib/arm-linux-gnueabi/ and
/usr/lib/arm-linux-gnueabihf/ directories on my host system and it
nicely loads those when I fakechroot into a foreign root filesystem.

Can you strace your fakechroot execution? It should look into those
directories for you as well.

The problem is more that neither fakeroot nor fakechroot are multiarch
yet, so you have to manually copy the shared libraries into their
multiarch directories.

I submitted a patch to make fakechroot multiarch here [3] and wrote the
maintainer of fakeroot a month ago but didnt get a response yet.


I can suggest you to go through the last two months of the
debian-embedded list archives and search for my threads regarding
fakechroot and a tool called polystrap that I wrote which uses
fakechroot. You could also join #emdebian and talk to me (josch) as I
think I already solved those problems of yours.

hope I could be of some help


cheers, josch


[1] http://lists.debian.org/debian-embedded/2011/06/msg00104.html
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632192
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632954

Johannes Schauer <j.schauer@email.de> writes:

Yeah, I think those would be the two options.

If I rember correctly this was for the multiarch setup when you run
armel binaries outside the chroot.

Given some spare time I will test this again, after I recovered from debconf.

MfG
        Goswin