From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-13 04:25:23
Christopher Currie wrote:
> > 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
Ok. Then the corresponding issue needs to wait a bit more before being really
> > 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 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.
Sure. It's just an additional safeguard. I lean towards using it everywhere,
with -rpath-link on GNU linker, and -L on Solaris.
> >>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.
I'm sure it's so. Just nobody took the time.
> > Can you tell some things:
> > 2. What is the name of binary directory that is produced?
> > 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]
Thanks! Seems like Andre has made it work so now we can test on Solaris as
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