New libtool is in the GCC and Src trees.

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

New libtool is in the GCC and Src trees.

Steve Ellcey
The GCC and src trees have been updated with the new libtool.  Let me
know if you run into problems.

Steve Ellcey
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Steve Ellcey
> The GCC and src trees have been updated with the new libtool.  Let me
> know if you run into problems.
>
> Steve Ellcey
> [hidden email]

Some of the regenerated files did not get checked in to the src tree.  I
think the GCC tree is OK.  I will be checking them in shortly.

Steve Ellcey
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Steve Ellcey
> > The GCC and src trees have been updated with the new libtool.  Let me
> > know if you run into problems.
> >
> > Steve Ellcey
> > [hidden email]
>
> Some of the regenerated files did not get checked in to the src tree.  I
> think the GCC tree is OK.  I will be checking them in shortly.
>
> Steve Ellcey
> [hidden email]

Everything should be OK now, my test build with a fresh checkout looks
good.  (Famous last words.)

Steve Ellcey
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Andreas Tobler
In reply to this post by Steve Ellcey
Steve Ellcey wrote:
> The GCC and src trees have been updated with the new libtool.  Let me
> know if you run into problems.

gcc builds fail on Darwin. Attached a patch which cures the issue.
Also, I'm analyzing the build failure in libjava, seems you forgot to
regen the part in classpath.

Ok?

Thanks,
Andreas

2007-05-24  Andreas Tobler  <[hidden email]>

        * ltmain.sh: Fix Darwin verstring, remove ${wl}.


Index: ltmain.sh
===================================================================
--- ltmain.sh   (revision 125036)
+++ ltmain.sh   (working copy)
@@ -4794,7 +4794,7 @@
           versuffix="$major.$age.$revision"
           # Darwin ld doesn't like 0 for these options...
           minor_current=`expr $current + 1`
-         verstring="${wl}-compatibility_version ${wl}$minor_current
${wl}-current_version ${wl}$minor_current.$revision"
+         verstring="-compatibility_version $minor_current
-current_version $minor_current.$revision"
           ;;

         freebsd-aout)
Reply | Threaded
Open this post in threaded view
|

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

Steve Ellcey
> gcc builds fail on Darwin. Attached a patch which cures the issue.
> Also, I'm analyzing the build failure in libjava, seems you forgot to
> regen the part in classpath.
>
> Ok?
>
> Thanks,
> Andreas

ltmain.sh is part of the new libtool, do you know if the ToT libtool has
this fixed?

I am not sure what happened with libjava.  I ran

        aclocal -I . -I .. -I ../config;automake;autoconf

in the libjava directory.  That regenerated the top level configure
script and the Makefile.in files in the gcj, include, and testsuite
subdirs.  I don't know why it didn't do anything to the classpath
subdir.

Steve Ellcey
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Mike Stump
In reply to this post by Andreas Tobler
On May 24, 2007, at 1:01 PM, Andreas Tobler wrote:
> Steve Ellcey wrote:
>> The GCC and src trees have been updated with the new libtool.  Let me
>> know if you run into problems.
>
> gcc builds fail on Darwin. Attached a patch which cures the issue.

> Ok?

Ok.  This is fine, as I think all the uses in gcc just use the built  
compiler, so it is safe.  For other packages that don't include a  
compiler, I suspect the patch might break compiles on older systems.
Reply | Threaded
Open this post in threaded view
|

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

Andreas Tobler
In reply to this post by Steve Ellcey
Steve Ellcey wrote:

>> gcc builds fail on Darwin. Attached a patch which cures the issue.
>> Also, I'm analyzing the build failure in libjava, seems you forgot to
>> regen the part in classpath.
>>
>> Ok?
>>
>> Thanks,
>> Andreas
>
> ltmain.sh is part of the new libtool, do you know if the ToT libtool has
> this fixed?

Don't know yet, I'll check tomorrow. I'm happy if my stable 1.5.22
version does not go mad.

>
> I am not sure what happened with libjava.  I ran
>
> aclocal -I . -I .. -I ../config;automake;autoconf
>
> in the libjava directory.  That regenerated the top level configure
> script and the Makefile.in files in the gcj, include, and testsuite
> subdirs.  I don't know why it didn't do anything to the classpath
> subdir.

