From: Christopher Currie (Christopher_at_[hidden])
Date: 2004-01-09 14:31:53
Vladimir Prus wrote:
> Okay, then another question -- is Solaris linker sensitive to the order of
> libraries on command line? I read the above to mean it is not, but probably I
> was wrong. If it is sensitive, is there any way to make it insensitive?
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).
I was unable to find any way of making the Solaris linker insensitive.
>From the manpage, in the section on the -l flag:
ld searches a library when it encounters its name, so the placement
of -l is significant.
This is why, a few months back, I posted a comment about library
dependency ordering, because my programs would link fine if I built
<link>shared, but when I build <link>static, they fail.
This is not just a problem with gcc and the Solaris linker, but with the
Sun toolset, because it's bundled linkers also only search archives when
specified on the command line.
> Actually, that email was the only source I could find to understand why
> --rpath-link is needed at all. By the time email was written GNU ld has very
> sloppy behaviour -- with Boost.Build, if there were underfined symbols, the
> linker issued the warning, but the binary crashed.
> Now there have improved things, so I have to either put --rpath-link, or pass
> --unresolved-symbols (or -z nodefs on Solaris). I've decided to path
> --rpath-link, so I think -L is needed on Solaris.
Actually, I would just recommend using -L in all cases, because it's
meaning is clearer. -rpath-link does not, IMO, add value to the linker
and makes things more confusing.
> I have some more questions: what's the best way to tell if non-GNU ld is used?
> Is the following check from V1 okay?
> switch $(JAMUNAME)
> case SunOS* :
> NO_GNU_LN = true ; # sun seems not to use the GNU linker with gcc
(Off topic, but I think the variable name NO_GNU_LN is awful, because
Unix *has* a tool called ln, for quite a different purpose. It should be
No, not at all. It's perfectly acceptable to build GCC on Solaris using
the binutils linker. It's not typically done, because in the past the
binutils linker (and its assembler, IIRC) had issues creating proper
executables on Solaris, but these problems are all past. Still, most
people don't bother to install binutils, since Solaris has perfectly
good tools available, and I think the default package distributed by Sun
does not use binutils.
The only way that I know of to determine the linker used is to capture
the output of:
which will generate lots of errors because of a failed link, but will
also get ld (either Solaris or GNU) to print out a version string that
could be interpreted. My linker prints out:
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.282
I'm not sure what the GNU linker looks like, but it probably has the
word GNU in it somewhere, perhaps we could key off that.
> Another question: are you able to run Boost.Build tests on Solaris? If not,
> can you tell what are the problems? I'm asking because some my changes
> might break Solaris, and I'd like to be at least sure that those regressions
> can be detected by tests.
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?
[ ... installing Python ... ]
ccurrie_at_thunderbird [14:30:36] [~/src/boost/tools/build/v2/test]
$ python test_all.py
skipping railsys test since QTDIR environment variable is unset
unit_tests : Cannot find built Boost.Jam
Traceback (most recent call last):
File "test_all.py", line 127, in ?
File "test_all.py", line 32, in run_tests
File "unit_tests.py", line 5, in ?
t = Tester(pass_toolset=0)
File "BoostBuild.py", line 120, in __init__
TypeError: 'str' object is not callable
So, no, they're not working right now. Not sure why, it seems to be
looking for ../../jam_src, which does exist in my tree, but it can't
seem to find it properly.
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