On Wed, 2004-09-15 at 14:55 -0300, Alexandre Oliva wrote: > On Sep 13, 2004, Scott James Remnant <email@example.com> wrote: > > > 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. > Actually you'd probably get a link failure, or at least cause one later on, unless you're really unlucky in which case you'd get some nasty runtime error. Thus you're effectively abandoning the abstraction in favour of causing errors later on. I'm all for having Libtool tell you that you can't link non-PIC code into a shared library on platforms that don't support that -- but that needs to be done by actually checking you're trying to do that, rather than using an incorrect assumption. > > 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. > This wouldn't get very far ... as soon as you have to do things specially for Libtool just to link against things like X, it's doomed. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Description: This is a digitally signed message part