New libtool is in the GCC and Src trees.
Tue May 29 01:25:00 GMT 2007
[libtool-patches: please render assistance...SOS!]
Andreas Schwab wrote:
>> The GCC and src trees have been updated with the new libtool. Let me
>> know if you run into problems.
> Please also commit the version of ltdl.m4 that you used.
Apologies for not catching this; I /thought/ about asking Steve about
libltdl, but I wasn't aware that anything in gcc used it, so I figured
why dredge up trouble?
Anyway, since something DOES use it, you actually need more than just
ltdl.m4 -- and the mechanisms used to integrate libltdl as a subproject
have changed (well, /expanded/: "subproject" mode which is the mechanism
supported by old libtool, but also, "nonrecursive" and "recursive". In
the latter two cases, the libltdl configury is done by the enclosing
configure script, not as a separate configuration stage. The new modes
differ in how make is invoked).
This transition is going to require some effort -- and since we want to
get this done /fast/ -- broken is /bad/ -- some help from the more
knowledgeable libtool guys would be handy. (I'm copying the
libtool-patches mailing list as an appeal for help).
As I understand it, there are a number of additional .m4 files needed,
as well as additional *.m4sh/.sh files. Whether these should all be
added to <toplevel>/ and <toplevel>/config/ to keep the gcc tree's
libtool stuff together, or if the additional files needed only for
libltdl should be added at the libjava/ level because only libjava uses
libltdl, I don't know.
Secondly, the entire contents of libjava/libltdl/ need to be updated. I
don't think it is The Right Thing, although it may be possible, to build
an old version of libltdl using a new libtool. I'm sure that there has
been NO testing of any interaction between (new) libtool.m4 and (old)
ltdl.m4. The problem is, the libltdl interface has changed (although I
believe it is still backwards compatible) -- and some of those changes
have occurred between 2007-03-18 (the date of gcc's now-current libtool
stuff) and today.
So, before ANY of this work begins, we should decide:
(1) to use 2007-03-18 libtool for everything, including libltdl, and
delay resyncing to more recent libtool until we get stuff stabilized
(2) or combine the libltdl work in libjava with a general repeat of
Steve's merge, updating libtool throughout to a more recent CVS version.
Ordinarily I'd say (1), but as Andreas pointed out there were some
issues with updating the aclocal's -- which means we've got to
re-aclocal/re-automake/re-autoconf again very soon, /anyway/... Plus,
the libtool guys might have something to say about the changes in
libltdl in the last two months that might impact this decision.
P.S. it also looks like libjava/classpath has its very own copy of all
of the libtool stuff.
(1) is this intentional?
(2) should it also be updated to newer libtool
(3) if so, should it then use <toplevel>/'s version instead?
More information about the Newlib