Johannes Schauer <[email protected]> writes:
> 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?
Yeah, I think those would be the two options.
>> 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.
If I rember correctly this was for the multiarch setup when you run
armel binaries outside the chroot.
> 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.
Given some spare time I will test this again, after I recovered from debconf.
> 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
MfG
Goswin
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
