[Top][All Lists]
[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