RTLD changes for non-native system (was: Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?)
Quoting Daniel O'Connor [EMAIL PROTECTED] (from Tue, 28 Oct 2008 10:18:10 +1030): On Tuesday 28 October 2008 01:31:16 M. Warner Losh wrote: In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Daniel O'Connor wrote: : On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: : 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. : : The same problem happens with the Linux run time linker - it merrily : tries to link FreeBSD libraries to Linux binaries with predictable : results.. : : You *can* link Linux libraries with FreeBSD binaries (and : vice versa), if the library does not perform any syscalls, : e.g. it is a pure computation library or similar. : : That said it would be really nice if it ignored incompatible libraries : :) : : No. Please don't put such pseudo-cleverness into rtld. : It wouldn't be an improvement, in fact it might break some : working configurations. Yes. I have a bunch of printer drivers that I've used that link in linux shared libraries... They are in ports... Good point.. The problem is really the Linux linker - it will find a FreeBSD library and try and use it ahead of a Linux one later in the search path - this prevents stuff working :) I have this exact problem with libfontconfig and Xilinx ISE. Perhaps instead of ignore, use last.. But then it doesn't really matter for the FreeBSD linker - I imagine I would have to convince Linux folks it's a good idea. Please ignore for a moment that we are not talking about changing the FreeBSD RTLD anymore: Would it make sense (for us and/or for GNU) to first search for libs for the current system and if none are found to try the others? Bye, Alexander. -- There is hardly a thing in the world that some man can not make a little worse and sell a little cheaper. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?
Daniel O'Connor wrote: On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: 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. The same problem happens with the Linux run time linker - it merrily tries to link FreeBSD libraries to Linux binaries with predictable results.. You *can* link Linux libraries with FreeBSD binaries (and vice versa), if the library does not perform any syscalls, e.g. it is a pure computation library or similar. That said it would be really nice if it ignored incompatible libraries :) No. Please don't put such pseudo-cleverness into rtld. It wouldn't be an improvement, in fact it might break some working configurations. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?
In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Daniel O'Connor wrote: : On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: : 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. : : The same problem happens with the Linux run time linker - it merrily tries to : link FreeBSD libraries to Linux binaries with predictable results.. : : You *can* link Linux libraries with FreeBSD binaries (and : vice versa), if the library does not perform any syscalls, : e.g. it is a pure computation library or similar. : : That said it would be really nice if it ignored incompatible libraries :) : : No. Please don't put such pseudo-cleverness into rtld. : It wouldn't be an improvement, in fact it might break some : working configurations. Yes. I have a bunch of printer drivers that I've used that link in linux shared libraries... They are in ports... Warner ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit ?binaries?
On Tuesday 28 October 2008 01:31:16 M. Warner Losh wrote: In message: [EMAIL PROTECTED] Oliver Fromme [EMAIL PROTECTED] writes: : Daniel O'Connor wrote: : On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: : 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. : : The same problem happens with the Linux run time linker - it merrily : tries to link FreeBSD libraries to Linux binaries with predictable : results.. : : You *can* link Linux libraries with FreeBSD binaries (and : vice versa), if the library does not perform any syscalls, : e.g. it is a pure computation library or similar. : : That said it would be really nice if it ignored incompatible libraries : :) : : No. Please don't put such pseudo-cleverness into rtld. : It wouldn't be an improvement, in fact it might break some : working configurations. Yes. I have a bunch of printer drivers that I've used that link in linux shared libraries... They are in ports... Good point.. The problem is really the Linux linker - it will find a FreeBSD library and try and use it ahead of a Linux one later in the search path - this prevents stuff working :) I have this exact problem with libfontconfig and Xilinx ISE. Perhaps instead of ignore, use last.. But then it doesn't really matter for the FreeBSD linker - I imagine I would have to convince Linux folks it's a good idea. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Fri, Oct 24, 2008 at 7:28 PM, Daniel O'Connor [EMAIL PROTECTED] wrote: On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: 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. The same problem happens with the Linux run time linker - it merrily tries to link FreeBSD libraries to Linux binaries with predictable results.. One trick I use for that is to put a symlink in /compat/linux in the place the problematic FreeBSD library is.. That said it would be really nice if it ignored incompatible libraries :) Yea. Also you go tot realize that if it didn't pick up /usr/lib32 shared objects then /lib would be searched as a last resort I believe since its the default path. As a result, things again would have just worked. Is this a bug or not in FreeBSD's rtld? -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Sat, 25 Oct 2008 08:49:19 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Is this a bug or not in FreeBSD's rtld? -aps It is not. In case it was not clear before, I maintain that you _ask_ rtld for wrong behaviour and you get back what you asked for, down to the letter. 'Tasting' libraries just because someone somewhere want to screw up their configuration does not seem right to me at all. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Sat, Oct 25, 2008 at 9:57 AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Sat, 25 Oct 2008 08:49:19 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Is this a bug or not in FreeBSD's rtld? -aps It is not. In case it was not clear before, I maintain that you _ask_ rtld for wrong behaviour and you get back what you asked for, down to the letter. 'Tasting' libraries just because someone somewhere want to screw up their configuration does not seem right to me at all. I maintain that rtld should not load 32-bit libraries for a 64-bit binary. That is WRONG anyway you look at it. And again, if it checked the arch type and skipped libutil.so.5 in /usr/lib32 it would fall back to checking /lib and things would work. Moreover, if /usr/lib had major number links just like /usr/lib32 has, this would again have worked without issue. I believe this will be fixed on the other side of the fence (not setting LD_LIBRARY_PATH to include /usr/lib32 to begin wtih) but still, my point still stands. -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Sat, 25 Oct 2008 13:10:53 -0400 Alexander Sack [EMAIL PROTECTED] wrote: On Sat, Oct 25, 2008 at 9:57 AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Sat, 25 Oct 2008 08:49:19 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Is this a bug or not in FreeBSD's rtld? -aps It is not. In case it was not clear before, I maintain that you _ask_ rtld for wrong behaviour and you get back what you asked for, down to the letter. 'Tasting' libraries just because someone somewhere want to screw up their configuration does not seem right to me at all. I maintain that rtld should not load 32-bit libraries for a 64-bit binary. That is WRONG anyway you look at it. And again, if it checked the arch type and skipped libutil.so.5 in /usr/lib32 it would fall back to checking /lib and things would work. Moreover, if /usr/lib had major number links just like /usr/lib32 has, this would again have worked without issue. I believe this will be fixed on the other side of the fence (not setting LD_LIBRARY_PATH to include /usr/lib32 to begin wtih) but still, my point still stands. -aps It doesn't. Stop feeding 32 bit libraries and it won't try to load them. It is as simple as that. For complex scenarious we do provide LD_32_ family of environment variables and if you refuse using them and insist on sticking with clearly broken configuration, it your problem, not rtld's. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
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? this will make system trying to bind 32-bit libs to 64-bit program. it can't work ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On 2008-Oct-24 10:43:04 +0200, Wojciech Puchar [EMAIL PROTECTED] 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. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpO8GHmdRY0K.pgp Description: PGP signature
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Fri, Oct 24, 2008 at 8:50 AM, Peter Jeremy [EMAIL PROTECTED] wrote: On 2008-Oct-24 10:43:04 +0200, Wojciech Puchar [EMAIL PROTECTED] 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Friday 24 October 2008 23:20:59 Peter Jeremy wrote: 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. The same problem happens with the Linux run time linker - it merrily tries to link FreeBSD libraries to Linux binaries with predictable results.. One trick I use for that is to put a symlink in /compat/linux in the place the problematic FreeBSD library is.. That said it would be really nice if it ignored incompatible libraries :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Dag-Erling Smørgrav [EMAIL PROTECTED] writes: If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. You can rebuild rtld(1) with debugging enabled: % cd /usr/src/libexec/rtld-elf % make clean % make DEBUG_FLAGS=-DDEBUG % make install % echo $LD_LIBRARY_PATH /home/des/lib:/opt/varnish/lib:/usr/local/lib % LD_DEBUG=1 /usr/bin/true /libexec/ld-elf.so.1 is initialized, base address = 0x80050 RTLD dynamic = 0x8006305b0 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libc.so.7 Trying /home/des/lib/libc.so.7 Trying /opt/varnish/lib/libc.so.7 Trying /usr/local/lib/libc.so.7 Trying /lib/libc.so.7 loading /lib/libc.so.7 Ignoring d_tag 1879048185 = 0x6ff9 0x80063b000 .. 0x80085efff: /lib/libc.so.7 checking for required versions initializing initial thread local storage relocating /usr/bin/true relocating /lib/libc.so.7 doing copy relocations initializing key program variables __progname: *0x5005e8 -- 0x7fffebc1 environ: *0x500878 -- 0x7fffe9a8 initializing thread locks calling init function for /lib/libc.so.7 at 0x800664da8 __sysctl in libc.so.7 == 0x80071ae00 in libc.so.7 reloc_jmpslot: *0x800845c78 = 0x80071ae00 transferring control to program entry point = 0x400420 atexit in true == 0x8006fac3e in libc.so.7 reloc_jmpslot: *0x500868 = 0x8006fac3e exit in true == 0x8006af118 in libc.so.7 reloc_jmpslot: *0x500860 = 0x8006af118 __cxa_finalize in libc.so.7 == 0x8006fa940 in libc.so.7 reloc_jmpslot: *0x800846140 = 0x8006fa940 rtld_exit() calling fini function for /lib/libc.so.7 at 0x80071ae60 _exit in libc.so.7 == 0x8006cfff0 in libc.so.7 reloc_jmpslot: *0x8008471d8 = 0x8006cfff0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Alexander Sack [EMAIL PROTECTED] writes: 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. [...] LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 I'm surprised you have /usr/bin in there... 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. If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. Someone I'm sure is going don't do that and I agree. Well, yeah, but it should (at the very least) fail in a more graceful manner. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, Oct 23, 2008 at 9:23 PM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: If you look at the rtld(1) man page, there are a number of environment variables you can set to debug the loader. I'm not sure how helpful they are, though. You can rebuild rtld(1) with debugging enabled: % cd /usr/src/libexec/rtld-elf % make clean % make DEBUG_FLAGS=-DDEBUG % make install % echo $LD_LIBRARY_PATH /home/des/lib:/opt/varnish/lib:/usr/local/lib % LD_DEBUG=1 /usr/bin/true /libexec/ld-elf.so.1 is initialized, base address = 0x80050 RTLD dynamic = 0x8006305b0 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libc.so.7 Trying /home/des/lib/libc.so.7 Trying /opt/varnish/lib/libc.so.7 Trying /usr/local/lib/libc.so.7 Trying /lib/libc.so.7 loading /lib/libc.so.7 Ignoring d_tag 1879048185 = 0x6ff9 0x80063b000 .. 0x80085efff: /lib/libc.so.7 checking for required versions initializing initial thread local storage relocating /usr/bin/true relocating /lib/libc.so.7 doing copy relocations initializing key program variables __progname: *0x5005e8 -- 0x7fffebc1 environ: *0x500878 -- 0x7fffe9a8 initializing thread locks calling init function for /lib/libc.so.7 at 0x800664da8 __sysctl in libc.so.7 == 0x80071ae00 in libc.so.7 reloc_jmpslot: *0x800845c78 = 0x80071ae00 transferring control to program entry point = 0x400420 atexit in true == 0x8006fac3e in libc.so.7 reloc_jmpslot: *0x500868 = 0x8006fac3e exit in true == 0x8006af118 in libc.so.7 reloc_jmpslot: *0x500860 = 0x8006af118 __cxa_finalize in libc.so.7 == 0x8006fa940 in libc.so.7 reloc_jmpslot: *0x800846140 = 0x8006fa940 rtld_exit() calling fini function for /lib/libc.so.7 at 0x80071ae60 _exit in libc.so.7 == 0x8006cfff0 in libc.so.7 reloc_jmpslot: *0x8008471d8 = 0x8006cfff0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
Alright, well I found some weirdness: [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# LD_DEBUG=1 ls /libexec/ld-elf.so.1 is initialized, base address = 0x800506000 RTLD dynamic = 0x80062ad78 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libutil.so.5 Trying /usr/bin/libutil.so.5 Trying /usr/lib/libutil.so.5 Trying /usr/lib32/libutil.so.5 loading /usr/lib32/libutil.so.5 /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout That's because libutil.so.5 does not exist in /usr/lib only in /lib. The /usr/lib directory has: [EMAIL PROTECTED] ~]# ls -l /usr/lib/libutil* -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 So rtld is looking for major number 5 of libutil, without the standard /lib in my LD_LIBRARY_PATH it searches /usr/lib, doesn't find it but: [EMAIL PROTECTED] ~]# ls -l /usr/lib32/libutil* -r--r--r-- 1 root wheel 65274 Aug 21 2007 /usr/lib32/libutil.a lrwxrwxrwx 1 root wheel 12 Sep 11 11:45 /usr/lib32/libutil.so - libutil.so.5 -r--r--r-- 1 root wheel 46872 Aug 21 2007 /usr/lib32/libutil.so.5 -r--r--r-- 1 root wheel 66918 Aug 21 2007 /usr/lib32/libutil_p.a And whalah, I'm broke since there is a libutil.so.5 in there. So my question to anyone out there, WHY does /usr/lib32 contain major numbers but /usr/lib does not? This seems like a bug to me (FreeBSD 7.0-RELEASE is the same) or at least a dubious design decision. Thanks! -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, Oct 23, 2008 at 10:09 PM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Thu, 23 Oct 2008 21:48:47 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. Yes I figured that out on my own but my question still exists, why isn't /usr/lib similar in format to /usr/lib32 though with respect to major numbers? Actually now that I re-read your paragraph I suppose this isn't such a bad idea but for some reason I believe that if you have /usr/lib before /usr/lib32 it should *just* work. -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, 23 Oct 2008 21:48:47 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Thanks, comments most appreciated. Damn, I was looking for someone to go a ha, you can't do this because Alright, let me see why rtld on 6.1-amd64 is picking up /usr/lib32 stuff for a native 64-bit binary via debugging techniques. This seems very very wrong to me. I mean if /usr/lib is in my LD_LIBRARY_PATH and it comes before /usr/lib the /usr/lib32 *should* be innocuous, right? Feel free to use that last statement on my epitaph! :D LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, 23 Oct 2008 22:31:40 -0400 Alexander Sack [EMAIL PROTECTED] wrote: Yes I figured that out on my own but my question still exists, why isn't /usr/lib similar in format to /usr/lib32 though with respect to major numbers? Actually now that I re-read your paragraph I suppose this isn't such a bad idea but for some reason I believe that if you have /usr/lib before /usr/lib32 it should *just* work. trimmed hackers@ from CC as this question does not belong there The last statement is as wrong as it gets. I tried but I still fail to see the reason why you would possibly expect that to work reliably. By setting LD_LIBRARY_PATH to /usr/lib:/usr/lib32, you cause dynamic linker to look for libraries in /usr/lib, usr/lib32 and /lib in that exact order, so if library in /usr/lib32 shadows one in /lib, it will be rightly picked up and you will get exactly what you asked for. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, 23 Oct 2008, Alexander Sack wrote: Alright, well I found some weirdness: [EMAIL PROTECTED] ~]# export LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64 [EMAIL PROTECTED] ~]# LD_DEBUG=1 ls /libexec/ld-elf.so.1 is initialized, base address = 0x800506000 RTLD dynamic = 0x80062ad78 RTLD pltgot = 0x0 processing main program's program header Filling in DT_DEBUG entry lm_init((null)) loading LD_PRELOAD libraries loading needed objects Searching for libutil.so.5 Trying /usr/bin/libutil.so.5 Trying /usr/lib/libutil.so.5 Trying /usr/lib32/libutil.so.5 loading /usr/lib32/libutil.so.5 /libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout That's because libutil.so.5 does not exist in /usr/lib only in /lib. The /usr/lib directory has: [EMAIL PROTECTED] ~]# ls -l /usr/lib/libutil* -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 So rtld is looking for major number 5 of libutil, without the standard /lib in my LD_LIBRARY_PATH it searches /usr/lib, doesn't find it but: [EMAIL PROTECTED] ~]# ls -l /usr/lib32/libutil* -r--r--r-- 1 root wheel 65274 Aug 21 2007 /usr/lib32/libutil.a lrwxrwxrwx 1 root wheel 12 Sep 11 11:45 /usr/lib32/libutil.so - libutil.so.5 -r--r--r-- 1 root wheel 46872 Aug 21 2007 /usr/lib32/libutil.so.5 -r--r--r-- 1 root wheel 66918 Aug 21 2007 /usr/lib32/libutil_p.a And whalah, I'm broke since there is a libutil.so.5 in there. So my question to anyone out there, WHY does /usr/lib32 contain major numbers but /usr/lib does not? This seems like a bug to me (FreeBSD 7.0-RELEASE is the same) or at least a dubious design decision. I think the distinction is this. rtld is looking for libutil.so.5 (with version number). This file has to be in /lib, in the root filesystem, so that programs can run before /usr is mounted. libutil.so on the other hand is not searched for by rtld, but by ld (driven by cc), when the program is built. /usr/lib is the traditional place for it to search; I'm not sure if it searches /lib at all. In the case of static libraries, /usr/lib is certainly the right place for libutil.a to go, so having libutil.so there makes sense in my mind. I think your best bet is to dig into whatever is setting LD_LIBRARY_PATH and get it set correctly. Remove /usr/lib32 or at least ensure that /lib is searched first. Trying to change rtld's behavior is not the right approach, IMHO. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
In the last episode (Oct 23), Alexander Sack said: On Thu, Oct 23, 2008 at 10:09 PM, Alexander Kabaev [EMAIL PROTECTED] wrote: LD_LIBRARY_PATH is for native 64bit rtld. If you want a specific path added for use by 32-bit ld-elf.so.1 only, use LD_32_LIBRARY_PATH. Said that, your problem is likely caused by the fact that there is no /lib32, only /usr/lib32. So if 64-bit library lives in /lib, your LD_LIBRARY_PATH will cause loader to find its 32-bit equivalent in /usr/lib32 first. Try LD_LIBRARY_PATH=/lib:/usr/lib:/usr/lib32:/usr/lib64 for better results. Yes I figured that out on my own but my question still exists, why isn't /usr/lib similar in format to /usr/lib32 though with respect to major numbers? Ever since the switch from static to dynamic-linked /bin and /sbin, some shared libraries are needed during the boot process. Those libraries live in /lib, and since there are no 32-bit binaries required to boot a 64-bit system, there is no need for a /lib32. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
