Should .a library contains non-reallocatable code?
- To: debian-devel@lists.debian.org
- Subject: Should .a library contains non-reallocatable code?
- From: Dmitry Katsubo <dma_k@mail.ru>
- Date: Sat, 14 Feb 2015 13:31:04 +0100
- Message-id: <[🔎] 54DF4008.20707@mail.ru>
- In-reply-to: <54C27A56.6040904@gnu.org>
- References: <54A1AA84.4080103@mail.ru> <20141230041059.GA84060@gmail.com> <54A408B4.9000506@mail.ru> <20150106215407.GA21042@gmail.com> <54B13989.4020002@mail.ru> <CAEGbG9GaBNar1gub02fQwnpM6fS-XFNMh3=qg-VjA6jV2eYXoQ@mail.gmail.com> <54C27A56.6040904@gnu.org>
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
Reply to: