Final(?) patch to update libtool in GCC and src trees

Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

Here is what I hope is the final patch to update libtool in the GCC and
src trees.  I tested this on HPPA HP-UX, IA64 HP-UX, IA64 Linux, and
X86_64 Linux.  I did get a few more errors with the new libtool than the
old.  Most seemed to be unrelated (timeouts on long running tests that I
have seen before), I got 60 failures in ObjC (instead of 24) on IA64
Linux.  I don't build ObjC on HP-UX platforms.  The failures involve
having an undefined reference to __gnu_objc_personality_v0 when linking
and I haven't investigated them further.

Other than that the testing looked good.

Given these results is it OK to checkin the new libtool?  I'd rather not
wait to fix the objc problem because maintaining all these changes in
both the GCC and src trees is a bit of a pain.

Here is the final patch with everthing but the new libtool, the new
libtool that I am using can be found in the message:

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

along with most of these changes.  The only difference in this patch
from that one is the change to ml-config.in but here are the complete
GCC changelog files, the gcc diffs, the src ChangeLogs and the src diffs
(but not the new libtool).

OK to checkin?

Steve Ellcey
sje@cup.hp.com


Top level GCC tree ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* ltmain.sh: Update from ToT Libtool.
	* libtool.m4: Update from ToT Libtool.
	* ltsugar.m4: New. Update from ToT Libtool.
	* ltversion.m4: New. Update from ToT Libtool.
	* ltoptions.m4: New. Update from ToT Libtool.
	* ltconfig: Remove.
	* ltcf-c.sh: Remove.
	* ltcf-cxx.sh: Remove.
	* ltcf-gcj.sh: Remove.
	* config-ml.in: Pass ${ml_config_env} to configure calls.

libgfortran/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* Makefile.am: Add -I .. to ACLOCAL_AMFLAGS.  Add libgfortran_la_LINK.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

libgomp/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* Makefile.am: Add -I .. to ACLOCAL_AMFLAGS.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.
	* configure: Regenerate.

zlib/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* Makefile.am: Add -I .. to ACLOCAL_AMFLAGS.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

libstdc++-v3/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* configure.ac: Change how LIBSUPCXX_PICFLAGS is set.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* src/Makefile.in: Regenerate.
	* po/Makefile.in: Regenerate.
	* libmath/Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* libsupc++/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.
	* configure: Regenerate.

libobjc/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* configure: Regenerate.

libmudflap/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.
	* configure: Regenerate.

boehm-gc/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* configure: Regenerate.

libffi/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.
	* configure: Regenerate.

libssp/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

libjava/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* include/Makefile.in: Regenerate.
	* gcj/Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.
	* configure: Regenerate.



Index: config-ml.in
===================================================================
--- config-ml.in	(revision 123670)
+++ config-ml.in	(working copy)
@@ -890,7 +890,7 @@ if [ -n "${multidirs}" ] && [ -z "${ml_n
 
     if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
 	--with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
-	${ac_configure_args} ${ml_srcdiroption} ; then
+	${ac_configure_args} ${ml_config_env} ${ml_srcdiroption} ; then
       true
     else
       exit 1
Index: libgfortran/Makefile.am
===================================================================
--- libgfortran/Makefile.am	(revision 123670)
+++ libgfortran/Makefile.am	(working copy)
@@ -1,12 +1,13 @@
 ## Process this file with automake to produce Makefile.in
 
 
-ACLOCAL_AMFLAGS = -I ../config
+ACLOCAL_AMFLAGS = -I .. -I ../config
 
 ## May be used by toolexeclibdir.
 gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
 
 toolexeclib_LTLIBRARIES = libgfortran.la
+libgfortran_la_LINK = $(LINK)
 libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lm $(extra_ldflags_libgfortran)
 
 myexeclib_LTLIBRARIES = libgfortranbegin.la
Index: libgomp/Makefile.am
===================================================================
--- libgomp/Makefile.am	(revision 123670)
+++ libgomp/Makefile.am	(working copy)
@@ -1,6 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
-ACLOCAL_AMFLAGS = -I ../config
+ACLOCAL_AMFLAGS = -I .. -I ../config
 SUBDIRS = testsuite
 
 ## May be used by toolexeclibdir.
Index: zlib/Makefile.am
===================================================================
--- zlib/Makefile.am	(revision 123670)
+++ zlib/Makefile.am	(working copy)
@@ -2,7 +2,7 @@
 
 AUTOMAKE_OPTIONS = 1.8 cygnus
 
-ACLOCAL_AMFLAGS = -I ../config
+ACLOCAL_AMFLAGS = -I .. -I ../config
 
 ZLIB_SOURCES = adler32.c compress.c crc32.c crc32.h deflate.c \
 deflate.h gzio.c infback.c inffast.c inffast.h inffixed.h inflate.c \
Index: libstdc++-v3/configure.ac
===================================================================
--- libstdc++-v3/configure.ac	(revision 123670)
+++ libstdc++-v3/configure.ac	(working copy)
@@ -355,10 +355,8 @@ GLIBCXX_EXPORT_INSTALL_INFO
 GLIBCXX_EXPORT_INCLUDES
 GLIBCXX_EXPORT_FLAGS
 
-if ${CONFIG_SHELL-/bin/sh} ./libtool --tag CXX --features |
-   grep "enable shared" > /dev/null;
-then
-  LIBSUPCXX_PICFLAGS=-prefer-pic
+if test "$enable_shared" = yes; then
+  LIBSUPCXX_PICFLAGS="-prefer-pic"
 else
   LIBSUPCXX_PICFLAGS=
 fi


Top level src tree ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* ltmain.sh: Update from GCC.
	* libtool.m4: Update from GCC.
	* ltsugar.m4: New. Update from GCC.
	* ltversion.m4: New. Update from GCC.
	* ltoptions.m4: New. Update from GCC.
	* ltconfig: Remove.
	* ltcf-c.sh: Remove.
	* ltcf-cxx.sh: Remove.
	* ltcf-gcj.sh: Remove.
	* src-release: Update with new libtool file list.

bfd/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* acinclude.m4: Add new includes.
	* configure.in: Change macro call order.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regnerate.
	* configure: Regenerate.

binutils/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* configure.in: Change macro call order.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

gas/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* acinclude.m4: Add new includes.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

gprof/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* acinclude.m4: Add new includes.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

rda/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* acinclude.m4: Add new includes.
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

ld/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

opcodes/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.

newlib/ChangeLog
2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* aclocal.m4: Regenerate.
	* Makefile.in: Regenerate.
	* configure: Regenerate.


Index: src-release
===================================================================
RCS file: /cvs/src/src/src-release,v
retrieving revision 1.22
diff -u -p -r1.22 src-release
--- src-release	9 Feb 2007 15:15:38 -0000	1.22
+++ src-release	4 Apr 2007 16:58:29 -0000
@@ -49,8 +49,8 @@ PWD = $${PWDCMD-pwd}
 DEVO_SUPPORT= README Makefile.in configure configure.ac \
 	config.guess config.sub config move-if-change \
 	COPYING COPYING.LIB install-sh config-ml.in symlink-tree \
-	mkinstalldirs ltconfig ltmain.sh missing ylwrap \
-	libtool.m4 ltcf-c.sh ltcf-cxx.sh ltcf-gcj.sh \
+	mkinstalldirs ltmain.sh missing ylwrap \
+	libtool.m4 ltsugar.m4, ltversion.m4, ltoptions.m4 \
 	Makefile.def Makefile.tpl src-release config.rpath
 
 # Files in devo/etc used in any net release.
Index: bfd/acinclude.m4
===================================================================
RCS file: /cvs/src/src/bfd/acinclude.m4,v
retrieving revision 1.16
diff -u -p -r1.16 acinclude.m4
--- bfd/acinclude.m4	31 May 2006 15:14:35 -0000	1.16
+++ bfd/acinclude.m4	4 Apr 2007 16:58:29 -0000
@@ -49,6 +49,9 @@ else
 fi
 AC_SUBST(EXEEXT_FOR_BUILD)])dnl
 
