New libtool is in the GCC and Src trees.

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
sje@cup.hp.com

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
> sje@cup.hp.com

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
sje@cup.hp.com

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
> > sje@cup.hp.com
> 
> 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
> sje@cup.hp.com

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

Steve Ellcey
sje@cup.hp.com

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

[Andreas Tobler]

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  <a.tobler@schweiz.org>

	* 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)

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
sje@cup.hp.com

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

[Mike Stump]

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.

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

[Andreas Tobler]

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

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

[libtool]

On Thu, 24 May 2007 13:32:54 -0700 (PDT), "Steve Ellcey"
<sje@cup.hp.com> 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

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

[Mike Stump]

On May 24, 2007, at 2:14 PM, libtool@cwilson.fastmail.fm 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.

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

[Andrew Pinski]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On 5/24/07, Steve Ellcey <sje@cup.hp.com> 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).

[-- Attachment #2: fixlibobjc.diff.txt --]
[-- Type: text/plain, Size: 2020 bytes --]

Index: Makefile.in
===================================================================
--- Makefile.in	(revision 125044)
+++ Makefile.in	(working copy)
@@ -42,7 +42,6 @@ toolexecdir = @toolexecdir@
 toolexeclibdir = @toolexeclibdir@
 
 includedirname = @includedirname@
-libext = @libext@
 
 extra_ldflags_libobjc = @extra_ldflags_libobjc@
 
@@ -137,7 +136,7 @@ FLAGS_TO_PASS = \
 	"libsubdir=$(libsubdir)" \
 	"tooldir=$(tooldir)"
 
-all: libobjc$(libext).la $(OBJC_BOEHM_GC)
+all: libobjc.la $(OBJC_BOEHM_GC)
 	: $(MAKE) ; exec $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=all
 
 # User-visible header files.
@@ -274,12 +273,12 @@ doc: info dvi pdf html
 install-html:
 install-pdf:
 
-libobjc$(libext).la: $(OBJS)
+libobjc.la: $(OBJS)
 	$(LIBTOOL_LINK) $(CC) -o $@ $(OBJS) \
 		-rpath $(toolexeclibdir) \
 		-version-info $(LIBOBJC_VERSION) $(extra_ldflags_libobjc)
 
-libobjc_gc$(libext).la: $(OBJS_GC)
+libobjc_gc.la: $(OBJS_GC)
 	$(LIBTOOL_LINK) $(CC) -o $@ $(OBJS_GC) \
 		-rpath $(toolexeclibdir) \
 		-version-info $(LIBOBJC_GC_VERSION) $(extra_ldflags_libobjc)
@@ -334,9 +333,9 @@ install: install-libs install-headers
 
 install-libs: installdirs
 	$(SHELL) $(multi_basedir)/mkinstalldirs $(DESTDIR)$(toolexeclibdir)
-	$(LIBTOOL_INSTALL) $(INSTALL) libobjc$(libext).la $(DESTDIR)$(toolexeclibdir);
+	$(LIBTOOL_INSTALL) $(INSTALL) libobjc.la $(DESTDIR)$(toolexeclibdir);
 	if [ "$(OBJC_BOEHM_GC)" ]; then \
-	  $(LIBTOOL_INSTALL) $(INSTALL) libobjc_gc$(libext).la \
+	  $(LIBTOOL_INSTALL) $(INSTALL) libobjc_gc.la \
 				$(DESTDIR)$(toolexeclibdir);\
 	fi
 	$(MULTIDO) $(FLAGS_TO_PASS) multi-do DO="$@"
@@ -353,7 +352,7 @@ install-headers:
 check uninstall install-strip dist installcheck installdirs:
 
 mostlyclean:
-	-$(LIBTOOL_CLEAN) rm -f libobjc$(libext).la libobjc_gc$(libext).la *.lo
+	-$(LIBTOOL_CLEAN) rm -f libobjc.la libobjc_gc.la *.lo
 	-rm -f runtime-info.h tmp-runtime.s *.o *.lo libobjc* xforward \
 		fflags *.aux *.cp *.dvi *.pdf *.fn *.info *.ky *.log *.pg \
 		*.toc *.tp *.vr *.html libobj.exp

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

[Andreas Tobler]

Mike Stump wrote:
> On May 24, 2007, at 2:14 PM, libtool@cwilson.fastmail.fm 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

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

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

[Eric Christopher]

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

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

[Andreas Tobler]

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

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

[Eric Christopher]

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

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

[Andreas Schwab]

Steve Ellcey <sje@cup.hp.com> 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, schwab@suse.de
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."

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

[Andreas Schwab]

Steve Ellcey <sje@cup.hp.com> 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, schwab@suse.de
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."

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

[Charles Wilson]

[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?

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

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

[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
sje@cup.hp.com