i386 binaries on amd64: ldconfig problems

[Konstantin Belousov]

On Thu, May 31, 2012 at 05:28:42PM +0700, Eugene Grosbein wrote:
> 31.05.2012 16:58, Konstantin Belousov writes:
> 
> >> 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.
> 
> I've faced exactly same problem. What can be done other to rebuild
> of all such 32bit bit binaries to make them work for transition period?
> Should libmap32.conf help? It seems it does not.
No idea.

The presence of rpath in the binary indicates self-inflicted damage.
Just do not specify -rpath for linking. If you have such broken binary,
use LD_LIBRARY_PATH to override.

In fact, the ELF standard requires that DT_RPATH is not overridable by
LD_LIBRARY_PATH env variable, but DT_RUNPATH is. Currently our rtld
interpretes both DT_RPATH and DT_RUNPATH as overridable, thus violating
the standard and diverging from other ELF platforms.

Dragonfly fixed this.
-------------- 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/3e92e5c6/attachment.pgp