Date: Fri, 24 Oct 2008 09:09:35 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: "Peter Jeremy" <peterjeremy@optushome.com.au> Cc: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>, freebsd-questions@freebsd.org Subject: Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries? Message-ID: <3c0b01820810240609g402e4947m762f59c0ddd434ea@mail.gmail.com> In-Reply-To: <20081024125059.GE1137@server.vk2pj.dyndns.org> References: <3c0b01820810231731s1b4d4659j7d1df8bf4abb229c@mail.gmail.com> <20081024104232.X21603@wojtek.tensor.gdynia.pl> <20081024125059.GE1137@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 24, 2008 at 8:50 AM, Peter Jeremy <peterjeremy@optushome.com.au> wrote: > On 2008-Oct-24 10:43:04 +0200, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote: >>> 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. >> >>what do you expect else? > > Well, the rtld should be smart enough to recognize 32-bit .so's and > skip them when binding a 64-bit executable. Whilst having /usr/lib32 > in LD_LIBRARY_PATH doesn't make sense from a solely FreeBSD perspective, > I have done similar things when writing cross-platform scripts (to > avoid having to use platform-dependent code). > >>this will make system trying to bind 32-bit libs to 64-bit program. it >>can't work > > rtld shouldn't attempt to bind 32-bit libs to 64-bit programs. Bingo! I don't care what the LD_LIBRARY_PATH is, a 64-bit binary should NEVER attempt to load a 32-bit library (at least by default). If anything, rtld should just exit with can't find library exception. What its doing now in my book is just wrong in everyway. The name of the shared object is no longer enough to verify a match, it also needs to check the arch bits as well. I agree with everyone on this list that for FreeBSD, the gcc toolset initialization should always contain /lib (and in fact I am going further and saying that al *NIX platforms should probably always check /lib since its the default and its there during bootup (that was a good point btw)). I think the issue has been cross platform builds and the way Linux has it organized. I have submitted a patch to add /lib back to the Boost folks but I still want to understand this behavior on FreeBSD - what am I missing? Final note, I thought that /usr/lib would have the major number versions linked just like /usr/lib32 so the above would just work. Right now the issue is libutil.so.5 isn't found not because /lib isn't in the LD_LIBRARY_PATH, i.e If I make a symlink in /usr/lib just like the /usr/lib32 file structure, it all just works. I was just saying above that I was wondering why major numbers aren't actually available as links in /usr/lib like they are in /usr/lib32. -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820810240609g402e4947m762f59c0ddd434ea>