Re: [FYI] Cleanup of linux pass_all
On Sep 13, 2004, Scott James Remnant <scott@netsplit.com> wrote:
> Simply looking at what kind of library you're linking against isn't
> sufficient.
Agreed.
>> Listing a non-shared library as a dependency of a libtool library is
>> not the right approach to create a shared library with libtool.
> What happens when the non-shared library contains PIC code?
If you're lucky, you win.
> What happens when the shared library you're happily linking with
> contains non-PIC code?
It doesn't matter. When you link with a shared library, you only get
the SONAME from it, and we only use its symbol table and additional
dependencies to test for missing symbols. The dependency is not
on that exact version of the shared library; it's on the SONAME alone.
>> The right approach to creating libtool libraries out of archives is to
>> create libtool archives (AKA convenience libraries). This enables
>> libtool to make sure that only PIC is present in the input, and
>> generate a shared library, or to know that non-PIC is present, and
>> refrain from generating a shared library.
> How would it know this when linking against software (X) that doesn't
> use Libtool?
We might offer means for people to create libtool archives out of
static libraries, such that they can indicate whether it is known to
be PIC or non-PIC.
> The error in this case is Libtool's. It refuses to link PIC code into a
> shared library because the test it uses to determine whether code is PIC
> or not doesn't actually do anything of the kind and is based on an
> incorrect assumption (static=non-PIC, shared=PIC).
Agreed.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Reply to: