Re: [FYI] Cleanup of linux pass_all

[Jacob Meuser]

On Sat, Sep 11, 2004 at 04:24:56AM -0300, Alexandre Oliva wrote:
> On Sep  8, 2004, Scott James Remnant <address@hidden> wrote:
> 
> > The alternative method (file) isn't reliable enough, and consistently
> > fails for huge numbers of shared libraries (such as GTK+).
> 
> How does it fail in the cases you have in mind?
> 
> I agree file is not ideal, but trying to create a shared library out
> of non-PIC is a very bad idea on platforms that don't support it, and
> generating an error is probably not the best libtool can do.

Is there any tool that can determine if an object is PIC?

> It's very unfortunate
> that x86, the most widely used platform, doesn't require PIC in shared
> libraries, otherwise people would know better.

use Open or NetBSD, they need PIC for shared objects on x86 too.

> 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.

yes, but what if a dependency comes from somewhere other than the
package being built.  libtool has no way to know if a static lib
on a system is PIC or not.  (well, NetBSD and OpenBSD have a
convention for that, libfoo_pic.a, and libtool uses a third option
for deplibs_check_method, "match_pattern", matching valid lib names
by regex)

> I realize you're trying to be pragmatic here, and trying to find the
> simplest solution for the big problem at hand,

if there was only a good way to test for PIC ....

-- 
<address@hidden>