* Ian Jackson <ijack...@chiark.greenend.org.uk> [150224 18:51]:
> Right. I think that the right answer to this, in these cases, is
> either to use an explicit symbol export file or to adjust the link
> command lines.
"adjust the link command lines" ? That's like saying the mine field
is safe because people will know which way through it is safe (at least
the second time they pass).
Creating multiple copies by creating shared libraries that merge
the static library in so that might end up multiple times in the same
library, and in a way they leak those implementation and might override
even things in programs linking against that library is at best a gross
hack, at worst a disaster waiting to happen.
"explicit symbol export file"
While this might be possibly avoid problems, it is quite a hard thing to
do. As there needs to be the default to hide everything (unless you
assume a library author incapabable of managing a ABI on the one hand
but able to properly make all symbols match some easy pattern) you
need an explicit whitelist one what you export from the merged library.
And in both cases you still have the problem that you have object code
copies in other packages, including all the problems like the need to
keep multiple source versions around, security updates being quite a
hassle, needing more memory if that code ends up in multiple libraries
and so on. (Not to speak of all the other problems of static libraries,
like breaking the versioning of symbols used from other libraries and
stuff like that).
Compare that to the straightforward case of just building a dynamic
instead of a static library with some simple:
printf 'LIBFOO_0.'$REVISION' {\n global:\n *\n};\n' > foo.map
gcc --shared -Wl,--version-script=foo.map -Wl,--soname libfoo.so.0.${REVSION}
-o libfoo.so.0.${REVSION} ...
ln -s libfoo.so.0.${REVSION} libfoo.so
which also gives you all the advantages of not having needlessly
multiple copies of the same version of the compile code around
and get all the other goodies (like automatic tracking where it is
used and which what version and being able to do a security update
without recompiling anything but that library).
So I really do not see what advantage in that case PIC code in the .a
file has, while not having it there avoids many possible mistakes.
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150226230057.ga3...@client.brlink.eu