You should read the HACKING:77ff inside libjava for how to go on for
classpath.
Although, I tried to do it the way as described there and did not
succeed (but I'm on Darwin and this is a bit special). I hope Tom has a
bit more insight and can explain what's missing.

I'm on the run to bed, late night here.

Thanks for your effort, Steve.

Regards,
Andreas



Reply | Threaded
Open this post in threaded view
|

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

Charles Wilson-6
In reply to this post by Steve Ellcey

On Thu, 24 May 2007 13:32:54 -0700 (PDT), "Steve Ellcey"
<[hidden email]> said:
> > gcc builds fail on Darwin. Attached a patch which cures the issue.
> > Also, I'm analyzing the build failure in libjava, seems you forgot to
> > regen the part in classpath.
>
> ltmain.sh is part of the new libtool, do you know if the ToT libtool has
> this fixed?

No, it does not.
http://cvs.savannah.gnu.org/viewvc/libtool/libltdl/config/ltmain.m4sh?annotate=1.75&root=libtool
see line 4968

However, wasn't the point of using ToT libtool: to _avoid_ haring off
with quick-n-dirty [*] local patches -- in effect, forking libtool?
Instead of fixing gcc's local copy, shouldn't this fix -- or a better
one -- instead be submitted to libtool, and then gcc can resync?  (At
least in the medium-to-long term.  For an immediate and temporary fix
for a broken build, as long as it IS temporary...)

[*] As Mike pointed out, the proposed change is not compatible with
older compilers.

--
Chuck
Reply | Threaded
Open this post in threaded view
|

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

Mike Stump
On May 24, 2007, at 2:14 PM, [hidden email] wrote:
> Instead of fixing gcc's local copy, shouldn't this fix -- or a  
> better one -- instead be submitted to libtool, and then gcc can  
> resync?  (At least in the medium-to-long term.  For an immediate  
> and temporary fix for a broken build, as long as it IS temporary...)

I agree.  I'm happy to have the hack in gcc so that we don't have gcc  
not building and testing for the next month, but really, those  
options should work on the compiler.  If someone is passing them to  
the linker, well, that's wrong.  If to the compiler, I don't quite  
see what went wrong, and no one said what went wrong.  Cleaverly, I  
was waiting on other recent breakages to go away before updating, so  
I didn't see what went wrong.
Reply | Threaded
Open this post in threaded view
|

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

Andrew Pinski-3
In reply to this post by Steve Ellcey
On 5/24/07, Steve Ellcey <[hidden email]> wrote:
> The GCC and src trees have been updated with the new libtool.  Let me
> know if you run into problems.

And this breaks libobjc building libobjc.a and/or libobjc.so because
we now build libobja.a which is wrong.  This patch fixes the problem.

Committed after a bootstrap and tested on i686-linux-gnu with no
regressions and build and tested for spu-elf with no regressions.

Thanks,
Andrew Pinski

libobjc/ChangeLog:
* Makefile.in: Remove all uses of $(libext).

fixlibobjc.diff.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andreas Tobler
In reply to this post by Mike Stump
Mike Stump wrote:

> On May 24, 2007, at 2:14 PM, [hidden email] wrote:
>> Instead of fixing gcc's local copy, shouldn't this fix -- or a better
>> one -- instead be submitted to libtool, and then gcc can resync?  (At
>> least in the medium-to-long term.  For an immediate and temporary fix
>> for a broken build, as long as it IS temporary...)
>
> I agree.  I'm happy to have the hack in gcc so that we don't have gcc
> not building and testing for the next month, but really, those options
> should work on the compiler.  If someone is passing them to the linker,
> well, that's wrong.  If to the compiler, I don't quite see what went
> wrong, and no one said what went wrong.  Cleaverly, I was waiting on
> other recent breakages to go away before updating, so I didn't see what
> went wrong.
>

/head/testbin-single/lib/libltdl.3.dylib -Wl,-compatibility_version
-Wl,5 -Wl,-current_version -Wl,5.1
/usr/bin/ld: unknown flag: -compatibility_version
collect2: ld returned 1 exit status

And Paolo, your suggestion doesn't work. Same error.

So, do I follow correctly to put my patch into ltmain.sh on gcc?

I just want to unbreak gcc bootstrap.

Oh, and have a look into ltmain.sh on 4.2 branch... ok, I guess I put it
in, but when I did that I synced from libtool cvs back in 03.

Andreas
Reply | Threaded
Open this post in threaded view
|

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

Paolo Bonzini

> /head/testbin-single/lib/libltdl.3.dylib -Wl,-compatibility_version
> -Wl,5 -Wl,-current_version -Wl,5.1
> /usr/bin/ld: unknown flag: -compatibility_version
> collect2: ld returned 1 exit status
>
> And Paolo, your suggestion doesn't work. Same error.
>
> So, do I follow correctly to put my patch into ltmain.sh on gcc?

Go ahead (gcc and src), remembering it is a temporary measure.

Peter said he'd look at it in the weekend. (I'll be offline for the
whole weekend instead)

Paolo
Reply | Threaded
Open this post in threaded view
|

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

Eric Christopher-2
>
> Go ahead (gcc and src), remembering it is a temporary measure.

Agreed.

>
> Peter said he'd look at it in the weekend. (I'll be offline for the  
> whole weekend instead)

Peter and I exchanged email about it last night.

-eric
Reply | Threaded
Open this post in threaded view
|

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

Steve Ellcey
In reply to this post by Steve Ellcey
Tom Tromey wrote:

> The failure looks like:
>
>     configure: loading cache .././config.cache
>     configure: error: `CXXFLAGS' has changed since the previous run:
>     configure:   former value:  -g -O2  -D_GNU_SOURCE
>     configure:   current value: -g -O2 -D_GNU_SOURCE
>     configure: error: changes in the environment can compromise the build
>     configure: error: run `make distclean' and/or `rm .././config.cache' and start over
>     configure: error: /bin/sh '../../../../trunk/libjava/classpath/configure' failed for classpath

Paolo,

What do you think about putting the confsubdir.m4 macro in the config
directory (in GCC and src) to fix this problem?  We would also have to
regenerate the configure scripts, we could either do that proactively or
let it happen as people run into the problem and/or as people regen the
configure scripts for other reasons.

The confsubdir.m4 macro can be found here:

        http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01320.html

Steve Ellcey
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Andreas Tobler
In reply to this post by Paolo Bonzini
Paolo Bonzini wrote:

>
>> /head/testbin-single/lib/libltdl.3.dylib -Wl,-compatibility_version
>> -Wl,5 -Wl,-current_version -Wl,5.1
>> /usr/bin/ld: unknown flag: -compatibility_version
>> collect2: ld returned 1 exit status
>>
>> And Paolo, your suggestion doesn't work. Same error.
>>
>> So, do I follow correctly to put my patch into ltmain.sh on gcc?
>
> Go ahead (gcc and src), remembering it is a temporary measure.

Ok, done on gcc. Looking for a helper on src. Or is it time to request
src access ?
>
> Peter said he'd look at it in the weekend. (I'll be offline for the
> whole weekend instead)

Thank you,
Regards,
Andreas
Reply | Threaded
Open this post in threaded view
|

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

Eric Christopher-2

On May 25, 2007, at 12:33 PM, Andreas Tobler wrote:

> Paolo Bonzini wrote:
>>> /head/testbin-single/lib/libltdl.3.dylib -Wl,-
>>> compatibility_version -Wl,5 -Wl,-current_version -Wl,5.1
>>> /usr/bin/ld: unknown flag: -compatibility_version
>>> collect2: ld returned 1 exit status
>>>
>>> And Paolo, your suggestion doesn't work. Same error.
>>>
>>> So, do I follow correctly to put my patch into ltmain.sh on gcc?
>> Go ahead (gcc and src), remembering it is a temporary measure.
>
> Ok, done on gcc. Looking for a helper on src. Or is it time to  
> request src access ?

I'll commit. Though if you'd like and have a need for src access  
lemme know.

-eric



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab
In reply to this post by Steve Ellcey
Steve Ellcey <[hidden email]> writes:

> 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.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab
In reply to this post by Steve Ellcey
Steve Ellcey <[hidden email]> writes:

> The GCC and src trees have been updated with the new libtool.  Let me
> know if you run into problems.

All the generated aclocal.m4 files contain a copy of an old libtool.m4.

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

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

Charles Wilson-6
In reply to this post by Andreas Schwab
[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?
Reply | Threaded
Open this post in threaded view
|

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

Peter O'Gorman
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