Re: New libtool is in the GCC and Src trees.

[Charles Wilson <libtool@cwilson.fastmail.fm>]

[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.

--
Chuck

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?