Re: [FYI] Cleanup of linux pass_all

[Alexandre Oliva]

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.

Ideally, we'd have an additional method that would attempt a link a
shared library and, if that errors out, we build only the static
version of the library, as if file_magic had gone through all libs and
failed to find an appropriate library.

However, we'd still need an additional method for the platforms that
fail to issue errors on e.g. overflows.

> While this patch isn't *quite* in the spirit of the option,

It actually renders the option useless.  Might as well remove it
completely and just let the linker error out for the user, rendering
the libtool abstraction useless in the process.

> it produces correct results across all 13,000 packages we've tried.
> Reverting it breaks well over half of the architectures.

For some definition of correct.

Listing a non-shared library as a dependency of a libtool library is
not the right approach to create a shared library with libtool.
Although it works on some platforms, it doesn't on others, so packages
that do this are making unwarranted assumptions, and the fact that
they break is just exposing this flaw in them.  It's very unfortunate
that x86, the most widely used platform, doesn't require PIC in shared
libraries, otherwise people would know better.  Nevertheless, IMHO the
right approach is not to break libtool to cope with the brokenness of
packages that mis-use it; I'd rather have the packages fixed.

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.

At least this was the way it was designed to work.  If you folks now
in charge of the project want to change this design, and modify the
API correspondingly, I guess it's your call.  I won't get it the way.
But arguing that it's the right thing because 13000 didn't break with
the change, and even papered over some errors in many of these
packages.   13000 wrongs don't make a right.

I realize you're trying to be pragmatic here, and trying to find the
simplest solution for the big problem at hand, but I don't think
that's the right way to run a project.  You should think of the
libtool design first, and then try to get packages to use it properly,
instead of forcing libtool to bend backwards to support abuses from
packages that should have known better.  While some of these packages
might not actually be broken, others will be, and with this change
users may get confused and blame libtool for an error that is actually
theirs.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}