libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: libtool
Subject: Re: New libtool is in the GCC and Src trees.
Date: Tue, 29 May 2007 19:33:28 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]