Re: Patch to update libtool in GCC and Src trees

[Charles Wilson <libtool at cwilson dot fastmail dot fm>]

Paolo Bonzini wrote:
> > (3) Should the configure.in's be changed to use the 'modern' libtool 
> > initialization macro LT_INIT([shared static win32-dll]) -- which will 
> > need to be committed simultaneously or as an integral part of Steve's 
> > update; or should they instead continue to use the old 
> > 'AC_LIBTOOL_WIN32_DLL; AM_PROG_LIBTOOL' macros?
>
> I prefer to do this one step at a time, because it applies to other 
> libraries too.

OK. I'll regen the configure.in patch that way.

Note1: the conversion from old-style libtool initialization macros to 
new-style can be done on a case-by-case basis after Steve's current 
update is committed; it needn't be an "all-at-once" megapatch.

Note2: I mentioned that switching to the new macros would require making 
the newlib changes atomically with Steve's update of the toplevel 
libtool.m4&friends.  This is a red herring; _LT_DECL_SED is /also/ only 
provided by the new .m4 files.  So we need to make the newlib and 
toplevel changes atomically, regardless of whether the newlib 
configure.in's use old-style libtool initialization macros or new-style.

> > (4) Once these questions are answered: Steve, do you want to 'absorb' 
> > this patch into your update, so it can be committed atomically?
>
> This would be best.  Steve, please post your patch again in reply to 
> this message (I've added back binutils, gdb, and gcc mailing lists) and 
> I'll ok it.

This ^^^ looks like Paolo's answer to question (1) from
http://www.cygwin.com/ml/newlib/2007/msg00542.html
is yes.  I still need an answer to (2), probably from Jeff, and then 
I'll redo my whole 10-step procedure and retest tonight.

Once that's done, I'll send Steve the *entire* set of changes (as 
produced mechanically by the scripts I posted earlier
http://www.cygwin.com/ml/newlib/2007/msg00533.html)
along with ChangeLog entries so he can 'absorb' it.

--
Chuck