This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: New libtool is in the GCC and Src trees.
- From: libtool at cwilson dot fastmail dot fm
- To: "Steve Ellcey" <sje at cup dot hp dot com>, toa at pop dot agri dot ch
- Cc: jjohnstn at redhat dot com, bonzini at gnu dot org, newlib at sourceware dot org, aoliva at redhat dot com, gcc-patches at gcc dot gnu dot org, gdb-patches at sourceware dot org, binutils at sourceware dot org
- Date: Thu, 24 May 2007 17:14:30 -0400
- Subject: Re: New libtool is in the GCC and Src trees.
- References: <200705242032.NAA13355@hpsje.cup.hp.com>
On Thu, 24 May 2007 13:32:54 -0700 (PDT), "Steve Ellcey"
<sje@cup.hp.com> said:
> > gcc builds fail on Darwin. Attached a patch which cures the issue.
> > Also, I'm analyzing the build failure in libjava, seems you forgot to
> > regen the part in classpath.
>
> ltmain.sh is part of the new libtool, do you know if the ToT libtool has
> this fixed?
No, it does not.
http://cvs.savannah.gnu.org/viewvc/libtool/libltdl/config/ltmain.m4sh?annotate=1.75&root=libtool
see line 4968
However, wasn't the point of using ToT libtool: to _avoid_ haring off
with quick-n-dirty [*] local patches -- in effect, forking libtool?
Instead of fixing gcc's local copy, shouldn't this fix -- or a better
one -- instead be submitted to libtool, and then gcc can resync? (At
least in the medium-to-long term. For an immediate and temporary fix
for a broken build, as long as it IS temporary...)
[*] As Mike pointed out, the proposed change is not compatible with
older compilers.
--
Chuck