Re: [jamboost] Re: Some questions on Solaris linker

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-12 04:19:05

Hi Christopher,

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

That's a mess :-(

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

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

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

To begin with, on GNU ld you have to you -rpath-link, because the directories 
specified by -L are ignored when linker tries to make sure all dynamic 
references are resolved. 

The only thing I've found about -L vs. -rpath-link was phrase that using -L 
for both purposes on Solaris "led to a number of problems". Of course, I have 
no idea what were those problems. 

I can conjecture that the scenario can be the following. You link your 
application to library scm.so, which in turn links to db.so. At the same time 
you put

-L /usr/lib

to linker command line. Linker tries to load 'db.so', to verify that 
references from scm.so to db.so are all resolved. But unfortunately, you have 
the previous version of 'db.so' lying in /usr/lib. So the linker loads this, 
and finds that all symbols are resolved. While in fact, if it loaded the 
newer version it would find that some references are missing. 

So, your link is okay, but then you install new scm.so and db.so to /usr/lib, 
you'll get unresoled symbols at runtime. Again, I don't know if this was the 
original motivation.

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

I think you're right.

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

Okay, then V2 needs to be a bit smarter.

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

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.

> > 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?

No, BOOST_ROOT should have no effect. What kind of errors do you get?

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

Can you tell some things:
1. Have you built bjam?
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

TIA,
Volodya