[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Should .a library contains non-reallocatable code?



* Ian Jackson <ijackson@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


Reply to: