From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-08 10:31:17
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.
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?
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 ;-)
--Boundary-00=_FfX//pVY7UZPwaf Content-Type: text/plain;
Consider the case where "main" linkigs to "libA.so" which links to "libB.so".
The references from "libA.so" to symbols in "libB.so" will be resolved at
runtime by dynamic linkder. GNU ld mimics the
behaviour of dynamic linkder to make sure unresolved symbols don't occur at
Which means there are two choices:
1. Add -rpath-link options for all used libraries (including libB.so), so that
linker can make sure all references will be resolved at runtime.
2. Use --unresolved-symbols=ignore-in-shared-lib. In this case I need to
specify by to libB.so, but linker won't be able to detect unresolved symbols,
so I might get error at runtime.
More details can be found in
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