From: Peter O'Gorman <peter@pogma.com>
To: Charles Wilson <libtool@cwilson.fastmail.fm>
Cc: Andreas Schwab <schwab@suse.de>,
bonzini@gnu.org, Steve Ellcey <sje@cup.hp.com>,
Libtool Patches <libtool-patches@gnu.org>,
newlib@sourceware.org, aoliva@redhat.com,
gcc-patches@gcc.gnu.org, binutils@sourceware.org,
jjohnstn@redhat.com, gdb-patches@sourceware.org
Subject: Re: New libtool is in the GCC and Src trees.
Date: Tue, 29 May 2007 01:25:00 -0000 [thread overview]
Message-ID: <1180401895.24863.56.camel@acer> (raw)
In-Reply-To: <465B2843.1060405@cwilson.fastmail.fm>
On Mon, 2007-05-28 at 15:06 -0400, Charles Wilson wrote:
> [libtool-patches: please render assistance...SOS!]
> 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.
With the new libtool `libtoolize --copy --ltdl --subproject', should
give you a libltdl directory that is ready to go. It will also include
all the necessary m4 files etc in its m4 subdir. I guess gcc will want
to rm at least the libtool.m4 in there and use the one at the top level.
What Gary has been doing recently, and it may very well affect libjava,
is to allow the client to choose, if the OS allows it, to load
RTLD_LOCAL or RTLD_GLOBAL. The default in libtool-1.5 was RTLD_GLOBAL,
so that is likely what libjava is using now, the default changed for the
development branch to RTLD_LOCAL. The recent changes add api to let the
client choose.
I would consider using the libltdl from the 1.5 branch, even if that
means adding all the required m4, including the 1.5 libtool.m4 to the
libltdl subdir in gcc, this would insulate you from any changes to
libltdl that may be made during development of libtool.
Or maybe Gary will pipe up and say "finished, nothing else will
change!". Gary?
Peter
next prev parent reply other threads:[~2007-05-29 1:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-24 17:35 Steve Ellcey
2007-05-24 18:07 ` Steve Ellcey
2007-05-24 18:46 ` Steve Ellcey
2007-05-24 20:02 ` Andreas Tobler
2007-05-24 20:33 ` Steve Ellcey
2007-05-24 21:09 ` Andreas Tobler
2007-05-24 21:14 ` libtool
2007-05-24 22:13 ` Mike Stump
2007-05-25 17:38 ` Andreas Tobler
2007-05-25 17:43 ` Paolo Bonzini
2007-05-25 17:50 ` Eric Christopher
2007-05-25 19:33 ` Andreas Tobler
2007-05-25 19:39 ` Eric Christopher
2007-05-24 20:37 ` Mike Stump
2007-05-25 0:12 ` Andrew Pinski
2007-05-28 12:49 ` Andreas Schwab
2007-05-28 19:07 ` Charles Wilson
2007-05-29 1:25 ` Peter O'Gorman [this message]
2007-05-28 13:33 ` Andreas Schwab
[not found] <m3irah6d45.fsf@fleche.redhat.com>
2007-05-25 18:21 ` Steve Ellcey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1180401895.24863.56.camel@acer \
--to=peter@pogma.com \
--cc=aoliva@redhat.com \
--cc=binutils@sourceware.org \
--cc=bonzini@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jjohnstn@redhat.com \
--cc=libtool-patches@gnu.org \
--cc=libtool@cwilson.fastmail.fm \
--cc=newlib@sourceware.org \
--cc=schwab@suse.de \
--cc=sje@cup.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox