"Bernhard R. Link" <brl...@debian.org> writes:
> 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.
It won't with something more complex on all architectures. I think there
are architectures (i386, maybe?) where you can link non-PIC code into a
shared library with a performance penalty, and (as mentioned by another)
it doesn't matter for code where there's no difference between PIC and
non-PIC. But this will definitely break on some architectures (including
amd64, IIRC).
There's been lots of discussion of this on the Libtool list, and I've had
to deal with this from time to time in various upstream projects where I
wanted to assemble a shared library from various internal helper
libraries. Take a look at all the work that Libtool does to handle
convenience libraries for exactly this reason.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/877fv9r7pr....@hope.eyrie.org
