This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [toplevel] Import two libtool patches to simplify AC_DEPLIBS_CHECK_METHOD under Linux.

On Nov 24, 2004, Kelley Cook <> wrote:

> I would like to propose to import these two patches from libtool which
> gets rid of the special casing for Linux dependencies.

I see only one patch in your e-mail, and it happens to be one that
I've fought hard against having integrated in libtool because it's
wrong (*).  Unfortunately, I lost the battle, so it's now in, so in
theory it could go into GCC as well.

The good news is that, as far as GCC is concerned, the patch is
actually correct and beneficial, so feel free to go ahead with it.

(*) libtool needs to distinguish files that can be listed as
dependencies of a shared library from those that can't.  On some
machines, you can link non-PIC into shared libs without errors, and
those are the only ones that can use pass_all.  For all others, you
have to figure out somehow whether a library listed as a dependency is
PIC or not.  The (admittedly bad) heuristics used in libtool on
targets that can't use pass_all (**) is that static archives are not
PIC and so, if you have them listed as a dependency when creating a
libtool library, you'd better avoid trouble and create a static-only
version of the libtool library.  Unfortunately, libgcc.a is often
mismatched by this heuristics, so we lose.

(**) on some platforms, the linker will fail if you try to link
non-PIC into a shared lib; for those, libtool could be extended to
trigger on the linker failure to fallback to the static-only case.  On
others, the linker will silently generate a broken shared lib, so you
have to avoid performing the link, ideally detecting in advance
whether the object files that are going to be brought in from the
static archive might trigger the linker error.  Nobody has ever
stepped up to implement these better mechanisms to handle machines
that can't use pass_all, and have been pushing for the use of pass_all
instead, and then blaming libtool when someone runs into an error that
libtool would have detected and worked around before, but that
translates into a hard link- or run-time error with the proposed

To sum it up: ok, please check it in :-)

Alexandre Oliva   
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]