Re: Should .a library contains non-reallocatable code?
* Russ Allbery <rra@debian.org> [150222 21:51]:
> "Bernhard R. Link" <brlink@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
Reply to: