Should .a library contains non-reallocatable code?

[Dmitry Katsubo <dma_k@mail.ru>]

Dear Debian Developers,

I wonder what is the current state-of-art concerning the code in .a
library (archive for static linking). Should it contain PIC code?

Situation: Dynamic (.so) library needs to be linked against such (.a)
library.

Thank you for any advises and your opinion in advance.

On 23/01/2015 17:44, Antonio Diaz Diaz wrote:
> Hello Alexander and Dmitry,
> 
> Alexander Alemayhu wrote:
>> forwarding a thread I had with Dmitry regarding [#]774164.
>> What do you think?
> 
> Libocrad is available only in static form because it is just a very
> immature hack. Basically I add functions as users ask for them. It meets
> about all the requirements in section 8.3 "Static libraries" of
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> 
> Ocrad itself is very immature. I can't guarantee any stability.
> 
> Moreover, AFAIK, compiling the sources twice (once without PIC for
> CLI and another time with PIC for .a) is not trivial. Different names
> are needed for the two versions of the object files.
> 
> BTW, libocrad.a is *not* used to create ocrad CLI. libocrad.a is just
> ocrad with an incomplete programming interface instead of a CLI.
> 
> 
> Best regards,
> Antonio.
> 
> ---------- Forwarded message ----------
> From: Dmitry Katsubo <dma_k@mail.ru>
> Date: 2015-01-10 15:39 GMT+01:00
> Subject: Re: Bug#774164: libocrad-dev: libocrad.a contains non-reallocatable code
> To: Alexander Alemayhu <alexander.alemayhu@googlemail.com>
> 
> On 06/01/2015 22:54, Alexander Alemayhu wrote:
>> It might take me some time to make a change, because of work.
>> Please also note I have not made Debian libraries before, so it
>> might take me some time to do it properly. If you can't wait and
>> would like to be the change, please send a patch or pull request
>> :)
>>
>> I had a little chat with my neighbour and he had some useful links
>> to share which should give more information on Debian best
>> practices.
>>
>> Thanks.
>>
>> See below:
>>
>> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
>> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-libraries
>
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> 
> Thanks for the links!
> 
> In particular this one:
> 
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#staticonlylibs
> 
> says
>
> "providing -fPIC versions of static libraries for linking with
> shared libraries is a bad sign, because the "unstable interface" is
> now exported through another library's stable library interface",
> which is true, but without -fPIC the resulting shared library is unusable.
> 
> Ideally of course would be that OCRAD is split into light-weight
> command-line and dynamic library library, but I am sure that adds more
> organizational work -- would it be worth? Try to ask the OCRAD
> community if they would be happy to have OCRAD also as dynamic library
> (which can also be wrapped into Perl/Java/etc bridges).
> 
> --
> With best regards,
> Dmitry


-- 
With best regards,
Dmitry