Boost logo

Boost-Build :

From: Christopher Currie (Christopher_at_[hidden])
Date: 2004-01-23 11:21:21


Vladimir Prus wrote:
> Christopher Currie wrote:
>
>>>I would say the simplest way is to add a parameter to 'gcc.init' telling
>>>which linker should be used. If not specified, reasonable defaults will
>>>be used -- like using solaris linker on solaris host.
>>
>>Yes, I think it might come to that, since it seems that the Solaris
>>linker and the GNU linker are completely incompatible in this regard.
>>Sun seems to take the policy that any shared library that requires
>>another shared library should hardcode the runtime path (using -R).
>
>
> Interesting.. see below
>
>
>>Perhaps a solution to save our sanity would be to just not support
>>-rpath-link at all, but instead require -R.
>
>
> The problem is that Debian Linux has the policy that no shared library should
> hardcode the runtime path. Since Debian appears to be the most stable Linux
> distrubution, I prefer to believe their policy -- reading mailing list
> discussion on this did not enlighten me much :-(

I think I've found why Solaris recommends hardcoding dependant library
paths, because the situation gets even worse. When the runtime path is
stored in an executable, it applied only to the libraries that are
directly linked on the command line. If any of those libraries depend on
other libraries, the runtime linker looks only at the runtime path of
the dependant library, *not of the executable*. Thus, given two
libraries, 'a' and 'b', and 'b' depends upon 'a' and was linked to it
without a hardcoded runtime path:

$ gcc -o app -L../libs -R../libs app.c ../libs/libb.so

$ ldd -s app

find object=libb.so; required by app
search path=/shared/ccurrie/gcc-3.3.2/lib (LD_LIBRARY_PATH)
trying path=/shared/ccurrie/gcc-3.3.2/lib/libb.so
search path=../libs (RPATH from file app)
trying path=../libs/libb.so
libb.so => ../libs/libb.so

find object=liba.so; required by ../libs/libb.so
search path=/shared/ccurrie/gcc-3.3.2/lib (LD_LIBRARY_PATH)
trying path=/shared/ccurrie/gcc-3.3.2/lib/liba.so
search path=/usr/lib (default)
trying path=/usr/lib/liba.so
liba.so => (file not found)

This seems to be inherent in the way the Solaris dynamic loader works,
independant of the link editor used. The only other option is to specify
'liba.so' on the link line of the executable.

Christopher

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk