i386 binaries on amd64: ldconfig problems

[Konstantin Belousov]

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