Bernhard R. Link writes ("Re: Should .a library contains non-reallocatable
code?"):
> Compare that to the straightforward case of just building a dynamic
> instead of a static library with some simple:
No-one is proposing that shared libraries should not be built, and
used, when possible. We are only discussing here the case where
building a shared library is not feasible for some reason.
The most common reason is that the shared library has no stable ABI:
that is, upstream make API changes willy-nilly. In that case ...
> 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
... this approach will lead to ABI-change-related breakage.
> 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.
As I said on Monday:
I should say that I agree with the conclusions of others in this
thread, that policy's rules about -fPIC for static libraries are
wrong.
Where only a static library is provided, it should be built _with_
-fPIC unless it is expected never to be included in any shared object
(which is probably hard to predict, but I guess there might be cases
where the maintainer might know).
Where a .so is provided too then the static library is normally used
only in cases where no dynamic linking is done at all, and then
-fPIC is probably undesirable. This is of course the usual case.
Ian.
--
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/21744.36780.425320.779...@chiark.greenend.org.uk
