This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Final(?) patch to update libtool in GCC and src trees
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: bonzini at gnu dot org
- Cc: binutils at sourceware dot org, gcc-patches at gcc dot gnu dot org, gdb-patches at gcc dot gnu dot org, newlib at sourceware dot org, Ralf dot Wildenhues at gmx dot de, aoliva at redhat dot com, fxcoudert at gmail dot com, libtool at cwilson dot fastmail dot fm, schwab at suse dot de
- Date: Fri, 13 Apr 2007 10:07:35 -0700 (PDT)
- Subject: Re: Final(?) patch to update libtool in GCC and src trees
> The patch is preapproved with those changes, but please post it again.
Just to be clear, this approval is for both the GCC and the Src tree
right?
> > Top level src tree ChangeLog:
> >
> > 2007-03-22 Steve Ellcey <sje@cup.hp.com>
> > * src-release: Update with new libtool file list.
>
> Obviously leave this out for now too, and keep config-ml.in in sync
> between gcc and src.
OK, If the config-ml.in change works with the old libtool I will make
the change in both trees. Otherwise I will leave them both alone.
> > bfd/ChangeLog
> > 2007-03-22 Steve Ellcey <sje@cup.hp.com>
> > * configure.in: Change macro call order.
> > * aclocal.m4: Regenerate.
> > * Makefile.in: Regnerate.
> > * configure: Regenerate.
>
> Here, please add -I .. to Makefile.am's ACLOCAL_AMFLAGS instead of
> modifying acinclude.m4.
That seems like a good idea. I did the change with sinclude because the
src tree seemed to use sinclude's instead of ACLOCAL_AMFLAGS. If I am
adding ACLOCAL_AMFLAGS should I add -I ../config and -I ../bfd too and
remove all the sinclude statements from the acinclude.m4 scripts?
My plan is to make the changes you want, test with the new libtool to
make sure that works, then revert to the old libtool, retest, and check
in the changes when that works. It may take a few days.
Steve Ellcey
sje@cup.hp.com