Re: Should .a library contains non-reallocatable code?
* Jeff Epler <jepler@unpythonic.net> [150220 00:19]:
> Here are two scenarios where building a static library (libfoo) with
> -fPIC is desirable:
>
> * libbar has a stable API, so it should be shipped as a .so,
> but if it links libfoo.a, and libfoo.a is not -fPIC, then
> libbar has to be shipped as a a static library too
This is wrong. If libbar.so needs libfoo.a then libfoo.a does not
need to be PIC:
echo 'int foo(void) {return 17;}' > foo.c
echo 'int bar(void) {return foo();}' > bar.c
echo 'int main() {return bar();}' > main.c
gcc -c -Wall foo.c
ar rs libfoo.a foo.o
gcc -shared -fPIC -Wall bar.c -o bar.so
gcc -Wall main.c -L. -lbar -lfoo
./a.out
echo $?
works just fine.
> * foomodule is a Python wrapper for libfoo, so it must be shipped
> as a .so, but if it links libfoo.a, and libfoo.a is not -fPIC,
> it is not possible to build foomodule at all
That is indeed the case. Note that simply compiling it with -fPIC might
not be enough here. As you need to include the actual library in the
module, this might mean you might end up with multiple copies of the
library, which might also mean multiple copies of any data it has or
with different versions of the same library in the same executeable
(and you cannot really have symbol versioning with a static library).
(If the wrapper is nor for the library itself (but only a library used
by that) this makes it quite dangerous. On the other hand it is a
wrapper for a library depending on an other yet-too-immature-to-have-a-.so
library, so it's quite safe to assume it is so experimental having a
python wrapper makes not much sense anyway.
If the python wrapper is for the library, than an _pic.a only is needed
if that wrapper is not generated by the same source package).
> Unless the circumstances of libfoo make these scenarios unlikely, it
> seems like it is better for other packages to prefer -fPIC even when
> building a static library.
>
> I wonder whether these scenarios were considered when the Policy was
> written.
Static libraries have many serious drawbacks (there are copies in many
programs, so every fix needs a recompile-orgy, multiple copies waste
more RAM, no built-in inter-library-dependencies, ...) and since then
even gotten more (headers if libraries the .a uses (like libc, ...) are
used at compile time, but they are only attached to symbol versions once
the .a in linked into something, so they might not match the headers,
...) since then.
Once something is actually used by other things it is really a good
idea to provide a dynamic library. (And conversely, if something is
not yet able to provide a dynamic library, this is a very good point
to be made against including anything using it).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Reply to: