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

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

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
[hidden email]


Top level GCC tree ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * 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  <[hidden email]>
        * 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  <[hidden email]>
        * 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  <[hidden email]>
        * Makefile.am: Add -I .. to ACLOCAL_AMFLAGS.
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

libstdc++-v3/ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * 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  <[hidden email]>
        * aclocal.m4: Regenerate.
        * configure: Regenerate.

libmudflap/ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * testsuite/Makefile.in: Regenerate.
        * configure: Regenerate.

boehm-gc/ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * include/Makefile.in: Regenerate.
        * configure: Regenerate.

libffi/ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * include/Makefile.in: Regenerate.
        * testsuite/Makefile.in: Regenerate.
        * configure: Regenerate.

libssp/ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

libjava/ChangeLog:

2007-03-22  Steve Ellcey  <[hidden email]>
        * 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  <[hidden email]>
        * 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  <[hidden email]>
        * 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  <[hidden email]>
        * configure.in: Change macro call order.
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

gas/ChangeLog
2007-03-22  Steve Ellcey  <[hidden email]>
        * acinclude.m4: Add new includes.
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

gprof/ChangeLog
2007-03-22  Steve Ellcey  <[hidden email]>
        * acinclude.m4: Add new includes.
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

rda/ChangeLog
2007-03-22  Steve Ellcey  <[hidden email]>
        * acinclude.m4: Add new includes.
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

ld/ChangeLog
2007-03-22  Steve Ellcey  <[hidden email]>
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

opcodes/ChangeLog
2007-03-22  Steve Ellcey  <[hidden email]>
        * aclocal.m4: Regenerate.
        * Makefile.in: Regenerate.
        * configure: Regenerate.

newlib/ChangeLog
2007-03-22  Steve Ellcey  <[hidden email]>
        * 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
Reply | Threaded
Open this post in threaded view
|

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

Andrew Pinski-3
On 4/10/07, Steve Ellcey <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Dave Korn
In reply to this post by Steve Ellcey
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....

Reply | Threaded
Open this post in threaded view
|

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

Steve Ellcey
In reply to this post by Andrew Pinski-3
> 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)
Reply | Threaded
Open this post in threaded view
|

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

Steve Ellcey
In reply to this post by Dave Korn
>   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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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

Dave Korn
In reply to this post by Steve Ellcey
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....

Reply | Threaded
Open this post in threaded view
|

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

Charles Wilson-6
In reply to this post by Steve Ellcey
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
Reply | Threaded
Open this post in threaded view
|

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

Paolo Bonzini
In reply to this post by Dave Korn
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
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab
Paolo Bonzini <[hidden email]> 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, [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: 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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

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

aclocal.m4.bz2 (68K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

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

Christopher Faylor-9
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
Reply | Threaded
Open this post in threaded view
|

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

Charles Wilson-4
In reply to this post by Charles Wilson-6
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.


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; \
Reply | Threaded
Open this post in threaded view
|

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
12