Re: Should .a library contains non-reallocatable code?
"Bernhard R. Link" <brlink@debian.org> writes:
> * Russ Allbery <rra@debian.org> [150222 21:51]:
>> 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.
Oh, you're talking about leaving symbols unresolved in the shared library
and requiring that the binary link with both the shared library and some
static library at build time?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: