Re: Some questions on Solaris linker

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

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:

gcc -Wl,-V

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
FAILED
Traceback (most recent call last):
File "test_all.py", line 127, in ?
run_tests(critical_tests, tests)
File "test_all.py", line 32, in run_tests
__import__(i)
File "unit_tests.py", line 5, in ?
t = Tester(pass_toolset=0)
File "BoostBuild.py", line 120, in __init__
exit(1)
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.

Christopher