Re: Should .a library contains non-reallocatable code?
On 23/02/2015 19:17, Ian Jackson wrote:
> Ian Jackson writes ("Re: Should .a library contains non-reallocatable code?"):
>> Jeff is correct.
> ...
>> That not usually a problem. Providing that only the relevant symbols
>> are exported from the .so, the executable simply results in multiple
>> completely independent copies of the static library.
> 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.
>
>
I agree with this; are there any cases where only a static library _is_
provided, and if so why? why not provide a .so?
The original examples are only problematic because they are linked
to a static .a rather than .so.
In my packages I always provide a -fPIC .so and non-fPIC .a library,
the latter for performance where it matters (these days typically slight).
regards
Alastair
--
Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
Reply to: