Re: [PATCH] fixes for /usr/lib64 systems

In message <20030306115215.GC31291@redhat.com> on Thu, Mar 06, 2003 at 11:52:15AM +0000, Joe Orton wrote: > /usr/lib64 exists so that you can have 64-bit libraries installed > alongside 32-bit libraries in /usr/lib - this is a precedent that comes > from Sun or SGI or somewhere I believe. Yep, HP-UX does it, too. > (In fact I think you can get /usr/lib32 as well for some IRIX/MIPS, > since there are two different flavours of 32-bit ABI) Sure. Sometimes lib-and-lib32 or lib-and-lib64 or lib-and-lib/sparcv9 or lib-and-lib/pa20_64. > Adding /usr/lib64 or /usr/lib to the library search path at minimum > causes a re-ordering of the library search path, which means in some > circumstances you pick up the wrong versions of libraries. [...] > e.g. if you have a libfoo in /usr/lib, but you want to compile against a > different version you have installed in /home/jim/lib, you start with > -L/home/jim/lib -lfoo. If the configure script then adds -L/usr/lib to > LDFLAGS, you might end up with the system libfoo again, which is wrong. Sure, my question is whether (and why) /usr/lib and /usr/lib64 should be preferentially treated. > On a lib64 system, if you do have the 32-bit libraries installed in > /usr/lib, but want to compile against the 64-bit libraries in > /usr/lib64, adding /usr/lib to the library search path breaks everything > horribly, since you pick up the 32-bit libc etc. Okay, so 64-bit Linux needs the path hack because it will try and use 32-bit binaries with its 64-bit ABI instead of recognising that the 32-bit binaries cannot be used and skipping over them? Is that what you're saying?