Hi, On Thu, Mar 10, 2011 at 02:16:11PM +0100, Goswin von Brederlow wrote: > 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.
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? > 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
