Bugzilla Bug 49678

After emerging emul-linux-x86-baselibs I can't get any 32-bit applications to
run: they complain they can't find /lib/ld-linux.so.2. The tech notes for amd64
say that a link from /lib/ld-linux.so.2 to /emul/..../ld-linux.so.2 should have
been automatically created. But it is not created! Unless I create the link by
hand (which I did with the command below), no 32-bit applications work. This
makes it impossible to emerge some x86 binary builds (e.g. openoffice-bin)
because the ebuild tries to run 32-bit applications in the process.

ln -s /emul/linux/x86/lib/ld-linux.so.2 /lib/ld-linux.so.2

After this link is created things seem to work fine.

Reproducible: Always
Steps to Reproduce:
1. emerge emul-linux-x86-baselibs
2. try to run any non-statically-linked 32-bit app (e.g. acroread)
3.

Actual Results:  
bash: appname: No such file or directory

Expected Results:  
Should have made a link from /emul/linux/x86/lib/ld-linux.so.2 to /lib/ld-
linux.so.2

phi dvandyk # ll /lib32
lrwxrwxrwx  1 root root 19 May  2 23:06 /lib32 -> /emul/linux/x86/lib
phi dvandyk # ll /lib32/ld-linux.so.2
lrwxrwxrwx  1 root root 11 May  2 23:06 /lib32/ld-linux.so.2 -> ld-2.3.2.so

That's the normal setup for Gentoo/amd64. It works for all 32bit binaries i know in portage.

Ah, and please provide the md5sum of emul-linux-x86-baselibs-1.1.ebuild.

The md5sum for my emul-linux-x86-baselibs-1.1.ebuild
is 5a6f8865e339320acec47c35a9fbd1e2.

Without creating the link by hand, here's what happens:

# ACCEPT_KEYWORDS=x86 emerge acroread
[success]
# ldd /opt/Acrobat5/Reader/intellinux/bin/acroread
/usr/bin/ldd: line 1: /lib/ld-linux.so.2: No such file or directory
ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)
# /opt/Acrobat5/Reader/intellinux/bin/acroread
sh: /opt/Acrobat5/Reader/intellinux/bin/acroread: No such file or directory

After I create the link by hand:

# ldd /opt/Acrobat5/Reader/intellinux/bin/acroread
        libXt.so.6 => /emul/linux/x86/usr/X11R6/lib/libXt.so.6 (0x55580000)
        libXp.so.6 => /emul/linux/x86/usr/X11R6/lib/libXp.so.6 (0x555d1000)
        libXext.so.6 => /emul/linux/x86/usr/X11R6/lib/libXext.so.6 (0x555d9000)
        libX11.so.6 => /emul/linux/x86/usr/X11R6/lib/libX11.so.6 (0x555e7000)
        libm.so.6 => /lib32/libm.so.6 (0x556ad000)
        libdl.so.2 => /lib32/libdl.so.2 (0x556cf000)
        libc.so.6 => /lib32/libc.so.6 (0x556d2000)
        libSM.so.6 => /emul/linux/x86/usr/X11R6/lib/libSM.so.6 (0x557ff000)
        libICE.so.6 => /emul/linux/x86/usr/X11R6/lib/libICE.so.6 (0x55807000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000)
# /opt/Acrobat5/Reader/intellinux/bin/acroread
[runs normally. Actually it complains because it doesn't like to be 
run by hand, but that shows that it is at least starting]

By the way,

# uname -a
Linux gandalf 2.6.3-gentoo-r2 #1 Wed Apr 28 14:15:50 BRT 2004 x86_64 12 GNU/Linux

It seems to me (at least that's what I always read in books, etc) is that
dynamically-linked binary applications have the string '/lib/ld-linux.so.2'
hard-coded into the executable, so ld-linux.so.2 must be present at that
specific location...

Ok, my fault. There _needs_ to be a /lib/ld-linux-2.so. The necessary symlinks
should be created by the ebuild but that fails, cause ${D}/lib doesn't exist
:-/

Fixed now. Thanks a lot Bruno.

thanks for looking into it!