Re: Some questions on Solaris linker

From: Christopher Currie (Christopher_at_[hidden])
Date: 2004-01-12 18:26:36

Vladimir Prus wrote:
>>It is sensitive in the case of static libraries (archives), not in the
>>case of dynamic libraries (shared objects). It seems this is the reason
>>that the gcc toolset lists all the libraries twice, but unfortunately
>>that plays all sorts of havoc with dynamic libraries (the Solaris linker
>>complains about multiple inclusion).
> 
> That's a mess :-(

Agreed.

> Seems like we'll still need to implement proper ordering.

I sympathize with the difficulty of this problem, but unfortunately, yes 
I think we will, or else require the user to somehow define the ordering 
themselves.

> 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).

Perhaps a solution to save our sanity would be to just not support 
-rpath-link at all, but instead require -R. I still question value of 
-rpath-link, anyway; you might just as well ignore undefined symbols, 
since there's no guarantee the library you pointed to at link time will 
be available at run time.

>>Before I get to that, recent CVS bjam/bbv2 now will not build anything
>>unless I have $BOOST_ROOT set; should this be the case?
> 
> No, BOOST_ROOT should have no effect. What kind of errors do you get?

Found the problem. I've got a "using boostbook : ... ;" directive in 
user-config.jam, but line 83 of boostbook.jam has:

local boost-root = [ path.make [ module.peek : BOOST_ROOT ] ] ;

which, if BOOST_ROOT is unset, results in an error from path.make being 
called with an empty parameter. Looks like boostbook.jam might need to 
be reworked a bit.

> Can you tell some things:
> 1. Have you built bjam?

Yes.

> 2. What is the name of binary directory that is produced?

bin.solaris

> 3. What is the output of the following python script
> 
> import os
> print os.name
> print os.uname

ccurrie_at_thunderbird [12:02:51] [~/src/boost/tools/build/v2/test]
$ python
Python 2.2.3 (#1, Jan 9 2004, 14:00:14)
[GCC 3.3.2] on TvoPT5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print os.name
posix
>>> print os.uname
<built-in function uname>
>>>

--
Christopher