* Ian Jackson <ijack...@chiark.greenend.org.uk> [150227 16:39]:
> 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.
How do you think this can lead to breakage that your suggestion to merge
the static library into the dynamic library using it can not?
> 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).
If you change that to "unless it is expected to never be
included in any shared object correctly." you get the current policy.
Because I can hardly think of a shared library for which that is not
expected.
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/20150227183331.ga2...@client.brlink.eu
