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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-09 06:08:39

Christopher Currie wrote:

> > I'd very appreciate if someone can answer two questions above. I looks
> > like some persons on this list has used V2 + gcc + solaris linker, so
> > they might know the answers right away.
>
> This is the configuration I'm using for gcc, so I'll take a stab...

Thanks!

> > 1. The docs on Sun site say:
> >
> > Although the link-editor makes multiple passes through an archive to
> > resolve symbols, this mechanism can be quite costly for large archives
> > containing random organizations of relocatable objects. In these cases
> > you can use tools like lorder(1) and tsort(1) to order the relocatable
> > objects within the archive and so reduce the number of passes the
> > link-editor must carry out.
> >
> > Is this really the case? Was this behaviour introduced long enough for us
> > to assume it exists for all version of Solaris linkers now in use?
>
> These tools do exist; I'd not heard of them before, so I can't attest as
> to the effect that they'll have on link times. The typical usage they
> recommend is something like:
>
> ar -rc lib.a `lorder *.o | tsort`
>
> which purports to find the optimum sorting order *within the context of
> a single library* so it doesn't have to read itself multiple times to
> resolve its own references. (i.e. this technique is not for inter-lib
> dependencies). All it really does is reorder the library list for
> efficiency, so I assume the technique would be equally useful for shared
> libraries. I can make this change locally and run some time tests
> building and linking against boost libraries, if feel it's necessary.

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?

> > 2. Does the Solaris linker has an equivalent of GNU's --rpath-link
> > option? Just in case you don't know what GNU option does, I attach my
> > notes on it -- which really were not that easy to get ;-)
>
> I'm very confused about the use and purpose of -rpath-link. It seems to
> be the equivalent of -L, but only for the purposes of searching for
> undefined symbols between shared libraries, and it also guarantees the
> path to be searched first. For this, no, Solaris LD does not have an
> equivalent; -L is your only option.

Ok.

> The email you referenced seemed to want to *not* use -rpath-link, but
> instead have it ignore the undefined symbol w.r.t. the shared library.
> Much of the remainder of the thread discusses how to implement this in
> binutils, as it appears that even gnu ld didn't handle this at the time.
> In this, the only option is to add "-z nodefs" to allow undefined
> symbols in the executable.

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.

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
}

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. 

- Volodya