* Russ Allbery <r...@debian.org> [150222 21:51]: > "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.
You are speaking about linking .a helper libraries into a shared object. I'm about the case that a shared library has a dependency on a different static library instead. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- 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/20150224015905.gb2...@client.brlink.eu