This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]