Patch to update libtool in GCC and Src trees
Charles Wilson
libtool@cwilson.fastmail.fm
Wed May 16 13:22:00 GMT 2007
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
More information about the Newlib
mailing list