On Tue, 29 May 2007 12:36:13 -0600, "Tom Tromey" said: > >>>>> "Charles" == Charles Wilson writes: > Charles> Secondly, the entire contents of libjava/libltdl/ need to be > Charles> updated. > > I don't think we need to do this. libgcj uses libltdl primarily as a > portable wrapper for dlopen. As such it works just fine as is.
Well, it /did/ -- until the new-libtool merge. Now there seem to be build problems. So /something/ needs fixin'. <g> > Also, > libgcj has some local libltdl patches as well. Then they should be submitted upstream -- if they are still necessary. There have been a lot of improvements in libltdl since 1.4.x and even 1.5.x. > Why do you think it should be updated? Because unless I am very mistaken, new libtool.m4 + old ltdl.m4(&other old libltdl stuff) is not a tested/supported configuration -- it /may/ work, but... Will aclocal pull in the the old libtool.m4 (perhaps from /usr/share/aclocal/ if it can't find one with the required serial number closer at hand?) at the request of the old ltdl.m4? Will it instead complain about serial number mismatch? Will libjava/aclocal.m4 end up with both/conflicting versions of various LT macros, or worse a hodgepodge of some LT macros from old libtool.m4 and some from new libtool.m4? Or will libjava/aclocal get only new libtool.m4 LT macros, but not define some of the (old) ones that old ltdl.m4 relies on? I don't know the answers to these questions -- but I do know that new libtool.m4 + new libltdl stuff has a pretty thorough test suite. I hate to say this, but perhaps, for now: (1) the libjava/ portions of Steve's patch should be backed out (2) local copies of what USED to be in <toplevel> put into libjava/ (3) libjava's configure.ac and Makefile.am's modified again to NOT look in <toplevel> (4) re-auto* in libjava/* just so that libjava can get back to status quo ante. Because it looks like there really is a whole lot of work left to be done before libjava is ready to use the new libtool, thanks to the overlooked use of libltdl. -- Chuck