+sinclude(../ltsugar.m4)
+sinclude(../ltversion.m4)
+sinclude(../ltoptions.m4)
 sinclude(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring libtool.m4
 dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
Index: bfd/configure.in
===================================================================
RCS file: /cvs/src/src/bfd/configure.in,v
retrieving revision 1.226
diff -u -p -r1.226 configure.in
--- bfd/configure.in	23 Mar 2007 02:51:30 -0000	1.226
+++ bfd/configure.in	4 Apr 2007 16:58:30 -0000
@@ -19,7 +19,10 @@ dnl Default to a non shared library.  Th
 dnl configure option --enable-shared.
 AM_DISABLE_SHARED
 
-AM_PROG_LIBTOOL
+AC_PROG_CC
+AC_GNU_SOURCE
+
+AC_PROG_LIBTOOL
 
 AC_ARG_ENABLE(64-bit-bfd,
 [  --enable-64-bit-bfd     64-bit support (on hosts with narrower word sizes)],
@@ -85,9 +88,6 @@ bfd_default_target_size=32
 
 # host stuff:
 
-AC_PROG_CC
-AC_GNU_SOURCE
-
 ALL_LINGUAS="fr tr ja es sv da zh_CN ro rw vi"
 ZW_GNU_GETTEXT_SISTER_DIR
 AM_PO_SUBDIRS
Index: binutils/configure.in
===================================================================
RCS file: /cvs/src/src/binutils/configure.in,v
retrieving revision 1.77
diff -u -p -r1.77 configure.in
--- binutils/configure.in	15 Mar 2007 14:17:16 -0000	1.77
+++ binutils/configure.in	4 Apr 2007 16:58:30 -0000
@@ -11,7 +11,9 @@ BFD_VERSION=`sed -n -e 's/^.._INIT_AUTOM
 changequote([,])dnl
 AM_INIT_AUTOMAKE(binutils, ${BFD_VERSION})
 
-AM_PROG_LIBTOOL
+AC_PROG_CC
+AC_GNU_SOURCE
+AC_PROG_LIBTOOL
 
 AC_ARG_ENABLE(targets,
 [  --enable-targets        alternative target configurations],
@@ -40,9 +42,6 @@ if test -z "$host" ; then
     AC_MSG_ERROR(Unrecognized host system type; please check config.sub.)
 fi
 
-AC_PROG_CC
-AC_GNU_SOURCE
-
 AC_PROG_YACC
 AM_PROG_LEX
 
Index: gas/acinclude.m4
===================================================================
RCS file: /cvs/src/src/gas/acinclude.m4,v
retrieving revision 1.6
diff -u -p -r1.6 acinclude.m4
--- gas/acinclude.m4	2 Aug 2006 14:26:07 -0000	1.6
+++ gas/acinclude.m4	4 Apr 2007 16:58:30 -0000
@@ -71,6 +71,9 @@ done
 $1=[$]_gas_uniq_newlist
 ])dnl
 
+sinclude(../ltsugar.m4)
+sinclude(../ltversion.m4)
+sinclude(../ltoptions.m4)
 sinclude(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring libtool.m4
 dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
Index: gprof/acinclude.m4
===================================================================
RCS file: /cvs/src/src/gprof/acinclude.m4,v
retrieving revision 1.3
diff -u -p -r1.3 acinclude.m4
--- gprof/acinclude.m4	31 May 2006 15:14:37 -0000	1.3
+++ gprof/acinclude.m4	4 Apr 2007 16:58:30 -0000
@@ -4,6 +4,9 @@ sinclude(../config/nls.m4)
 sinclude(../config/po.m4)
 sinclude(../config/progtest.m4)
 
+sinclude(../ltsugar.m4)
+sinclude(../ltversion.m4)
+sinclude(../ltoptions.m4)
 sinclude(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring libtool.m4
 dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake
Index: rda/acinclude.m4
===================================================================
RCS file: /cvs/src/src/rda/acinclude.m4,v
retrieving revision 1.2
diff -u -p -r1.2 acinclude.m4
--- rda/acinclude.m4	31 May 2006 15:14:39 -0000	1.2
+++ rda/acinclude.m4	4 Apr 2007 16:58:30 -0000
@@ -1,3 +1,6 @@
+sinclude(../ltsugar.m4)
+sinclude(../ltversion.m4)
+sinclude(../ltoptions.m4)
 sinclude(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring libtool.m4
 dnl AM_PROG_LIBTOOL into aclocal.m4, while still arranging for automake

Re: Final(?) patch to update libtool in GCC and src trees

[Andrew Pinski]

On 4/10/07, Steve Ellcey <sje@cup.hp.com> wrote:
>
> Here is what I hope is the final patch to update libtool in the GCC and
> src trees.  I tested this on HPPA HP-UX, IA64 HP-UX, IA64 Linux, and
> X86_64 Linux.  I did get a few more errors with the new libtool than the
> old.  Most seemed to be unrelated (timeouts on long running tests that I
> have seen before), I got 60 failures in ObjC (instead of 24) on IA64
> Linux.  I don't build ObjC on HP-UX platforms.  The failures involve
> having an undefined reference to __gnu_objc_personality_v0 when linking
> and I haven't investigated them further.

Hmm, this usually means something is not being exported correctly from
libobjc.so, can you do a nm on generated libobjc.so?

Thanks,
Andrew Pinski

RE: Final(?) patch to update libtool in GCC and src trees

[Dave Korn]

On 10 April 2007 19:25, Steve Ellcey wrote:

> Here is what I hope is the final patch to update libtool in the GCC and
> src trees.  I tested this on HPPA HP-UX, IA64 HP-UX, IA64 Linux, and
> X86_64 Linux.  I did get a few more errors with the new libtool than the
> old. 

> Other than that the testing looked good.

  You don't mention any cygwin testing; did anyone else do any?

> Given these results is it OK to checkin the new libtool?  I'd rather not
> wait to fix the objc problem because maintaining all these changes in
> both the GCC and src trees is a bit of a pain.

  I appreciate the problem, but Cygwin can be a bit 'special' when it comes to
libtool; if it hasn't been done yet, can you possibly bear to hold off a bit
while I give it some hasty testing?  (By 'a bit', I mean no more than say
'overnight').  Sorry to be a pain :-/


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

> Hmm, this usually means something is not being exported correctly from
> libobjc.so, can you do a nm on generated libobjc.so?
> 
> Thanks,
> Andrew Pinski

% nm obj_gcc/ia64-debian-linux-gnu/libobjc/.libs/libobjca.so | grep person
0000000000027d10 T __gnu_objc_personality_v0

It looks like it is geing exported correctly.

It may be an issue with how the objc tests (compile tests, not library tests)
are being called during testing.  Here is an example failure from
gcc/testsuite/objc.dg:

set_ld_library_path_env_vars: ld_library_path=.::/proj/opensrc/nightly/build-ia64-debian-linux-gnu-trunk/obj_gcc/gcc:/proj/opensrc/nightly/build-ia64-debian-linux-gnu-trunk/obj_gcc/gcc:/proj/opensrc/nightly/build-ia64-debian-linux-gnu-trunk/obj_gcc/gcc:/proj/opensrc/nightly/build-ia64-debian-linux-gnu-trunk/obj_gcc/gcc
Executing on host: /proj/opensrc/nightly/build-ia64-debian-linux-gnu-trunk/obj_gcc/gcc/xgcc -B/proj/opensrc/nightly/build-ia64-debian-linux-gnu-trunk/obj_gcc/gcc/ /proj/opensrc/nightly/src/trunk/gcc/testsuite/objc.dg/bitfield-1.m     -lobjc -lm   -o ./bitfield-1.exe    (timeout = 300)
/proj/opensrc/be/ia64-debian-linux-gnu/lib/gcc/ia64-debian-linux-gnu/4.1.1/../../../../ia64-debian-linux-gnu/bin/ld: cannot find -lobjc
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
/proj/opensrc/be/ia64-debian-linux-gnu/lib/gcc/ia64-debian-linux-gnu/4.1.1/../../../../ia64-debian-linux-gnu/bin/ld: cannot find -lobjc
collect2: ld returned 1 exit status

FAIL: objc.dg/bitfield-1.m (test for excess errors)

Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

>   I appreciate the problem, but Cygwin can be a bit 'special' when it comes to
> libtool; if it hasn't been done yet, can you possibly bear to hold off a bit
> while I give it some hasty testing?  (By 'a bit', I mean no more than say
> 'overnight').  Sorry to be a pain :-/
> 
> 
>     cheers,
>       DaveK

I can wait, especially since no one has given me the go ahead yet.  :-)
I know of no cygwin testing that has been done.

Steve Ellcey
sje@cup.hp.com

RE: Final(?) patch to update libtool in GCC and src trees

[Dave Korn]

On 10 April 2007 21:07, Steve Ellcey wrote:

>>   I appreciate the problem, but Cygwin can be a bit 'special' when it
>> comes to libtool; if it hasn't been done yet, can you possibly bear to
>> hold off a bit while I give it some hasty testing?  (By 'a bit', I mean no
>> more than say 'overnight').  Sorry to be a pain :-/
>> 
>> 
>>     cheers,
>>       DaveK
> 
> I can wait, especially since no one has given me the go ahead yet.  :-)
> I know of no cygwin testing that has been done.

  Thank you.  In progress now; I won't keep you hanging about.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

RE: Final(?) patch to update libtool in GCC and src trees

[Dave Korn]

On 10 April 2007 21:07, Steve Ellcey wrote:

>>   I appreciate the problem, but Cygwin can be a bit 'special' when it
>> comes to libtool; if it hasn't been done yet, can you possibly bear to
>> hold off a bit while I give it some hasty testing?  (By 'a bit', I mean no
>> more than say 'overnight').  Sorry to be a pain :-/
>> 
>> 
>>     cheers,
>>       DaveK
> 
> I can wait, especially since no one has given me the go ahead yet.  :-)
> I know of no cygwin testing that has been done.

  Mixed results so far.  Patching a binutils checkout and building it got me
this:


                === ld tests ===
@@ -297,14 +297,8 @@ Running /usr/build/src-binutils/ld/tests
 Running /usr/build/src-binutils/ld/testsuite/ld-arm/arm-elf.exp ...
 Running /usr/build/src-binutils/ld/testsuite/ld-auto-import/auto-import.exp
...
 Running /usr/build/src-binutils/ld/testsuite/ld-bootstrap/bootstrap.exp ...
-FAIL: bootstrap
-FAIL: bootstrap with strip
 FAIL: bootstrap with --static
-FAIL: bootstrap with --traditional-format
-FAIL: bootstrap with --no-keep-memory
-FAIL: bootstrap with --relax
 Running /usr/build/src-binutils/ld/testsuite/ld-cdtest/cdtest.exp ...
-FAIL: cdtest
 FAIL: cdtest with -Ur
 Running /usr/build/src-binutils/ld/testsuite/ld-checks/checks.exp ...
 Running /usr/build/src-binutils/ld/testsuite/ld-cris/cris.exp ...
@@ -396,40 +390,40 @@ Running /usr/build/src-binutils/ld/tests

                === ld Summary ===

-# of expected passes           53
-# of unexpected failures       9
+# of expected passes           59
+# of unexpected failures       3
 # of unexpected successes      1
 # of expected failures         3
 # of unsupported tests         1
-/usr/build/obj-binutils/ld/ld-new 2.17.50.20070410
+/usr/build/obj-binutils-patched/ld/ld-new 2.17.50.20070410


..which is entirely good :-D  Then I tried a winsup checkout; it failed to
configure in newlib:

checking for i686-pc-cygwin-ranlib... ranlib
checking for i686-pc-cygwin-readelf... no
checking for readelf... readelf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether to enable maintainer-specific portions of Makefiles... no
checking for .preinit_array/.init_array/.fini_array support... readelf: Error:
Input file 'conftest' is not readable.
no
checking for array aliasing support... yes
configure: updating cache ./config.cache
configure: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.
Makefile:8649: *** [configure-target-newlib] Error 1

#0  configure-target-newlib at /usr/build/obj-winsup.new/Makefile:8649
#1  all-target-newlib at /usr/build/obj-winsup.new/Makefile:8690
#2  maybe-all-target-newlib at /usr/build/obj-winsup.new/Makefile:8687
#3  all-target (.PHONY target)
make[1]: Leaving directory `/usr/build/obj-winsup.new'


This is what config.log showed:

configure:3737: checking for a BSD-compatible install
configure:3793: result: /usr/bin/install -c
configure:3808: checking whether to enable maintainer-specific portions of
Makefiles
configure:3817: result: no
configure:21892: checking for .preinit_array/.init_array/.fini_array support
configure:21905: gcc -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/cygwin
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/w32api/lib -isystem
/usr/build/src-winsup/winsup/include -isystem
/usr/build/src-winsup/winsup/cygwin/include -isystem
/usr/build/src-winsup/winsup/w32api/include
-B/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/ -isystem
/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/targ-include -isystem
/usr/build/src-winsup/newlib/libc/include
-I/usr/build/src-winsup/winsup/cygwin/include    -o conftest conftest.c
		   -static -nostartfiles -nostdlib 1>&5
configure:21908: $? = 0
configure:21921: result: no
configure:21931: checking for array aliasing support
configure:21942: gcc -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/cygwin
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/w32api/lib -isystem
/usr/build/src-winsup/winsup/include -isystem
/usr/build/src-winsup/winsup/cygwin/include -isystem
/usr/build/src-winsup/winsup/w32api/include
-B/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/ -isystem
/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/targ-include -isystem
/usr/build/src-winsup/newlib/libc/include
-I/usr/build/src-winsup/winsup/cygwin/include   -c conftest.c
		   1>&5
conftest.c:1: warning: excess elements in scalar initializer
conftest.c:1: warning: (near initialization for `x3')
conftest.c:1: warning: excess elements in scalar initializer
conftest.c:1: warning: (near initialization for `x3')
configure:21945: $? = 0
configure:21954: result: yes
configure:22030: updating cache ./config.cache
configure:22141: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.


  Note the huge jump:

configure:3817: result: no
configure:21892: checking for .preinit_array/.init_array/.fini_array support

interestingly enough, the only line after 3817 that has a conditional and that
precedes any more printout is at #3939, where it says ...

if test "${use_libtool}" = "yes"; then

and the clause that would set am_fastdepCXX is at 7496 to 7505, which is
probably still inside that conditional.

if
  test "x$enable_dependency_tracking" != xno \
  && test "$am_cv_CXX_dependencies_compiler_type" = gcc3; then
  am__fastdepCXX_TRUE=
  am__fastdepCXX_FALSE='#'
else
  am__fastdepCXX_TRUE='#'
  am__fastdepCXX_FALSE=
fi



  This happened by following your procedure in
http://sourceware.org/ml/gdb/2007-03/msg00284.html.  I did the following
steps:

- take existing checkout of 'winsup' module, 
- clean it out with
 cvs up -CAdP config contrib etc include libiberty newlib winsup
 cvs up -lCA .
- kill the four libtool config files
  rm ltc*
- untar the libtool tarball
  tar xzvf libtool.tar.gz
- regenerated newlib as in your email
  cd newlib ; aclocal; automake --cygnus; autoconf

Then configured in an out-of-tree object dir with no options other than
--prefix and -v.

  Any idea what to try next?  It looks a bit like the problem with
AM_CONDITIONAL discussed at

http://sourceware.org/ml/automake/2005-01/msg00037.html



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Final(?) patch to update libtool in GCC and src trees

[Charles Wilson]

Steve Ellcey wrote:
>>   I appreciate the problem, but Cygwin can be a bit 'special' when it comes to
>> libtool; if it hasn't been done yet, can you possibly bear to hold off a bit
>> while I give it some hasty testing?  (By 'a bit', I mean no more than say
>> 'overnight').  Sorry to be a pain :-/
> 
> I can wait, especially since no one has given me the go ahead yet.  :-)
> I know of no cygwin testing that has been done.

Sorry -- I was starting to do some testing, but got distracted by some 
side issues:
   (1) building libbfd/libopcodes as DLL on windows (with the new 
libtool support).  This is related to:
   (2) using the new libtool to build libiberty
Warning on #2: I dug up an old (gcc-patches mailing list, circa Oct 
2004) attempt at this, and used it with some limited success.  However, 
there are /issues/ with making libiberty into a libtoolized 
"convenience" library.  See this thread:

[RFC] New library "type" needed?
http://lists.gnu.org/archive/html/libtool/2007-03/msg00022.html

especially the final post:
Simultaneous pic and non-pic convenience libs [Was: [RFC] New library..]
http://lists.gnu.org/archive/html/libtool/2007-03/msg00038.html

I'll rip that failed experiment out of my tree and try again with just 
Steve's patches; however I'd imagine Dave Korn will have results before 
I do.

--
Chuck

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

Dave Korn wrote:
> On 10 April 2007 21:07, Steve Ellcey wrote:
> 
>>>   I appreciate the problem, but Cygwin can be a bit 'special' when it
>>> comes to libtool; if it hasn't been done yet, can you possibly bear to
>>> hold off a bit while I give it some hasty testing?  (By 'a bit', I mean no
>>> more than say 'overnight').  Sorry to be a pain :-/
>>>
>>>
>>>     cheers,
>>>       DaveK
>> I can wait, especially since no one has given me the go ahead yet.  :-)
>> I know of no cygwin testing that has been done.
> 
>   Mixed results so far.  Patching a binutils checkout and building it got me
> this:
> 
> 
>                 === ld tests ===
> @@ -297,14 +297,8 @@ Running /usr/build/src-binutils/ld/tests
>  Running /usr/build/src-binutils/ld/testsuite/ld-arm/arm-elf.exp ...
>  Running /usr/build/src-binutils/ld/testsuite/ld-auto-import/auto-import.exp
> ...
>  Running /usr/build/src-binutils/ld/testsuite/ld-bootstrap/bootstrap.exp ...
> -FAIL: bootstrap
> -FAIL: bootstrap with strip
>  FAIL: bootstrap with --static
> -FAIL: bootstrap with --traditional-format
> -FAIL: bootstrap with --no-keep-memory
> -FAIL: bootstrap with --relax
>  Running /usr/build/src-binutils/ld/testsuite/ld-cdtest/cdtest.exp ...
> -FAIL: cdtest
>  FAIL: cdtest with -Ur
>  Running /usr/build/src-binutils/ld/testsuite/ld-checks/checks.exp ...
>  Running /usr/build/src-binutils/ld/testsuite/ld-cris/cris.exp ...
> @@ -396,40 +390,40 @@ Running /usr/build/src-binutils/ld/tests
> 
>                 === ld Summary ===
> 
> -# of expected passes           53
> -# of unexpected failures       9
> +# of expected passes           59
> +# of unexpected failures       3
>  # of unexpected successes      1
>  # of expected failures         3
>  # of unsupported tests         1
> -/usr/build/obj-binutils/ld/ld-new 2.17.50.20070410
> +/usr/build/obj-binutils-patched/ld/ld-new 2.17.50.20070410
> 
> 
> ..which is entirely good :-D  Then I tried a winsup checkout; it failed to
> configure in newlib:
> 
> checking for i686-pc-cygwin-ranlib... ranlib
> checking for i686-pc-cygwin-readelf... no
> checking for readelf... readelf
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for .preinit_array/.init_array/.fini_array support... readelf: Error:
> Input file 'conftest' is not readable.
> no
> checking for array aliasing support... yes
> configure: updating cache ./config.cache
> configure: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
> Makefile:8649: *** [configure-target-newlib] Error 1
> 
> #0  configure-target-newlib at /usr/build/obj-winsup.new/Makefile:8649
> #1  all-target-newlib at /usr/build/obj-winsup.new/Makefile:8690
> #2  maybe-all-target-newlib at /usr/build/obj-winsup.new/Makefile:8687
> #3  all-target (.PHONY target)
> make[1]: Leaving directory `/usr/build/obj-winsup.new'
> 
> 
> This is what config.log showed:
> 
> configure:3737: checking for a BSD-compatible install
> configure:3793: result: /usr/bin/install -c
> configure:3808: checking whether to enable maintainer-specific portions of
> Makefiles
> configure:3817: result: no
> configure:21892: checking for .preinit_array/.init_array/.fini_array support
> configure:21905: gcc -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup
> -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/cygwin
> -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/w32api/lib -isystem
> /usr/build/src-winsup/winsup/include -isystem
> /usr/build/src-winsup/winsup/cygwin/include -isystem
> /usr/build/src-winsup/winsup/w32api/include
> -B/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/ -isystem
> /usr/build/obj-winsup.new/i686-pc-cygwin/newlib/targ-include -isystem
> /usr/build/src-winsup/newlib/libc/include
> -I/usr/build/src-winsup/winsup/cygwin/include    -o conftest conftest.c
> 		   -static -nostartfiles -nostdlib 1>&5
> configure:21908: $? = 0
> configure:21921: result: no
> configure:21931: checking for array aliasing support
> configure:21942: gcc -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup
> -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/cygwin
> -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/w32api/lib -isystem
> /usr/build/src-winsup/winsup/include -isystem
> /usr/build/src-winsup/winsup/cygwin/include -isystem
> /usr/build/src-winsup/winsup/w32api/include
> -B/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/ -isystem
> /usr/build/obj-winsup.new/i686-pc-cygwin/newlib/targ-include -isystem
> /usr/build/src-winsup/newlib/libc/include
> -I/usr/build/src-winsup/winsup/cygwin/include   -c conftest.c
> 		   1>&5
> conftest.c:1: warning: excess elements in scalar initializer
> conftest.c:1: warning: (near initialization for `x3')
> conftest.c:1: warning: excess elements in scalar initializer
> conftest.c:1: warning: (near initialization for `x3')
> configure:21945: $? = 0
> configure:21954: result: yes
> configure:22030: updating cache ./config.cache
> configure:22141: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
> 
> 
>   Note the huge jump:
> 
> configure:3817: result: no
> configure:21892: checking for .preinit_array/.init_array/.fini_array support

Right.

Inside those two lines we have

if test "${use_libtool}" = "yes"; then
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
AC_PROG_AWK
fi

I would rewrite them at the very least as

AC_PROG_AWK
AC_PROG_CXX

if test "${use_libtool}" = "yes"; then
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
fi

There might be more macros to put above the "if" to avoid that they be 
expanded inside an "if".

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Andreas Schwab]

Paolo Bonzini <paolo.bonzini@lu.unisi.ch> writes:

> Inside those two lines we have
>
> if test "${use_libtool}" = "yes"; then
> AC_LIBTOOL_WIN32_DLL
> AM_PROG_LIBTOOL
> AC_PROG_AWK
> fi
>
> I would rewrite them at the very least as
>
> AC_PROG_AWK
> AC_PROG_CXX
>
> if test "${use_libtool}" = "yes"; then
> AC_LIBTOOL_WIN32_DLL
> AM_PROG_LIBTOOL
> fi

I think that should use AS_IF instead.

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: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

>> I would rewrite them at the very least as
>>
>> AC_PROG_AWK
>> AC_PROG_CXX
>>
>> if test "${use_libtool}" = "yes"; then
>> AC_LIBTOOL_WIN32_DLL
>> AM_PROG_LIBTOOL
>> fi
> 
> I think that should use AS_IF instead.

Does AS_IF put required macros outside its expansion?  That's a
cool feature if it does.

However, if this is the case, it is also a problem.
AM_PROG_LIBTOOL used to expand its subparts via
AC_REQUIRE, which would sort of undo the effect of
the if statement.

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Ralf Wildenhues]

* Paolo Bonzini wrote on Wed, Apr 11, 2007 at 10:50:31AM CEST:
>>> I would rewrite them at the very least as
>>>
>>> AC_PROG_AWK
>>> AC_PROG_CXX
>>>
>>> if test "${use_libtool}" = "yes"; then
>>> AC_LIBTOOL_WIN32_DLL
>>> AM_PROG_LIBTOOL
>>> fi
>> I think that should use AS_IF instead.
>
> Does AS_IF put required macros outside its expansion?  That's a
> cool feature if it does.

Only with Autoconf 2.60 and newer.

> However, if this is the case, it is also a problem.
> AM_PROG_LIBTOOL used to expand its subparts via
> AC_REQUIRE, which would sort of undo the effect of
> the if statement.

Yes, I don't think it'll help here.  But also I don't see why CXX should
come into play here at all, if not by an old 1.5.x libtool.m4 file that
is picked up by aclocal (without having tested anything, though).

Cheers,
Ralf

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

>> Does AS_IF put required macros outside its expansion?  That's a
>> cool feature if it does.
> 
> Only with Autoconf 2.60 and newer.

I see; so it's ruled out for now.

>> However, if this is the case, it is also a problem.
>> AM_PROG_LIBTOOL used to expand its subparts via
>> AC_REQUIRE, which would sort of undo the effect of
>> the if statement.
> 
> Yes, I don't think it'll help here.  But also I don't see why CXX should
> come into play here at all, if not by an old 1.5.x libtool.m4 file that
> is picked up by aclocal (without having tested anything, though).

Dave, can you check the content of newlib/aclocal.m4?

Paolo

RE: Final(?) patch to update libtool in GCC and src trees

[Dave Korn]

On 11 April 2007 09:59, Paolo Bonzini wrote:

>>> Does AS_IF put required macros outside its expansion?  That's a
>>> cool feature if it does.
>> 
>> Only with Autoconf 2.60 and newer.
> 
> I see; so it's ruled out for now.

  I used 2.60 to regenerate in newlib/, was that the wrong thing to do?

/usr/build/src-winsup/newlib $ head -3 configure
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.60 for newlib 1.15.0.

>>> However, if this is the case, it is also a problem.
>>> AM_PROG_LIBTOOL used to expand its subparts via
>>> AC_REQUIRE, which would sort of undo the effect of
>>> the if statement.
>> 
>> Yes, I don't think it'll help here.  But also I don't see why CXX should
>> come into play here at all, if not by an old 1.5.x libtool.m4 file that
>> is picked up by aclocal (without having tested anything, though).
> 
> Dave, can you check the content of newlib/aclocal.m4?
> 
> Paolo

  That would be the freshly regenerated one:

/usr/build/src-winsup/newlib $ head -1 aclocal.m4
# generated automatically by aclocal 1.9.6 -*- Autoconf -*-

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

>> I see; so it's ruled out for now.
> 
>   I used 2.60 to regenerate in newlib/, was that the wrong thing to do?

No, it shouldn't be a problem; but committing would require 2.59.

>   That would be the freshly regenerated one:
> 
> /usr/build/src-winsup/newlib $ head -1 aclocal.m4
> # generated automatically by aclocal 1.9.6 -*- Autoconf -*-

Can you please attach it?

Paolo

RE: Final(?) patch to update libtool in GCC and src trees

[Dave Korn]

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

On 11 April 2007 10:25, Paolo Bonzini wrote:

>>   That would be the freshly regenerated one:
>> 
>> /usr/build/src-winsup/newlib $ head -1 aclocal.m4
>> # generated automatically by aclocal 1.9.6 -*- Autoconf -*-
> 
> Can you please attach it?

  Cc list trimmed a bit :-)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

[-- Attachment #2: aclocal.m4.bz2 --]
[-- Type: application/octet-stream, Size: 50941 bytes --]

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

Dave Korn wrote:
> On 11 April 2007 10:25, Paolo Bonzini wrote:
> 
>>>   That would be the freshly regenerated one:
>>>
>>> /usr/build/src-winsup/newlib $ head -1 aclocal.m4
>>> # generated automatically by aclocal 1.9.6 -*- Autoconf -*-
>> Can you please attach it?
> 
>   Cc list trimmed a bit :-)

aclocal used your 1.5.x libtool, instead of the new GCC libtool.

You have to regenerate it with

  aclocal -I ../config -I .. -I.

or something like that.

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Christopher Faylor]

On Wed, Apr 11, 2007 at 12:18:56PM +0200, Paolo Bonzini wrote:
>Dave Korn wrote:
>>On 11 April 2007 10:25, Paolo Bonzini wrote:
>>
>>>>  That would be the freshly regenerated one:
>>>>
>>>>/usr/build/src-winsup/newlib $ head -1 aclocal.m4
>>>># generated automatically by aclocal 1.9.6 -*- Autoconf -*-
>>>Can you please attach it?
>>
>>  Cc list trimmed a bit :-)
>
>aclocal used your 1.5.x libtool, instead of the new GCC libtool.
>
>You have to regenerate it with
>
> aclocal -I ../config -I .. -I.
>
>or something like that.

It's a minor nit but doesn't the "-I .." rather than "-I.." bother anyone?
It just seems inconsistent.

cgf

Re: Final(?) patch to update libtool in GCC and src trees

[Charles Wilson]

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

Charles Wilson wrote:
> Steve Ellcey wrote:
>>>   I appreciate the problem, but Cygwin can be a bit 'special' when it 
>>> comes to
>>> libtool; if it hasn't been done yet, can you possibly bear to hold 
>>> off a bit
>>> while I give it some hasty testing?  (By 'a bit', I mean no more than 
>>> say
>>> 'overnight').  Sorry to be a pain :-/
>>
>> I can wait, especially since no one has given me the go ahead yet.  :-)
>> I know of no cygwin testing that has been done.
>
> I'll rip that failed experiment out of my tree and try again with just 
> Steve's patches; however I'd imagine Dave Korn will have results before 
> I do.

Well, I ran into some trouble, related to the new libtool.  I'm building 
in a combined tree, with binutils and gcc, but not winsup or newlib. 
(configuration args at end of post).  All of the binutils stuff built 
fine (non-shared, natch).  The error is this, when I get into building 
libgcc (stage1):

configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2

In _build/i686-pc-cygwin/libgcc, config.log shows:

configure:2587: /usr/local/src/gcc/_build/./gcc/xgcc 
-B/usr/local/src/gcc/_build
/./gcc/ -B/opt/i686-pc-cygwin/bin/ -B/opt/i686-pc-cygwin/lib/ -isystem 
/opt/i686
-pc-cygwin/include -isystem /opt/i686-pc-cygwin/sys-include 
-L/usr/local/src/gcc
/_build/./ld -c -O2 -g -O2   conftest.c >&5
/bin/sh: /usr/local/src/gcc/_build/./gcc/as: No such file or directory

Taking a look in _build/./gcc, ls -l (for selected files) shows:

-rwxr-xr-x 2 cwilson None     5632 Apr 11 03:57 as.exe*
-rwxr-xr-x 2 cwilson None     5632 Apr 11 03:58 collect-ld.exe*
-rwxr-xr-x 2 cwilson None     5632 Apr 11 03:55 nm.exe*

These .exe files are all hardlinks (I'm using cygwin on NTFS, where 
hardlinks work) to *wrapper* executables (here's the relevant section 
from stdout during the build):

creating as
ln ../gas/as-new.exe as.exe
echo timestamp > stamp-as
creating collect-ld
ln ../ld/ld-new.exe collect-ld.exe
echo timestamp > stamp-collect-ld
creating nm
ln ../binutils/nm-new.exe nm.exe
echo timestamp > stamp-nm

This is wrong.  libtool-ToT (and libtool-1.5) on cygwin and mingw, when 
shared libraries are "in the mix", use the following scheme:

(1) a wrapper script (./foo) is used in the "normal" libtool way to set 
$PATH so that just-built .dll's can be located by the wrapped 
executable.  It will invoke the actual executable (./.libs/foo.exe)

(2) a wrapper executable (./foo.exe) whose sole purpose is to ensure 
that 'make' is happy.  New automake-derived Makefile.in's (and thus, 
Makefile's) have program targets like 'foo$(EXEEXT):'.  If only 'foo' 
exists, then 'make' thinks that the target wasn't built, and continually 
relinks executables...over and over and over.  So, we arrange that 
libtool produces a wrapper executable in . with the correct name, so 
that 'make' will know that the target has been satisfied.  The wrapper 
executable then runs the wrapper script via 'execv("$SHELL",newargz);' 
where newargz is a copy of all args to the wrapper script, with [0] set 
to the path ${thisdir}/foo  (e.g. the wrapper /script/).

(3) ./.libs/foo.exe is the "actual" executable.

Thus, on mingw/cygwin, the "top-level" wrapper is ./foo.exe which calls 
./foo which calls ./.libs/foo.exe

On other platforms, the "top-level" wrapper is ./foo (a script), which 
calls .libs/foo (an executable).

But there's still a problem (and this may affect other platforms; 
*should* do so, I think -- so I'm confused by Steve's success here; 
Steve: are you building the src/ stuff separately from the gcc stuff, or 
are you using a combined tree like I am?  I think the issue I am seeing 
will affect all platforms, but only if doing a combined build AND when 
--disable-shared is NOT explicitly passed during configure).

Current code in gcc/Makefile.in is

stamp-as: $(ORIGINAL_AS_FOR_TARGET)
         @echo creating as; \
         case "$(ORIGINAL_AS_FOR_TARGET)" in \
           ./as) ;; \
           ../*) \
              rm -f as$(exeext); \
              echo $(LN) $< as$(exeext); \
              $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
           *) \
              rm -f as; \
              echo '#!$(SHELL)' > as; \
              echo 'exec $(ORIGINAL_AS_FOR_TARGET) "$$@"' >> as ; \
              chmod +x as ;; \
         esac
         echo timestamp > $@

The source code for the wrapper executable (if you're curious, it is 
embedded in ltmain.sh), says:

   This wrapper executable should never be moved out of the build
   directory. If it is, it will not operate correctly.

Similarly, wrapper scripts say the following:

# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.

They can be exec'ed via a relative PATH, but you can't just copy (or 
hardlink) the wrapper to a different directory, and invoke that 
copy/hardlink -- because it will then look in the wrong place for 
.libs/<actual-executable> (non-cygwin) or ./<wrapper-script> 
(cygwin/mingw).  You *can* create a symlink to the wrapper /script/, and 
it will work properly (it walks its own symlink path back to the "real" 
script, before computing the directory in which to look for the target 
executable).  However, the wrapper /executable/ does not have this 
ability -- so symlinking to the wrapper executable is a no-go.

However, we can't use symlinks anyway, because (according to 
gcc/Makefile.in):

# We need hard links so that directories can be shuffled
# during toplevel bootstrap.


So, I'm not really sure how this worked, even on "normal" 
platforms...unless Steve wasn't doing a top-level (combined-tree) bootstrap.


=======

It's a little unorthodox (and assumes a lot about libtool's 
implementation) but we COULD:

(1) hardlink/copy ${ORIGINAL_AS_FOR_TARGET--without-$exeext} .
(2) hardlink/copy ${ORIGINAL_AS_FOR_TARGET--with_$exeext} .
(3) mkdir .libs
(4) hardlink/copy ${ORIGINAL_AS_FOR_TARGET--with-/.libs/-inserted} .libs/

all with appropriate existence checks. And since (e.g) ld-new gets 
renamed to collect-ld, you'd have to rename (both) wrappers, similarly 
-- but NOT rename the .libs/ inhabitant.  (This is because the 
executable wrapper inspects argv[0] to figure out how to invoke the 
script wrapper.  The script wrapper doesn't care what its own name is, 
it just "knows" what its target in .libs/ *should* be named.)

But what a mess.  I've attached a preliminary patch for gcc/Makefile.in. 
It works for native/cygwin -- that is, it gets me past THAT problem -- 
but some more testing for other platforms and crosses is definitely in 
order...

Obviously this patch depends on Steve's new libtool stuff.

2007-04-11  Charles Wilson  <...>

	* gcc/Makefile.in [stamp-as]: handle libtool wrappers when
	copying binutils applications during combined-tree build.
	[stamp-collect-ld]: ditto
	[stamp-nm]: ditto

--
Chuck


configure options:
${RELSRCDIR}/configure \
   --prefix=/opt \
   --exec-prefix=/opt \
   --sysconfdir=/opt/etc \
   --libdir=/opt/lib \
   --libexecdir=/opt/lib \
   --mandir=/opt/share/man \
   --infodir=/opt/share/info \
   --with-datarootdir=/opt/share \
   --enable-languages=c,c++,objc,fortran \
   --with-gcc \
   --enable-nls \
   --without-included-gettext \
   --enable-version-specific-runtime-libs \
   --without-x \
   --with-system-zlib \
   --enable-threads=posix \
   --disable-win32-registry \
   --disable-sjlj-exceptions \ [*]
   --enable-libstdcxx-debug \
   --enable-cxx-flags='-fno-function-sections -fno-data-sections' \
   --enable-libgomp \
   --with-arch=i486 \
   --with-tune=i686 \
   --disable-werror

[*] oh yeah, I've also got Danny Smith's dwarf2 exceptions patch 
(20061203) in my tree.

And that's my next roadblock: the dwarf2 patch adds crtbegin.o/crtend.o 
to cygwin's build, and I get:
../../combined_src/gcc/crtstuff.c:445:2: error: #error "What are you 
doing with crtstuff.c, then?"

Sigh.


[-- Attachment #2: gcc-Makefile.in-handle-libtool-wrappers-csw20070411.patch --]
[-- Type: text/plain, Size: 3343 bytes --]

Index: Makefile.in
===================================================================
--- Makefile.in	(revision 123710)
+++ Makefile.in	(working copy)
@@ -1478,8 +1478,31 @@
 	  ./as) ;; \
 	  ../*) \
 	     rm -f as$(exeext); \
+	     if [ -e as ]; then \
+	       rm -f as ;\
+	     fi ;\
+	     if [ -e .libs/as$(exeext) ]; then \
+	       rm -f .libs/as$(exeext) ;\
+	     fi ;\
 	     echo $(LN) $< as$(exeext); \
-	     $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
+	     $(LN) $< as$(exeext) || cp $< as$(exeext) ;\
+	     if [ -n "$(exeext)" ]; then \
+	       if [ -e $(<:%$(exeext)=%) ]; then \
+	         echo $(LN) $(<:%$(exeext)=%) as ;\
+	         $(LN) $(<:%$(exeext)=%) as ||\
+	           cp $(<:%$(exeext)=%) as ;\
+	       fi ;\
+	     fi ;\
+	     if [ -e $(<D)/.libs ]; then \
+	       if [ ! -e .libs ]; then \
+	         mkdir .libs ;\
+	       fi ;\
+	       if [ -e $(<D)/.libs/$(<F) ]; then \
+	         echo $(LN) $(<D)/.libs/$(<F) .libs/$(<F);\
+	         $(LN) $(<D)/.libs/$(<F) .libs/$(<F) ||\
+	           cp $(<D)/.libs/$(<F) .libs/$(<F) ;\
+	       fi ;\
+	     fi ;; \
 	  *) \
 	     rm -f as; \
 	     echo '#!$(SHELL)' > as; \
@@ -1494,8 +1517,31 @@
 	  ./collect-ld) ;; \
 	  ../*) \
 	     rm -f collect-ld$(exeext); \
+	     if [ -e collect-ld ]; then \
+	       rm -f collect-ld ;\
+	     fi ;\
+	     if [ -e .libs/collect-ld$(exeext) ]; then \
+	       rm -f .libs/collect-ld$(exeext) ;\
+	     fi ;\
 	     echo $(LN) $< collect-ld$(exeext); \
-	     $(LN) $< collect-ld$(exeext) || cp $< collect-ld$(exeext) ;; \
+	     $(LN) $< collect-ld$(exeext) || cp $< collect-ld$(exeext) ;\
+	     if [ -n "$(exeext)" ]; then \
+	       if [ -e $(<:%$(exeext)=%) ]; then \
+	         echo $(LN) $(<:%$(exeext)=%) collect-ld ;\
+	         $(LN) $(<:%$(exeext)=%) collect-ld ||\
+	           cp $(<:%$(exeext)=%) collect-ld ;\
+	       fi ;\
+	     fi ;\
+	     if [ -e $(<D)/.libs ]; then \
+	       if [ ! -e .libs ]; then \
+	         mkdir .libs ;\
+	       fi ;\
+	       if [ -e $(<D)/.libs/$(<F) ]; then \
+	         echo $(LN) $(<D)/.libs/$(<F) .libs/$(<F);\
+	         $(LN) $(<D)/.libs/$(<F) .libs/$(<F) ||\
+	           cp $(<D)/.libs/$(<F) .libs/$(<F) ;\
+	       fi ;\
+	     fi ;; \
 	  *) \
 	     rm -f collect-ld$(exeext); \
 	     echo '#!$(SHELL)' > collect-ld; \
@@ -1510,8 +1556,31 @@
 	  ./nm) ;; \
 	  ../*) \
 	     rm -f nm$(exeext); \
+	     if [ -e nm ]; then \
+	       rm -f nm ;\
+	     fi ;\
+	     if [ -e .libs/nm$(exeext) ]; then \
+	       rm -f .libs/nm$(exeext) ;\
+	     fi ;\
 	     echo $(LN) $< nm$(exeext); \
-	     $(LN) $< nm$(exeext) || cp $< nm$(exeext) ;; \
+	     $(LN) $< nm$(exeext) || cp $< nm$(exeext) ;\
+	     if [ -n "$(exeext)" ]; then \
+	       if [ -e $(<:%$(exeext)=%) ]; then \
+	         echo $(LN) $(<:%$(exeext)=%) nm ;\
+	         $(LN) $(<:%$(exeext)=%) nm ||\
+	           cp $(<:%$(exeext)=%) nm ;\
+	       fi ;\
+	     fi ;\
+	     if [ -e $(<D)/.libs ]; then \
+	       if [ ! -e .libs ]; then \
+	         mkdir .libs ;\
+	       fi ;\
+	       if [ -e $(<D)/.libs/$(<F) ]; then \
+	         echo $(LN) $(<D)/.libs/$(<F) .libs/$(<F);\
+	         $(LN) $(<D)/.libs/$(<F) .libs/$(<F) ||\
+	           cp $(<D)/.libs/$(<F) .libs/$(<F) ;\
+	       fi ;\
+	     fi ;; \
 	  *) \
 	     rm -f nm$(exeext); \
 	     echo '#!$(SHELL)' > nm; \

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

> It's a little unorthodox (and assumes a lot about libtool's 
> implementation) but we COULD:
> 
> (1) hardlink/copy ${ORIGINAL_AS_FOR_TARGET--without-$exeext} .
> (2) hardlink/copy ${ORIGINAL_AS_FOR_TARGET--with_$exeext} .
> (3) mkdir .libs
> (4) hardlink/copy ${ORIGINAL_AS_FOR_TARGET--with-/.libs/-inserted} .libs/

Another possibility (and I would be grateful if you would test this) is 
to confine all this stuff into a script, something like this (I'll call 
it exec-tool.in):

#! /bin/sh

ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
ORIGINAL_LD_FOR_TARGET="@ORIGINAL_LD_FOR_TARGET@"
ORIGINAL_NM_FOR_TARGET="@ORIGINAL_NM_FOR_TARGET@"

invoked=`basename "$0"`
case "$invoked" in
   as)
     original=$ORIGINAL_AS_FOR_TARGET
     prog=as-new
     dir=gas
     ;;
   collect-ld)
     original=$ORIGINAL_LD_FOR_TARGET
     prog=ld-new
     dir=ld
     ;;
   nm)
     original=$ORIGINAL_NM_FOR_TARGET
     prog=nm-new
     dir=binutils
     ;;
esac

case "$original" in
   ../*)
     if test -x ../$dir/$prog; then
       exec ../$dir/$prog ${1+"$@"}
     else
       exec ../prev-$dir/$prog ${1+"$@"}
     fi
     ;;
   *)
     exec "$original" ${1+"$@"}
     ;;
esac



Then, you *can* use symlinks.  So in configure.ac you can simply do

AC_CONFIG_FILES(exec-tool.sh:exec-tool.in, [chmod +x exec-tool.sh])
case "$ORIGINAL_AS_FOR_TARGET" in
   ./as) ;;
   *) AC_CONFIG_LINKS(as:exec-tool.sh) ;;
esac
case "$ORIGINAL_LD_FOR_TARGET" in
   ./collect-ld) ;;
   *) AC_CONFIG_LINKS(collect-ld:exec-tool.sh) ;;
esac
case "$ORIGINAL_NM_FOR_TARGET" in
   ./nm) ;;
   *) AC_CONFIG_LINKS(nm:exec-tool.sh) ;;
esac

and drop all the as/collect-ld/nm rules from Makefile.in.

Paolo

RE: Final(?) patch to update libtool in GCC and src trees

[Dave Korn]

On 11 April 2007 22:41, Christopher Faylor wrote:

> On Wed, Apr 11, 2007 at 12:18:56PM +0200, Paolo Bonzini wrote:
>> Dave Korn wrote:
>>> On 11 April 2007 10:25, Paolo Bonzini wrote:
>>> 
>>>>>  That would be the freshly regenerated one:
>>>>> 
>>>>> /usr/build/src-winsup/newlib $ head -1 aclocal.m4
>>>>> # generated automatically by aclocal 1.9.6 -*- Autoconf -*- Can you
>>>>> please attach it? 
>>> 
>>>  Cc list trimmed a bit :-)
>> 
>> aclocal used your 1.5.x libtool, instead of the new GCC libtool.
>> 
>> You have to regenerate it with
>> 
>> aclocal -I ../config -I .. -I.
>> 
>> or something like that.
> 
> It's a minor nit but doesn't the "-I .." rather than "-I.." bother anyone?
> It just seems inconsistent.
> 
> cgf

  Alas, it didn't help; the same problem recurred.  The only difference in the
newly-generated-but-still-faulty aclocal.m4 as compared to my previous attempt
was:

/usr/build/src-winsup/newlib $ diff -pu aclocal.m4.save  aclocal.m4
--- aclocal.m4.save     2007-04-11 10:58:44.830368700 +0100
+++ aclocal.m4  2007-04-11 16:04:18.826887600 +0100
@@ -6953,27 +6953,6 @@ AC_DEFUN([AM_PROG_INSTALL_SH],
 install_sh=${install_sh-"$am_aux_dir/install-sh"}
 AC_SUBST(install_sh)])

-# Copyright (C) 2003, 2005  Free Software Foundation, Inc.
-#
-# This file is free software; the Free Software Foundation
-# gives unlimited permission to copy and/or distribute it,
-# with or without modifications, as long as this notice is preserved.
-
-# serial 2
-
-# Check whether the underlying file-system supports filenames
-# with a leading dot.  For instance MS-DOS doesn't.
-AC_DEFUN([AM_SET_LEADING_DOT],
-[rm -rf .tst 2>/dev/null
-mkdir .tst 2>/dev/null
-if test -d .tst; then
-  am__leading_dot=.
-else
-  am__leading_dot=_
-fi
-rmdir .tst 2>/dev/null
-AC_SUBST([am__leading_dot])])
-
 # Add --enable-maintainer-mode option to configure.         -*- Autoconf -*-
 # From Jim Meyering

@@ -7362,4 +7341,10 @@ AC_SUBST([am__tar])
 AC_SUBST([am__untar])
 ]) # _AM_PROG_TAR

+m4_include([../libtool.m4])
+m4_include([../ltoptions.m4])
+m4_include([../ltsugar.m4])
+m4_include([../ltversion.m4])
+m4_include([../config/depstand.m4])
+m4_include([../config/lead-dot.m4])
 m4_include([acinclude.m4])



  Leading to the same issues at configure time:



configure:3737: checking for a BSD-compatible install
configure:3793: result: /usr/bin/install -c
configure:3808: checking whether to enable maintainer-specific portions of
Makefiles
configure:3817: result: no
configure:21892: checking for .preinit_array/.init_array/.fini_array support
configure:21905: gcc -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/cygwin
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/w32api/lib -isystem
/usr/build/src-winsup/winsup/include -isystem
/usr/build/src-winsup/winsup/cygwin/include -isystem
/usr/build/src-winsup/winsup/w32api/include
-B/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/ -isystem
/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/targ-include -isystem
/usr/build/src-winsup/newlib/libc/include
-I/usr/build/src-winsup/winsup/cygwin/include    -o conftest conftest.c
		   -static -nostartfiles -nostdlib 1>&5
configure:21908: $? = 0
configure:21921: result: no
configure:21931: checking for array aliasing support
configure:21942: gcc -L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/cygwin
-L/usr/build/obj-winsup.new/i686-pc-cygwin/winsup/w32api/lib -isystem
/usr/build/src-winsup/winsup/include -isystem
/usr/build/src-winsup/winsup/cygwin/include -isystem
/usr/build/src-winsup/winsup/w32api/include
-B/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/ -isystem
/usr/build/obj-winsup.new/i686-pc-cygwin/newlib/targ-include -isystem
/usr/build/src-winsup/newlib/libc/include
-I/usr/build/src-winsup/winsup/cygwin/include   -c conftest.c
		   1>&5
conftest.c:1: warning: excess elements in scalar initializer
conftest.c:1: warning: (near initialization for `x3')
conftest.c:1: warning: excess elements in scalar initializer
conftest.c:1: warning: (near initialization for `x3')
configure:21945: $? = 0
configure:21954: result: yes
configure:22030: updating cache ./config.cache
configure:22141: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.



  Charles W. made some suggestions offlist which I'll try later, but I need to
concentrate on my day job right now :)



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

Charles Wilson wrote:

> But there's still a problem (and this may affect other platforms; 
> *should* do so, I think -- so I'm confused by Steve's success here; 
> Steve: are you building the src/ stuff separately from the gcc stuff, or 
> are you using a combined tree like I am?  I think the issue I am seeing 
> will affect all platforms, but only if doing a combined build AND when 
> --disable-shared is NOT explicitly passed during configure).

Yes, I build src seperately from gcc.  I.e. not a combined tree.

Steve Ellcey
sje@cup.hp.com

Re: Final(?) patch to update libtool in GCC and src trees

[Charles Wilson]

On Thu, 12 Apr 2007 08:13:00 -0700 (PDT), "Steve Ellcey"
> Charles Wilson wrote:
> 
> > But there's still a problem (and this may affect other platforms; 
> > *should* do so, I think -- so I'm confused by Steve's success here; 
> > Steve: are you building the src/ stuff separately from the gcc stuff, or 
> > are you using a combined tree like I am?  I think the issue I am seeing 
> > will affect all platforms, but only if doing a combined build AND when 
> > --disable-shared is NOT explicitly passed during configure).
> 
> Yes, I build src seperately from gcc.  I.e. not a combined tree.

Thanks for the clarification.  I guess my use of a combined tree exposed
a weakness in your libtool patch, but hopefully Paolo's contribution (
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00663.html ) will plug that
hole, and we can move closer to getting your stuff in-tree.

--
Chuck

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

> OK to checkin?

I checked in the patch to fix the as/ld/nm problem on cygwin, but there 
are still other issues to be solved.  However, I'm sure we can first of 
all limit your pain in maintaining the patch.  So, if you wish, you can 
checkin everything *but the new libtool* after testing on just one 
platform (combined tree, or separate gcc/src builds are both okay), with 
the changes I indicate below.

The patch is preapproved with those changes, but please post it again.

> Top level src tree ChangeLog:
> 
> 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> 	* src-release: Update with new libtool file list.

Obviously leave this out for now too, and keep config-ml.in in sync 
between gcc and src.

> bfd/ChangeLog
> 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> 	* configure.in: Change macro call order.
> 	* aclocal.m4: Regenerate.
> 	* Makefile.in: Regnerate.
> 	* configure: Regenerate.

Here, please add -I .. to Makefile.am's ACLOCAL_AMFLAGS instead of 
modifying acinclude.m4.


> gas/ChangeLog
> 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> 	* acinclude.m4: Add new includes.
> 	* aclocal.m4: Regenerate.
> 	* Makefile.in: Regenerate.
> 	* configure: Regenerate.

Likewise.

> gprof/ChangeLog
> 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> 	* acinclude.m4: Add new includes.
> 	* aclocal.m4: Regenerate.
> 	* Makefile.in: Regenerate.
> 	* configure: Regenerate.

Likewise.

> rda/ChangeLog
> 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> 	* acinclude.m4: Add new includes.
> 	* aclocal.m4: Regenerate.
> 	* Makefile.in: Regenerate.
> 	* configure: Regenerate.

Likewise.

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

> The patch is preapproved with those changes, but please post it again.

Just to be clear, this approval is for both the GCC and the Src tree
right?

> > Top level src tree ChangeLog:
> > 
> > 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> > 	* src-release: Update with new libtool file list.
> 
> Obviously leave this out for now too, and keep config-ml.in in sync 
> between gcc and src.

OK, If the config-ml.in change works with the old libtool I will make
the change in both trees.  Otherwise I will leave them both alone.

> > bfd/ChangeLog
> > 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> > 	* configure.in: Change macro call order.
> > 	* aclocal.m4: Regenerate.
> > 	* Makefile.in: Regnerate.
> > 	* configure: Regenerate.
> 
> Here, please add -I .. to Makefile.am's ACLOCAL_AMFLAGS instead of 
> modifying acinclude.m4.

That seems like a good idea.  I did the change with sinclude because the
src tree seemed to use sinclude's instead of ACLOCAL_AMFLAGS.  If I am
adding ACLOCAL_AMFLAGS should I add -I ../config and -I ../bfd too and
remove all the sinclude statements from the acinclude.m4 scripts?

My plan is to make the changes you want, test with the new libtool to
make sure that works, then revert to the old libtool, retest, and check
in the changes when that works.  It may take a few days.

Steve Ellcey
sje@cup.hp.com

Re: Final(?) patch to update libtool in GCC and src trees

[Daniel Jacobowitz]

On Fri, Apr 13, 2007 at 10:07:35AM -0700, Steve Ellcey wrote:
> That seems like a good idea.  I did the change with sinclude because the
> src tree seemed to use sinclude's instead of ACLOCAL_AMFLAGS.  If I am
> adding ACLOCAL_AMFLAGS should I add -I ../config and -I ../bfd too and
> remove all the sinclude statements from the acinclude.m4 scripts?

No - feel free to try that later, if you want, but this is doing
enough things at once already :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

Daniel Jacobowitz wrote:
> On Fri, Apr 13, 2007 at 10:07:35AM -0700, Steve Ellcey wrote:
>> That seems like a good idea.  I did the change with sinclude because the
>> src tree seemed to use sinclude's instead of ACLOCAL_AMFLAGS.  If I am
>> adding ACLOCAL_AMFLAGS should I add -I ../config and -I ../bfd too and
>> remove all the sinclude statements from the acinclude.m4 scripts?
> 
> No - feel free to try that later, if you want, but this is doing
> enough things at once already :-)

Fully agreed. :-)

(Though, this is *not* including the libtool update on purpose).

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

> My plan is to make the changes you want, test with the new libtool to
> make sure that works, then revert to the old libtool, retest, and check
> in the changes when that works.  It may take a few days.

That's a safe plan.  I suggest a quicker smoke test though: this patch 
should result in no change to configure -- both with old libtool 
compared to CVS, and with new libtool compared to your previous patch.

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

> Daniel Jacobowitz wrote:
> > On Fri, Apr 13, 2007 at 10:07:35AM -0700, Steve Ellcey wrote:
> >> That seems like a good idea.  I did the change with sinclude because the
> >> src tree seemed to use sinclude's instead of ACLOCAL_AMFLAGS.  If I am
> >> adding ACLOCAL_AMFLAGS should I add -I ../config and -I ../bfd too and
> >> remove all the sinclude statements from the acinclude.m4 scripts?
> > 
> > No - feel free to try that later, if you want, but this is doing
> > enough things at once already :-)
> 
> Fully agreed. :-)
> 
> (Though, this is *not* including the libtool update on purpose).
> 
> Paolo

This feels backwards to me.

I think we should do a Src tree only patch (GCC tree doesn't need this
change) to set ACLOCAL_AMFLAGS and to remove the use of sinclude before
doing anything else with libtool.

Then, when we go to update libtool, no other changes should be needed in
the src tree.  In other words, do the clean up first.

I'll even go further and say that we should move the m4 macros that are
currently in bfd and used by other components over to the config
directory as part of this patch.  These files are acinclude.m4, bfd.m4,
and warning.m4.  That way we don't have to put -I ../bfd in the
ACLOCAL_AMFLAGS variable at all.  We set ACLOCAL_AMFLAGS to "-I ..  -I
../config" and we are done with it.

Would such a patch, done before any of the other libtool changes, be
acceptable?

Steve Ellcey
sje@cup.hp.com

Re: Final(?) patch to update libtool in GCC and src trees

[Paolo Bonzini]

> This feels backwards to me.
> 
> I think we should do a Src tree only patch (GCC tree doesn't need this
> change) to set ACLOCAL_AMFLAGS and to remove the use of sinclude before
> doing anything else with libtool.

It might be, but I was just trying to be helpful and make the libtool 
patch as small (and easy to maintain as possible).  Other cleanups, 
while much appreciated, are tangential.

(Besides, I am going on vacation on the 22nd and wanted to get the patch 
in before that!)

Paolo

Re: Final(?) patch to update libtool in GCC and src trees

[Steve Ellcey]

> It might be, but I was just trying to be helpful and make the libtool 
> patch as small (and easy to maintain as possible).  Other cleanups, 
> while much appreciated, are tangential.
> 
> (Besides, I am going on vacation on the 22nd and wanted to get the patch 
> in before that!)
> 
> Paolo

OK, I will do the original patch (with your changes) first and leave
the rest for later.

Steve

Re: Final(?) patch to update libtool in GCC and src trees

[Charles Wilson]

Steve Ellcey wrote:
> This feels backwards to me.
> 
> I think we should do a Src tree only patch (GCC tree doesn't need this
> change) to set ACLOCAL_AMFLAGS and to remove the use of sinclude before
> doing anything else with libtool.
> 
> Then, when we go to update libtool, no other changes should be needed in
> the src tree.  In other words, do the clean up first.

This is logical -- but I think the other posters are worried that your 
existing patch has gone thru several weeks of testing, on some 
non-homogeneous set of platforms/targets/configurations.  Your proposed 
change has not.

I suspect that if you want to pursue this order-of-commits, you will be 
asked to get the "cleanup" patches validated by a similar test regime, 
and that will only extend the time you must maintain the libtool-centric 
patches out-of-tree.

> I'll even go further and say that we should move the m4 macros that are
> currently in bfd and used by other components over to the config
> directory as part of this patch.  These files are acinclude.m4, bfd.m4,
> and warning.m4.  That way we don't have to put -I ../bfd in the
> ACLOCAL_AMFLAGS variable at all.  We set ACLOCAL_AMFLAGS to "-I ..  -I
> ../config" and we are done with it.

Agree with respect to bfd.m4 and warning.m4 (subject to the concerns 
above).  But acinclude.m4 is intended to be specific to each 
independently configured project (or subproject with its own 
configure.[ac|in]).  That's why there are a lot of acinclude.m4 files in 
the src/ tree:

-rw-r--r-- 1 cwilson None  2948 Mar 24 18:04 ./bfd/acinclude.m4
-rw-r--r-- 1 cwilson None    30 May 15  2005 ./binutils/acinclude.m4
-rwxr-xr-x 1 cwilson None 66436 Jan 14  2004 ./config/acinclude.m4
-rw-r--r-- 1 cwilson None  2658 Mar 24 18:06 ./gas/acinclude.m4
-rw-r--r-- 1 cwilson None   505 Mar 24 18:06 ./gprof/acinclude.m4
-rw-r--r-- 1 cwilson None    30 May 15  2005 ./ld/acinclude.m4
-rw-r--r-- 1 cwilson None   534 May 31  2006 ./opcodes/acinclude.m4
-rw-r--r-- 1 cwilson None  1174 May 24  2006 ./winsup/acinclude.m4
-rw-r--r-- 1 cwilson None  7319 Feb  5 17:57 ./newlib/acinclude.m4
<maybe more in modules I do not have checked out>

Frankly, The Right Thing To Do is to take each acinclude.m4, and split 
them up into functionally-independent my-descriptive-name.m4's.  Then, 
perhaps move (common ones? identical ones that appeared in multiple 
acinclude's? all of them?) into config/, do away with all acinclude.m4's 
and let aclocal do its job. [caveat: except perhaps if there are any 
cases where automake/aclocal are not used to maintain the existing 
aclocal.m4 file; it does not appear to me that any of the components in 
src/ meet that exception]

But that is an large effort, and one that is completely orthogonal to 
your existing patches, and should be handled separately.  And getting 
modern libtool support into the tree should not be predicated on this 
separate effort, IMO.

> Would such a patch, done before any of the other libtool changes, be
> acceptable?

See above.

--
Chuck