Hi,
I've recently migrated my workstation from i386 to amd64
(finally, because I neeed to go beyond 4 GB RAM). The
transition went smoothly so far, except for one thing:
I need to use several old i386 binaries, which all work
well except for one: olvwm.
$ uname -rsm
FreeBSD 8.3-STABLE-20120528 amd64
$ olvwm
/libexec/ld-elf.so.1: /usr/local/lib/libXpm.so.4: unsupported file layout
$ file olvwm
olvwm: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD),
dynamically linked (uses shared libs), for FreeBSD 8.2 (802502), stripped
$ ldd olvwm
olvwm:
libXpm.so.4 => not found (0x0)
libolgx.so.3 => /usr/local/lib32/compat/libolgx.so.3 (0x280d1000)
libXext.so.6 => not found (0x0)
libX11.so.6 => not found (0x0)
libm.so.5 => /usr/lib32/libm.so.5 (0x280df000)
libc.so.7 => /usr/lib32/libc.so.7 (0x280f9000)
$ ldconfig -32 -r | head -2
/var/run/ld-elf32.so.hints:
search directories: /usr/lib32:/usr/local/lib32:/usr/local/lib32/compat
$ ldconfig -32 -r | egrep 'libXpm|libXext|libX11'
190:-lXpm.4 => /usr/local/lib32/compat/libXpm.so.4
192:-lXext.6 => /usr/local/lib32/compat/libXext.so.6
193:-lX11.6 => /usr/local/lib32/compat/libX11.so.6
So, the 32bit libraries are there, ldconfig knows about them,
but the runtime linker does not, apparently.
Interestingly, it works when I force the library path (this
is currently the work-around that I'm using):
LD_32_LIBRARY_PATH=/usr/local/lib32/compat ldd olvwm
olvwm:
libXpm.so.4 => /usr/local/lib32/compat/libXpm.so.4 (0x280d1000)
libolgx.so.3 => /usr/local/lib32/compat/libolgx.so.3 (0x280e1000)
libXext.so.6 => /usr/local/lib32/compat/libXext.so.6 (0x280ef000)
libX11.so.6 => /usr/local/lib32/compat/libX11.so.6 (0x280fe000)
libm.so.5 => /usr/lib32/libm.so.5 (0x28216000)
libc.so.7 => /usr/lib32/libc.so.7 (0x28230000)
libxcb.so.2 => /usr/local/lib32/compat/libxcb.so.2 (0x2834b000)
libXau.so.6 => /usr/local/lib32/compat/libXau.so.6 (0x28362000)
libXdmcp.so.6 => /usr/local/lib32/compat/libXdmcp.so.6 (0x28365000)
libpthread-stubs.so.0 =>
/usr/local/lib32/compat/libpthread-stubs.so.0 (0x2836a000)
librpcsvc.so.5 => /usr/lib32/librpcsvc.so.5 (0x2836c000)
But actually I shouldn't have to use LD_32_LIBRARY_PATH.
I mean, it's ldconfig's job to configure the directories for
locating the libraries.
What is wrong here?
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
Blogging: Never before have so many people
with so little to say said so much to so few.
On Wed, May 30, 2012 at 06:15:59PM +0200, Oliver Fromme wrote:> Hi, > > I've recently migrated my workstation from i386 to amd64 > (finally, because I neeed to go beyond 4 GB RAM). The > transition went smoothly so far, except for one thing: > I need to use several old i386 binaries, which all work > well except for one: olvwm. > > $ uname -rsm > FreeBSD 8.3-STABLE-20120528 amd64 > > $ olvwm > /libexec/ld-elf.so.1: /usr/local/lib/libXpm.so.4: unsupported file layout > > $ file olvwm > olvwm: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked (uses shared libs), for FreeBSD 8.2 (802502), stripped > > $ ldd olvwm > olvwm: > libXpm.so.4 => not found (0x0) > libolgx.so.3 => /usr/local/lib32/compat/libolgx.so.3 (0x280d1000) > libXext.so.6 => not found (0x0) > libX11.so.6 => not found (0x0) > libm.so.5 => /usr/lib32/libm.so.5 (0x280df000) > libc.so.7 => /usr/lib32/libc.so.7 (0x280f9000) > > $ ldconfig -32 -r | head -2 > /var/run/ld-elf32.so.hints: > search directories: /usr/lib32:/usr/local/lib32:/usr/local/lib32/compat > > $ ldconfig -32 -r | egrep 'libXpm|libXext|libX11' > 190:-lXpm.4 => /usr/local/lib32/compat/libXpm.so.4 > 192:-lXext.6 => /usr/local/lib32/compat/libXext.so.6 > 193:-lX11.6 => /usr/local/lib32/compat/libX11.so.6 > > So, the 32bit libraries are there, ldconfig knows about them, > but the runtime linker does not, apparently. > > Interestingly, it works when I force the library path (this > is currently the work-around that I'm using): > > LD_32_LIBRARY_PATH=/usr/local/lib32/compat ldd olvwm > olvwm: > libXpm.so.4 => /usr/local/lib32/compat/libXpm.so.4 (0x280d1000) > libolgx.so.3 => /usr/local/lib32/compat/libolgx.so.3 (0x280e1000) > libXext.so.6 => /usr/local/lib32/compat/libXext.so.6 (0x280ef000) > libX11.so.6 => /usr/local/lib32/compat/libX11.so.6 (0x280fe000) > libm.so.5 => /usr/lib32/libm.so.5 (0x28216000) > libc.so.7 => /usr/lib32/libc.so.7 (0x28230000) > libxcb.so.2 => /usr/local/lib32/compat/libxcb.so.2 (0x2834b000) > libXau.so.6 => /usr/local/lib32/compat/libXau.so.6 (0x28362000) > libXdmcp.so.6 => /usr/local/lib32/compat/libXdmcp.so.6 (0x28365000) > libpthread-stubs.so.0 => /usr/local/lib32/compat/libpthread-stubs.so.0 (0x2836a000) > librpcsvc.so.5 => /usr/lib32/librpcsvc.so.5 (0x2836c000) > > But actually I shouldn't have to use LD_32_LIBRARY_PATH. > I mean, it's ldconfig's job to configure the directories for > locating the libraries. > > What is wrong here?The library search order is LD_{32}_LIBRARY_PATH, then DT_RPATH from the binary, then hints, then /lib:/usr/lib. So if rpath of the binary contains /usr/local/lib, you get /usr/local/lib before hints. Rtld uses only the search path from the hints file. When a library with the matched name found, rtld tries to load it. Regardless of the result of the load attempt, further components of the search path list are not tried. Look at the olvwm binary with readelf and see whether DT_RPATH specifies /usr/local/lib. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120531/c1a5b205/attachment.pgp
Konstantin Belousov wrote:
> The library search order is LD_{32}_LIBRARY_PATH, then DT_RPATH from
> the binary, then hints, then /lib:/usr/lib. So if rpath of the binary
> contains /usr/local/lib, you get /usr/local/lib before hints.
>
> Rtld uses only the search path from the hints file. When a library with
> the matched name found, rtld tries to load it. Regardless of the result
> of the load attempt, further components of the search path list are not
> tried.
I see. Thanks for the explanation, now I understand.
I forgot about rpath and thought that the hints would take
precedence.
> Look at the olvwm binary with readelf and see whether DT_RPATH specifies
> /usr/local/lib.
Yes, it does:
0x0000000f (RPATH) Library rpath: [/usr/local/lib]
Well, then I will just keep my LD_32_LIBRARY_PATH workaround.
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
The easiest way to teach yourself C++ in 21 days:
http://abstrusegoose.com/249