I'm working with a software vendor who is currently building ".so"
libraries with impure code (ie. non-PIC). [Explanation below for
anyone interested.]
I've perused the "Linker and Libraries Guide" and I haven't found
any strict prohibition against doing this. However, the software
vendor has hit a few problems (and I've found a few related bug
reports), so I would like to ask for some clarification about what
is "legal" (reasonable) and what isn't.
Questions
---------
1) Ignoring issues of performance or actually even sharing the
library pages, are there technical reasons that non-PIC code can
not be used to build a ".so" library? [This is for 32-bit
SPARC, Solaris 9, Sun Studio 8 and Forte 6 Update 2]
2) Does the answer to this question change for 64-bit SPARC or for
either 32-bit or 64-bit x86?
3) Does the use of "ld -r" to create some of the input objects
change the answer [see note].
4) Could building non-PIC libraries or using "ld -r" on the inputs
cause "silent failures"? By that, I mean incorrectly-executing
code which doesn't cause either "ld" or "ld.so" to generate a
warning/error message.
The bottom-line question is whether they are "safe" in only
insisting on PIC code when the linker complains (and slowly
migrating other libraries to PIC over time).
Thanks very much.
-morgan herrington
Note about use of "ld -r"
-------------------------
The manual page for "ld", when describing the "-r" option, says,
"This option cannot be used in dynamic mode or with -a." However,
it appears that they've used this technique for years in building
the *inputs* to some of their ".so" libraries without previously
observing problems.
Their use is that some groups aggregate a set of objects into a
single ".o" file using "ld -r". Then these aggregated objects are
later combined into a much bigger ".so" file.
Does this violate the "not in dynamic mode" rule? If this is
*does* cause problems, does it fail quietly (for example, with
replicated static data) or would the failures be obvious (for
example, an error from "ld.so")?
Explanation/history for anyone who is interested
------------------------------------------------
This is part of a family of products (from multiple corporate
divisions) which share a large set of libraries.
Previously, they tended to use ".a" archives, but that model had
some problems -- symbol collisions between libraries and long link
times. They're migrating to using map files to reduce the scope of
most symbols (to avoid collisions) and are switching many of the
libraries to be ".so" libraries.
When they build the 64-bit version of their program, they
*sometimes* get link-time errors like the following (reformatted):
ld: fatal:
relocation error: R_SPARC_WDISP30:
file libXXXXXX.o:
symbol some_particular_symbol_XXXX:
value 0x3b30629c does not fit
This looks like the failure signature in some bug reports (for
example, 4129745 and 4141890) except that this comes from "ld"
rather than "ld.so".
When they rebuilt the library (reported above) using "-KPIC", the
problem appeared to go away. Unfortunately, because some of the
libraries come from other divisions (or maybe even other
companies), it's a non-trivial task to rebuild them all.
This message posted from opensolaris.org
