Install ncurses on an AMD64 system (will likely happen on other multilib systems). With gen_usr_ldscript, this is generated: $ cat /mnt/gen64/usr/lib/libncurses.so /* GNU ld script Since Gentoo has critical dynamic libraries in /lib, and the static versions in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we run into linking problems. See bug http://bugs.gentoo.org/4411 for more info. */ GROUP ( /lib64/libncurses.so ) Then, try doing this on a 2.6.13-rc4 kernel tree: make menuconfig ARCH=um SUBARCH=i386 That will build the lxdialog binary with -m32 which links to ncurses. It will search for the library in that location (/usr/lib/libncurses.so) and then go to /lib64, and refuse that library. It means that even with -m32 gcc looks there, and finds a wrong file. I don't know a correct fix for this (maybe specifying a choice inside the created linker script). Reproducible: Always Steps to Reproduce: 1. 2. 3.
emerge emul-linux-x86-baselibs, it contains ncurses
I _do_ have ncurses. But _you_ (Gentoo) should put (additionally) 32-bit libraries in /usr/lib32, or symlink them there. How's GCC going to find libraries in /emul/...?
As an example of what I mean, take this example. $ ls -l /emul/linux/x86/usr/lib32/libncurses* /usr/lib32/libncurses* ls: /usr/lib32/libncurses*: No such file or directory -rwxr-xr-x 1 root root 314 4 nov 05:47 /emul/linux/x86/usr/lib32/libncurses.so -rwxr-xr-x 1 root root 315 4 nov 05:47 /emul/linux/x86/usr/lib32/libncursesw.so
have a look at /etc/ld.so.conf, it's a list of the default paths in which gcc will search for libraries. if you're interested in the details, also have a look at the profiles' portage.bashrc and http://dev.gentoo.org/~plasmaroo/devmanual//archs/amd64/ GCC *will* find libraries in /emul if you've emerged the emul-* packages
No, it's a wide-spread knowledge that GCC does not care to /etc/ld.so.conf. I've just tested on my system. I've done my homework and read the link you provided. And it's /etc/make.profile/make.defaults to make 32-bit apps emerge, and it only works for portage. Not for normal compilation, which is my purpose. Yes, I forgot to state this detail, gcc -m32 -Wall -W -g smart-resync.c -o smart-resync -lncurses (where smart-resync.c is a small dummy program which doesn't even need ncurses) does not work: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /lib64/libncurses.so when searching for /lib64/libncurses.so /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find /lib64/libncurses.so collect2: ld returned 1 exit status While it works with an explicit -L flag: $ gcc -m32 -Wall -W -g smart-resync.c -o smart-resync -lncurses -L /emul/linux/x86/lib32/ I have emul-* installed: $ epm -qf /emul/linux/x86/lib/libncurses.so.5.4 emul-linux-x86-baselibs-2.3 So, again, do you finally believe you have a bug? Btw, can I assume installation of real 32-bit packages just a "we're not there yet" feature? Some comments seam to vaguely suggest so, but I didn't find this listed in the FAQ.
(In reply to comment #5) > for portage. Not for normal compilation, which is my purpose. Whoops, missed that bit. > So, again, do you finally believe you have a bug? Yup :D > Btw, can I assume installation of real 32-bit packages just a "we're not there > yet" feature? Some comments seam to vaguely suggest so, but I didn't find this > listed in the FAQ. It is a workaround, yes, and not one that we're really happy with, but it is the only way we can provide 32bit software without a fully multilib-capable portage. Still hoping this will change sometime.
marking this as LATER since it's going to be fixed when we finally have real multilib support, but till then there's nothing we can really do. 32bit libraries don't go into lib32 for all profiles, so it'd be rather tricky to do in an ebuild. beside that, it's just another ugly workaround.. sanest thing you can do is using CFLAGS="${CFLAGS} -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib", which is what we currently do in portage.
From comment #7: > 32bit libraries don't go into lib32 for all profiles, so it'd be rather tricky > to do in an ebuild I.e. the same ebuild (emul-*) could put libraries elsewhere in a different profile? No "implicit" use flag (fixed for a given profile) can be added to specify this? Also, some ebuild do put libraries in /usr/lib32. Also, the "ugly workaround" thing is only the missing support to multilib, not installing the binary libraries in more reasonable places. The inelegant part is using this /emul hierarchy. However, I'd like suggest another (temporary) solution: patching Gcc's "specs" file to add -L/emul/<whatever> when -m32 is specified. Don't know if it's easy (the syntax looks fairly dense and undocumented), but seems doable. I know it's not very good, however I'm still tossing this out here. (btw, I think that to multilib it would be preferrable multiarch - installing an i386 package is supported on a lot of other package system, and would be very useful for mplayer with win32codecs).
reopen
emul-libs install to standard locations now
