Date: Thu, 23 Oct 2008 20:31:05 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: freebsd-questions@freebsd.org Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries? Message-ID: <3c0b01820810231731s1b4d4659j7d1df8bf4abb229c@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello: I have some weird behavior I'm trying to figure out and was wondering if someone can point me in the right direction. I'm running a FreeBSD 6.1-RELEASE-amd64 machine. If I add /usr/lib32 to my LD_LIBRARY_PATH it breaks all of my binaries on my 64-bit machine. For example: [root@hagen ~]# file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped [root@hagen ~]# ldd /bin/ls /bin/ls: libutil.so.5 => /lib/libutil.so.5 (0x800630000) libncurses.so.6 => /lib/libncurses.so.6 (0x80073d000) libc.so.6 => /lib/libc.so.6 (0x800896000) [root@hagen ~]# ls -l /libexec/ total 306 -r-xr-xr-x 1 root wheel 163864 Aug 21 2007 ld-elf.so.1 -r-xr-xr-x 1 root wheel 146420 Aug 21 2007 ld-elf32.so.1 [root@hagen ~]# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [root@hagen ~]# ls /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout [root@hagen ~]# unset LD_LIBRARY_PATH [root@hagen ~]# ls (normal ls output) [root@hagen ~]# ls -l /usr/lib/libut* -r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so -> /lib/libutil.so.5 -r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a [root@hagen ~]# file /lib/libutil.so.5 /lib/libutil.so.5: ELF 64-bit LSB shared object, AMD x86-64, version 1 (FreeBSD), stripped I would ASSUME that rtld would look at my LD_LIBRARY_PATH and use /usr/lib to find libraries, not /usr/lib32. Why does it insist on picking /usr/lib32 when "/bin/ls" is CLEARLY a 64-bit binary? This doesn't make complete sense to me just yet. Someone I'm sure is going "don't do that" and I agree. The issue is I'm porting a library/framework (boost) and it creates a runtime LD_LIBRARY_PATH for its gcc toolchain with the above which breaks the build ROYALLY on FreeBSD 64-bit machine. I'm trying to come up with the right heuristic here. Any help would be much appreciated! Thanks! -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820810231731s1b4d4659j7d1df8bf4abb229c>