Some questions on Solaris linker

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

TIA,
Volodya

 --Boundary-00=_FfX//pVY7UZPwaf Content-Type: text/plain;
charset="us-ascii";
name="rpath-link.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="rpath-link.txt"

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

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
http://sources.redhat.com/ml/binutils/2003-08/msg00171.html --Boundary-00=_FfX//pVY7UZPwaf--