Re: Patch to update libtool in GCC and binutils trees

Re: Patch to update libtool in GCC and binutils trees

[Charles Wilson]

This:

> 	if ${CONFIG_SHELL-/bin/sh} ./libtool --tag CXX --features |
> 	   grep "enable shared" > /dev/null;
> 	then
> 	  LIBSUPCXX_PICFLAGS=-prefer-pic
> 	else
> 	  LIBSUPCXX_PICFLAGS=
> 	fi

isn't the correct mechanism, anymore.  From the new libtool's .info:

===========================================
    With 1.3 era libtool, if you wanted to know any details of what
libtool had discovered about your architecture and environment, you had
to run the script with `--config' and grep through the results.  This
idiom was supported up to and including 1.5.x era libtool, where it was
possible to call the generated libtool script from `configure.ac' as
soon as `LT_INIT' had completed.  However, one of the features of
libtool 1.4 was that the libtool configuration was migrated out of a
separate `ltconfig' file, and added to the `LT_INIT' macro (nee
`AC_PROG_LIBTOOL'), so the results of the configuration tests were
available directly to code in `configure.ac', rendering the call out to
the generated libtool script obsolete.

    Starting with libtool 2.0, the multipass generation of the libtool
script has been consolidated into a single `config.status' pass, which
happens after all the code in `configure.ac' has completed.  The
implication of this is that the libtool script does not exist during
execution of code from `configure.ac', and so obviously it cannot be
called for `--config' details anymore.  If you are upgrading projects
that used this idiom to libtool 2.0 or newer, you should replace those
calls with direct references to the equivalent Autoconf shell variables
that are set by the configure time tests before being passed to
`config.status' for inclusion in the generated libtool script.
===========================================

So, short version: the code above should be replaced with [untested]:

	LIBSUPCXX_PICFLAGS=
	test "$enable_shared" = yes && LIBSUPCXX_PICFLAGS=-prefer-pic

Also, this:

AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL

should be replaced with

LT_INIT([dlopen win32-dll])

(okay, the win32-dll part would correspond to the deprecated 
AC_LIBTOOL_WIN32_DLL macro, which isn't actually present in libstdc++'s 
existing configure.ac.  But it would be nice if...)

--
Chuck

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

Charles Wilson wrote:

> 	LIBSUPCXX_PICFLAGS=
> 	test "$enable_shared" = yes && LIBSUPCXX_PICFLAGS=-prefer-pic

Thanks, testing $enable_shared fixes the build problem.

I still have a problem when testing libstdc++.  On IA64 HP-UX, when
testing in 64 bit mode, I look at
obj_gcc/ia64-hp-hpux11.23/hpux64/libstdc++-v3/testsuite/Makefile

and I see:

CXX =  /proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/./gcc/xgcc -shared-libgcc -B/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/./gcc -nostdinc++ -L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src -L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src/.libs -B/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/bin/ -B/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/lib/ -isystem /proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/include -isystem /proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/sys-include

The problem is:

	-L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src
	-L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src/.libs

These don't have the 'hpux64' multilib directory inserted between
ia64-hp-hpux11.23 and libstdc++-v3.  When I do a build/test with the old
libtool the hpux64 directory is there.

Any idea on where this is going wrong?

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Ralf Wildenhues]

* Steve Ellcey wrote on Fri, Mar 30, 2007 at 07:47:36PM CEST:
> 
> I still have a problem when testing libstdc++.  On IA64 HP-UX, when
> testing in 64 bit mode, I look at
> obj_gcc/ia64-hp-hpux11.23/hpux64/libstdc++-v3/testsuite/Makefile
> 
> and I see:
> 
> CXX =  /proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/./gcc/xgcc -shared-libgcc -B/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/./gcc -nostdinc++ -L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src -L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src/.libs -B/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/bin/ -B/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/lib/ -isystem /proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/include -isystem /proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/ia64-hp-hpux11.23/sys-include
> 
> The problem is:
> 
> 	-L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src
> 	-L/proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/src/.libs
> 
> These don't have the 'hpux64' multilib directory inserted between
> ia64-hp-hpux11.23 and libstdc++-v3.  When I do a build/test with the old
> libtool the hpux64 directory is there.
> 
> Any idea on where this is going wrong?

could you post the difference of the toplevel Makefile and config.log
files with old/new libtool?  AFAICS these lines get added there, but
I don't see yet how Libtool comes into play for this difference.

Thanks, and please Cc: me on replies,
Ralf

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

> could you post the difference of the toplevel Makefile and config.log
> files with old/new libtool?  AFAICS these lines get added there, but
> I don't see yet how Libtool comes into play for this difference.
> 
> Thanks, and please Cc: me on replies,
> Ralf

Hm, The toplevel Makefile does not appear to be different between the
versions with the new and old libtool.  But I noticed, looking at
obj_gcc/x86_64-suse-linux-gnu/32/libstdc++-v3/config.log, in the old
libtool tree I see:

=========

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by package-unused configure version-unused, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ /proj/opensrc/sje/svn.reg/src/trunk/libstdc++-v3/configure --with-multisubdi
r=32 --with-multisrctop= --enable-multilib --cache-file=./config.cache --enable-
multilib --prefix=/proj/opensrc/sje/svn.reg/gcc-x86_64-suse-linux-gnu-trunk --wi
th-local-prefix=/proj/opensrc/sje/svn.reg/gcc-x86_64-suse-linux-gnu-trunk --disa
ble-nls --with-gmp=/proj/opensrc/be/x86_64-suse-linux-gnu --with-mpfr=/proj/open
src/be/x86_64-suse-linux-gnu --enable-languages=c,c++,fortran --program-transfor
m-name=s,y,y, --with-target-subdir=x86_64-suse-linux-gnu --build=x86_64-suse-lin
ux-gnu --host=x86_64-suse-linux-gnu --target=x86_64-suse-linux-gnu --srcdir=/pro
j/opensrc/sje/svn.reg/src/trunk/libstdc++-v3 CPPFLAGS= build_alias=x86_64-suse-l
inux-gnu host_alias=x86_64-suse-linux-gnu target_alias=x86_64-suse-linux-gnu -sr
cdir=/proj/opensrc/sje/svn.reg/src/trunk/libstdc++-v3

=========

And in the new libtool tree I see:

=========

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by package-unused configure version-unused, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ /proj/opensrc/nightly/src/trunk/libstdc++-v3/configure --with-multisubdir=32
 --with-multisrctop= --enable-multilib --cache-file=./config.cache --enable-mult
ilib --prefix=/proj/opensrc/nightly/gcc-x86_64-suse-linux-gnu-trunk --with-local
-prefix=/proj/opensrc/nightly/gcc-x86_64-suse-linux-gnu-trunk --disable-nls --wi
th-gmp=/proj/opensrc/be/x86_64-suse-linux-gnu --with-mpfr=/proj/opensrc/be/x86_6
4-suse-linux-gnu --enable-languages=c,c++,fortran --program-transform-name=s,y,y
, --with-target-subdir=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --hos
t=x86_64-suse-linux-gnu --target=x86_64-suse-linux-gnu --srcdir=/proj/opensrc/ni
ghtly/src/trunk/libstdc++-v3 CPPFLAGS= CXXFLAGS=-g -O2 -D_GNU_SOURCE CXX= /proj/
opensrc/nightly/build-x86_64-suse-linux-gnu-trunk/obj_gcc/./gcc/xgcc -shared-lib
gcc -B/proj/opensrc/nightly/build-x86_64-suse-linux-gnu-trunk/obj_gcc/./gcc -nos
tdinc++ -L/proj/opensrc/nightly/build-x86_64-suse-linux-gnu-trunk/obj_gcc/x86_64
-suse-linux-gnu/libstdc++-v3/src -L/proj/opensrc/nightly/build-x86_64-suse-linux
-gnu-trunk/obj_gcc/x86_64-suse-linux-gnu/libstdc++-v3/src/.libs -B/proj/opensrc/
nightly/gcc-x86_64-suse-linux-gnu-trunk/x86_64-suse-linux-gnu/bin/ -B/proj/opens
rc/nightly/gcc-x86_64-suse-linux-gnu-trunk/x86_64-suse-linux-gnu/lib/ -isystem /
proj/opensrc/nightly/gcc-x86_64-suse-linux-gnu-trunk/x86_64-suse-linux-gnu/inclu
de -isystem /proj/opensrc/nightly/gcc-x86_64-suse-linux-gnu-trunk/x86_64-suse-li
nux-gnu/sys-include LDFLAGS= build_alias=x86_64-suse-linux-gnu host_alias=x86_64
-suse-linux-gnu target_alias=x86_64-suse-linux-gnu -srcdir=/proj/opensrc/nightly
/src/trunk/libstdc++-v3

========

So in the old version, when the top-level Makefile calls the libstdc++-v3
configure it doesn't pass values for CXX or CXXFLAGS.  But in the new call
it does.  I think this is where we are going wrong.

I don't see any differences between the top-level Makefile in the old
and new versions so I don't understand why they are different.

The 64 bit (standard) x86_64 libstdc++-v3 config.log doesn't show
CPPFLAGS, CXX, or CXXFLAGS being passed as args when the configure is
done.  Only in the 32 bit version do I see this.  But that is the same
for old and new versions.

The hunt continues.

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Alexandre Oliva]

On Apr  2, 2007, Steve Ellcey <sje@cup.hp.com> wrote:

> So in the old version, when the top-level Makefile calls the libstdc++-v3
> configure it doesn't pass values for CXX or CXXFLAGS.  But in the new call
> it does.  I think this is where we are going wrong.

Actually, it passes it down in both cases, but I suppose libtool.m4
marks CXX and CXXFLAGS as "precious" environment variables (maybe it's
AC_PROG_CXX that does this, or libtool's wrapper thereof), such that
they get copied to the invocation command line.  This is probably what
breaks us if we don't override it properly for multi-libs.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Patch to update libtool in GCC and binutils trees

[Ralf Wildenhues]

* Charles Wilson wrote on Fri, Mar 30, 2007 at 05:55:23AM CEST:
> This:
> 
> >	if ${CONFIG_SHELL-/bin/sh} ./libtool --tag CXX --features |
[...]
> isn't the correct mechanism, anymore.  From the new libtool's .info:
> 
> ===========================================
>    With 1.3 era libtool, if you wanted to know any details of what
> libtool had discovered about your architecture and environment, you had
> to run the script with `--config' and grep through the results.  This
> idiom was supported up to and including 1.5.x era libtool, where it was
> possible to call the generated libtool script from `configure.ac' as
> soon as `LT_INIT' had completed.  However, one of the features of
> libtool 1.4 was that the libtool configuration was migrated out of a
> separate `ltconfig' file, and added to the `LT_INIT' macro (nee
> `AC_PROG_LIBTOOL'), so the results of the configuration tests were
> available directly to code in `configure.ac', rendering the call out to
> the generated libtool script obsolete.
> 
>    Starting with libtool 2.0, the multipass generation of the libtool
> script has been consolidated into a single `config.status' pass, which
> happens after all the code in `configure.ac' has completed.  The
> implication of this is that the libtool script does not exist during
> execution of code from `configure.ac', and so obviously it cannot be
> called for `--config' details anymore.  If you are upgrading projects
> that used this idiom to libtool 2.0 or newer, you should replace those
> calls with direct references to the equivalent Autoconf shell variables
> that are set by the configure time tests before being passed to
> `config.status' for inclusion in the generated libtool script.

This is only half of the truth; you can still use the generated libtool
script, but then you have to ensure that it is generated earlier.
Quoting the paragraph following the one you quoted:

|  -- Macro: LT_OUTPUT
|      By default, the configured `libtool' script is generated by the
|      call to `AC_OUTPUT' command, and there is rarely any need to use
|      `libtool' from `configure'.  However, sometimes it is necessary to
|      run configure time compile and link tests using `libtool'.  You
|      can add `LT_OUTPUT' to your `configure.ac' any time after
|      `LT_INIT' and any `LT_LANG' calls; that done, `libtool' will be
|      created by a specially generated `config.lt' file, and available
|      for use in later tests.
| 
|      Also, when `LT_OUTPUT' is used, for backwards compatibility with
|      Automake regeneration rules, `config.status' will call `config.lt'
|      to regenerate `libtool', rather than generating the file itself.


Of course, your suggestion:

> So, short version: the code above should be replaced with [untested]:
> 
> 	LIBSUPCXX_PICFLAGS=
> 	test "$enable_shared" = yes && LIBSUPCXX_PICFLAGS=-prefer-pic

is still good, and IMVHO the right thing to do here.

Hope that helps.

Cheers,
Ralf

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

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

Alexandre Oliva wrote:

 > On Apr  2, 2007, Steve Ellcey <sje@cup.hp.com> wrote:
 >
 > > So in the old version, when the top-level Makefile calls the 
libstdc++-v3
 > > configure it doesn't pass values for CXX or CXXFLAGS.  But in the 
new call
 > > it does.  I think this is where we are going wrong.
 >
 > Actually, it passes it down in both cases, but I suppose libtool.m4
 > marks CXX and CXXFLAGS as "precious" environment variables (maybe it's
 > AC_PROG_CXX that does this, or libtool's wrapper thereof), such that
 > they get copied to the invocation command line.  This is probably what
 > breaks us if we don't override it properly for multi-libs.

So how do I override it?  I think I have exhausted the limits of my
configure/libtool/auto* knowledge here and don't know what to try next.

You can see the failures by running on an x86_64 Linux box or presumably
any multilib GCC.  When I run on x86_64, the build works fine but the tests
fail.  The 32 bit libstdc++-v3 testsuite fails badly enough that the 
tests don't
show up as failures because the initialization fails in 32 bit mode and 
the tests
don't get run at all in that mode.  I was testing with

make check RUNTESTFLAGS="--target_board 'unix{-m64,-m32}'"

Attached is the current state of my libtool patch, it contains a patch for
the GCC tree, a patch for the Src tree, and a tar file with the ToT
libtool that I used (and which should be installed at the top level of the
GCC and Src trees).

The only difference between this and my earlier patches is in
libstdc++-v3/configure.ac.  I did not include ChangeLog files.

Steve Ellcey
sje@cup.hp.com

[-- Attachment #2: gcc.diffs.gz --]
[-- Type: application/gzip, Size: 751 bytes --]

[-- Attachment #3: src.diffs.gz --]
[-- Type: application/gzip, Size: 1397 bytes --]

[-- Attachment #4: libtool.tar.gz --]
[-- Type: application/gzip, Size: 117116 bytes --]

Re: Patch to update libtool in GCC and binutils trees

[Alexandre Oliva]

On Apr  5, 2007, Steve Ellcey <sje@cup.hp.com> wrote:

> Alexandre Oliva wrote:
>> Actually, it passes it down in both cases, but I suppose libtool.m4
>> marks CXX and CXXFLAGS as "precious" environment variables (maybe it's
>> AC_PROG_CXX that does this, or libtool's wrapper thereof), such that
>> they get copied to the invocation command line.  This is probably what
>> breaks us if we don't override it properly for multi-libs.

> So how do I override it?

It seems to me that adding ${ml_config_env} to the end of the
${ml_recprog} command line in config-ml.in shoudl do it.  I.e.:

     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


I'm not sure I have already thanked you enough (or at all) for
undertaking this work.  Thank you thank you thank you :-)

Cheers,

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

Alexandre Oliva wrote:

> It seems to me that adding ${ml_config_env} to the end of the
> ${ml_recprog} command line in config-ml.in shoudl do it.  I.e.:
> 
>      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

Well dang, it worked.  It's a bit ugly, but it works.  The reason I say
it is ugly is because now we pass the wrong CXX variable first and then
we pass the right CXX variable after it, both on the configure command
line.  I only tested this on x86_64 so far, I'll put it in my nightly
sources to test on HPPA and IA64 over the weekend.

> I'm not sure I have already thanked you enough (or at all) for
> undertaking this work.  Thank you thank you thank you :-)

You just want to make sure I don't give up and drop this in your lap,
don't you?  :-)

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Benjamin Kosnik]

>> It seems to me that adding ${ml_config_env} to the end of the
>> ${ml_recprog} command line in config-ml.in shoudl do it.  I.e.:
>>
>>      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
> 
> Well dang, it worked.  It's a bit ugly, but it works.  The reason I say
> it is ugly is because now we pass the wrong CXX variable first and then
> we pass the right CXX variable after it, both on the configure command
> line.  I only tested this on x86_64 so far, I'll put it in my nightly
> sources to test on HPPA and IA64 over the weekend.

Since this could be a long and ill-defined weekend, I will pre-emptively 
give you an OK for the tiny libstdc++ change in your last gcc-diffs patch.

>> I'm not sure I have already thanked you enough (or at all) for
>> undertaking this work.  Thank you thank you thank you :-)
> 
> You just want to make sure I don't give up and drop this in your lap,
> don't you?  :-)

Frankly, yes.

;)

Thanks from me too though.

-benjamin

Re: Patch to update libtool in GCC and binutils trees

[François-Xavier Coudert]

> Any chance you could try it?  I am curious if my problem is HP-UX specific
> or multilib specific.  Basically I would be looking for you to run:
>
> make check RUNTESTFLAGS="--target_board 'unix{-mlp64,-milp32}'"

I've started a bootstrap and will regtest with multilibed
x86_64-linux. Would that be useful?

Also, when applying your patch and running autoconf in libjava (after
I did the aclocal && automake, as indicated in your previous mail) I
still get the following error:

configure.ac:436: error: possibly undefined macro: AC_LIBLTDL_CONVENIENCE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

So, that's occuring to me on both i686-pc-mingw32 and x86_64-linux,
it's weird that it's not occuring to anyone else. If it's relevant, I
only have a GCC tree, no src or other things.

FX

Re: Patch to update libtool in GCC and binutils trees

[François-Xavier Coudert]

> I've started a bootstrap and will regtest with multilibed
> x86_64-linux. Would that be useful?

libstdc++-v3 isn't building fine:

make[4]: Entering directory
`/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX --mode=link
/utmp/coudert/gfortran/ibin/./gcc/xgcc -shared-libgcc
-B/utmp/coudert/gfortran/ibin/./gcc -nostdinc++
-L/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/bin/
-B/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/lib/ -isystem
/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/include -isystem
/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/sys-include
-Wl,-O1 -Wl,-z,relro  -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections   -o libstdc++.la -rpath
/utmp/coudert/gfortran/irun/lib/../lib64 -version-info 6:9:0
-Wl,--version-script=libstdc++-symbols.ver -lm  bitmap_allocator.lo
pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo
complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo
globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo
limits.lo list.lo locale.lo locale_init.lo locale_facets.lo
localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo
concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo
iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo
misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo
streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo
wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo
ctype_members.lo messages_members.lo monetary_members.lo
numeric_members.lo time_members.lo basic_file.lo c++locale.lo
../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm
libtool: link:  /utmp/coudert/gfortran/ibin/./gcc/xgcc -shared-libgcc
-B/utmp/coudert/gfortran/ibin/./gcc -nostdinc++
-L/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/bin/
-B/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/lib/ -isystem
/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/include -isystem
/utmp/coudert/gfortran/irun/x86_64-unknown-linux-gnu/sys-include
-shared -nostdlib /usr/lib/../lib64/crti.o
/utmp/coudert/gfortran/ibin/./gcc/crtbeginS.o
.libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
.libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o
.libs/debug.o .libs/debug_list.o .libs/functexcept.o
.libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o
.libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o
.libs/locale_init.o .libs/locale_facets.o .libs/localename.o
.libs/stdexcept.o .libs/strstream.o .libs/tree.o
.libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o
.libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
.libs/istream-inst.o .libs/istream.o .libs/locale-inst.o
.libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o
.libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o
.libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o
.libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o
.libs/ctype_members.o .libs/messages_members.o
.libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o
.libs/basic_file.o .libs/c++locale.o  -Wl,--whole-archive
../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a
-Wl,--no-whole-archive
-L/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-lm -L/utmp/coudert/gfortran/ibin/./gcc -L/lib/../lib64
-L/usr/lib/../lib64 -lc -lgcc_s
/utmp/coudert/gfortran/ibin/./gcc/crtendS.o /usr/lib/../lib64/crtn.o
-Wl,-O1 -Wl,-z -Wl,relro -Wl,--version-script=libstdc++-symbols.ver
 -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.9
/homes/coudert/local/64/bin/ld:
../libsupc++/.libs/libsupc++convenience.a(array_type_info.o):
relocation R_X86_64_32S against `vtable for
__cxxabiv1::__array_type_info' can not be used when making a shared
object; recompile with -fPIC
../libsupc++/.libs/libsupc++convenience.a(array_type_info.o): could
not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libstdc++.la] Error 1
make[4]: Leaving directory
`/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/utmp/coudert/gfortran/ibin/x86_64-unknown-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/utmp/coudert/gfortran/ibin'
make: *** [all] Error 2

Re: Patch to update libtool in GCC and binutils trees

[Ralf Wildenhues]

* François-Xavier Coudert wrote on Fri, Mar 30, 2007 at 11:34:16AM CEST:
> 
> Also, when applying your patch and running autoconf in libjava (after
> I did the aclocal && automake, as indicated in your previous mail) I
> still get the following error:
> 
> configure.ac:436: error: possibly undefined macro: AC_LIBLTDL_CONVENIENCE
>      If this token and others are legitimate, please use m4_pattern_allow.
>      See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1
> 
> So, that's occuring to me on both i686-pc-mingw32 and x86_64-linux,
> it's weird that it's not occuring to anyone else. If it's relevant, I
> only have a GCC tree, no src or other things.

Which version of m4?  If older than 1.4.5, then please try updating it
to 1.4.9 first.  If that doesn't help, then please remove the
autom4te.cache directory, run `autoconf --verbose' and post the output.

Cheers, and please Cc: me on replies,
Ralf

Re: Patch to update libtool in GCC and binutils trees

[Paolo Bonzini]

Ralf Wildenhues wrote:
> * François-Xavier Coudert wrote on Fri, Mar 30, 2007 at 11:34:16AM CEST:
>> Also, when applying your patch and running autoconf in libjava (after
>> I did the aclocal && automake, as indicated in your previous mail) I
>> still get the following error:
>>
>> configure.ac:436: error: possibly undefined macro: AC_LIBLTDL_CONVENIENCE
>>      If this token and others are legitimate, please use m4_pattern_allow.
>>      See the Autoconf documentation.
>> autoreconf: /usr/bin/autoconf failed with exit status: 1
>>
>> So, that's occuring to me on both i686-pc-mingw32 and x86_64-linux,
>> it's weird that it's not occuring to anyone else. If it's relevant, I
>> only have a GCC tree, no src or other things.

This is because the new libtool does not include LIBLTDL macros in your 
libtool.m4.  You can either take them from HEAD libtool too, or move them
from the old libtool.m4 into a new libltdl.m4 file.

Paolo

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

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

This is a follow up patch with the libtool changes for the top-level of 
the GCC and binutils tree.  My first attempt to send this bounced 
because the patch was too big.  Here is is as a compressed attachment. 
The patch does not delete ltconfig, ltcf-c.sh, ltcf-cxx.sh, and 
ltcf-gcj.sh.  That needs to be done by hand.

Steve Ellcey
sje@cup.hp.com



[-- Attachment #2: Top --]
[-- Type: text/plain, Size: 352 bytes --]

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.

[-- Attachment #3: libtool.diff.gz --]
[-- Type: application/x-gzip, Size: 162357 bytes --]

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

I tested the new libtool on HP-UX and Linux over the weekend.  The
builds all worked fine but I got many C++ failures during testing on
IA64 HP-UX, PA HP-UX (32 bits), and x86_64 Linux.  All the failures
seemed to involve trouble finding the libstdc++ library when linking
test programs.  On IA64 HP-UX, testing worked in default 32 bit mode but
failed in 64 bit mode because we have a -L that finds the 32 bit
libstdc++ library before one that finds the 64 bit version.  On PA and
x86_64, we just don't seem to find libstdc++ at all.

I'll see if I can figure out what is going on.

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Paolo Bonzini]

Steve Ellcey wrote:
> I tested the new libtool on HP-UX and Linux over the weekend.  The
> builds all worked fine but I got many C++ failures during testing on
> IA64 HP-UX, PA HP-UX (32 bits), and x86_64 Linux.  All the failures
> seemed to involve trouble finding the libstdc++ library when linking
> test programs.  On IA64 HP-UX, testing worked in default 32 bit mode but
> failed in 64 bit mode because we have a -L that finds the 32 bit
> libstdc++ library before one that finds the 64 bit version.  On PA and
> x86_64, we just don't seem to find libstdc++ at all.
> 
> I'll see if I can figure out what is going on.

Thanks.  By the way, next time it's best if you don't post the
new libtool files as a patch, but just attach them or a .tar.gz
of them.  Just post the configure.ac/Makefile.am changes as diffs.

Sorry for not asking for this the previous time.

Paolo

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

Here is an update on my attempts to use the new libtool in the GCC and
Src trees.  It seems to be mostly working but I am having problems with
the libstdc++-v3 directory in the GCC tree.

On IA64 HP-UX (a multidir platform), I can build everything fine but
when I run the libstdc++-v3 testsuite in 32 and 64 modes the 32 bit
tests pass and the 64 bit tests fail.  It looks like the -L arguments
are set wrong in the 64 bit mode so g++ finds a 32 bit (default)
libstdc++ library instead of the 64 bit one and fails to link.

On x86_64 Linux (x86_64-suse-linux-gnu) the build for libstdc++ fails, I
wind up with:

	/proj/opensrc/nightly/gcc-x86_64-suse-linux-gnu-trunk/x86_64-suse-linux-gnu/bin/ld: ../libsupc++/.libs/libsupc++convenience.a(array_type_info.o): relocation R_X86_64_32S against `vtable for __cxxabiv1::__array_type_info' can not be used when making a shared object; recompile with -fPIC
	../libsupc++/.libs/libsupc++convenience.a(array_type_info.o): could not read symbols: Bad value
	collect2: ld returned 1 exit status
	make[4]: *** [libstdc++.la] Error 1

So something is not getting compiled with -fPIC but I don't know why.

Can someone familiar with the libstdc++ make setup offer any suggestions?

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Andreas Schwab]

Steve Ellcey <sje@cup.hp.com> writes:

> On x86_64 Linux (x86_64-suse-linux-gnu) the build for libstdc++ fails, I
> wind up with:
>
> 	/proj/opensrc/nightly/gcc-x86_64-suse-linux-gnu-trunk/x86_64-suse-linux-gnu/bin/ld: ../libsupc++/.libs/libsupc++convenience.a(array_type_info.o): relocation R_X86_64_32S against `vtable for __cxxabiv1::__array_type_info' can not be used when making a shared object; recompile with -fPIC
> 	../libsupc++/.libs/libsupc++convenience.a(array_type_info.o): could not read symbols: Bad value
> 	collect2: ld returned 1 exit status
> 	make[4]: *** [libstdc++.la] Error 1
>
> So something is not getting compiled with -fPIC but I don't know why.

I sometimes see that configure thinks -fPIC is not usable.  I'd suggest to
look at config.log to check that the test does not find a spurious
failure.

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: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

> > So something is not getting compiled with -fPIC but I don't know why.
> 
> I sometimes see that configure thinks -fPIC is not usable.  I'd suggest to
> look at config.log to check that the test does not find a spurious
> failure.
> 
> Andreas.

Interesting, config.log does show that -fPIC is supported but then
later in the log file I see:

LIBSUPCXX_PICFLAGS=''

I think this is related to libstdc++-v3/configure.ac:

	if ${CONFIG_SHELL-/bin/sh} ./libtool --tag CXX --features |
	   grep "enable shared" > /dev/null;
	then
	  LIBSUPCXX_PICFLAGS=-prefer-pic
	else
	  LIBSUPCXX_PICFLAGS=
	fi
	AC_SUBST(LIBSUPCXX_PICFLAGS)

The new libtool seems to still be putting out "enable shared" so I am
not sure why this would be different now.

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

Following up to my own mail about problems using the new libtool in the
libstdc++-v3 directory, it looks like when the libstdc++-v3 configure
script runs:

	if ${CONFIG_SHELL-/bin/sh} ./libtool --tag CXX --features |
	   grep "enable shared" > /dev/null;
	then
	  LIBSUPCXX_PICFLAGS=-prefer-pic
	else
	  LIBSUPCXX_PICFLAGS=
	fi

the libtool executable has not yet been put in the libstdc++ object
directory.  It does get put there later but at the time these commands
run, it has not yet been done.  I am note sure who or how libtool winds
up in the build directory but it is obviously getting done later then
before and this is causing LIBSUPCXX_PICFLAGS to get set to NULL rather
than -prefer-pic.

I tried to replace "${CONFIG_SHELL-/bin/sh} ./libtool" with $LIBTOOL
which looks like it is getting set earlier in the configure script and
which should use the libtool from the top-level but that didn't work
either (LIBTOOL did not seem to be set).  Does anyone have a better way
to handle this test in the libstdc++-v3 configure file?  I don't see any
other libraries running libtool as part of the configure.  Can I just
check the enable_shared variable instead?

Steve Ellcey
sje@cup.hp.com

Re: Patch to update libtool in GCC and binutils trees

[Alexandre Oliva]

On Mar 29, 2007, Steve Ellcey <sje@cup.hp.com> wrote:

> Does anyone have a better way
> to handle this test in the libstdc++-v3 configure file?

There should be a shell variable holding the right value, with
ltconfig fully integrated into the main configure script.

> Can I just check the enable_shared variable instead?

Most likely.  I don't have your patch handy any more, but if you could
check that enable_shared is what makes to the libtool script, that
later outputs "enable shared", then yes.  There might be per-language
settings.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Patch to update libtool in GCC and binutils trees

[Ben Elliston]

Hi Steve

On Fri, 2007-03-23 at 09:21 -0700, Steve Ellcey wrote:

> 2007-03-22  Steve Ellcey  <sje@cup.hp.com>
> 	* ltmain.sh: Update from ToT Libtool.

"ToT" is not a term I've seen before -- I am guessing that it is an
acronym for "Top of Tree"?  If so, I wonder if you could refer to
"mainline" or "head revision" or something instead, which is terminology
that we're more familiar with?  Alternatively, just spelling out ToT
would help .. :-)

Thanks,
Ben

Re: Patch to update libtool in GCC and binutils trees

[Paolo Bonzini]

Steve Ellcey wrote:

> Here is a patch to update the libtool in the GCC and src trees to the
> ToT libtool.

Please add a comment in libgfortran/Makefile.am.

Also, please resend with the libtool code to help people test the
precise version you'll commit. (*)  In particular, David, I'd
appreciate if you could test AIX before the commit.

I guess you can do HP-UX yourself, I'll do i686-linux as soon as
you post the updated patch.  I'll also try a combined tree with
newlib on arm-elf next week.  Please wait for these tests to
be finished before committing, as the patch seems pretty easy
to maintain.

Thanks very much for this work!

Paolo

(*) sending this first round without libtool was a good idea though

Re: Patch to update libtool in GCC and binutils trees

[François-Xavier Coudert]

> FX, I am not going to send out the generated files because that whould
> just be too big of a patch.

What are the tool versions required to regenerate everything? Are
there special command lines to be issued, or just ./configure
--enable-maintainer-mode?

FX

Re: Patch to update libtool in GCC and binutils trees

[FX Coudert]

> Testing with more platforms would be greatly appreciated.

I'm willing to test on native i386-pc-mingw32 using MSYS, but I would  
be great if you could post a complete patch with libtool and  
regenerated files.

Thanks,
FX

Patch to update libtool in GCC and binutils trees

[Steve Ellcey]

Here is a patch to update the libtool in the GCC and src trees to the
ToT libtool.  I did not include the actual new libtool in this patch but
if you pick up the latest snapshot (anything after March 19th) it should
work.  I can send the libtool I used as a patch if people want me to.  I
left it out of this patch in order to make it simpler to see what I did.

I have tested this on one platform only so far so I think it needs more
testing before we do anything further.

Here is what I did:

In GCC and Src trees I updated libtool by removing ltconfig, ltcf-c.sh,
ltcf-cxx.sh, and ltcf-gcj.sh; updating ltmain.sh and libtool.m4; and
adding ltsugar.m4, ltversion.m4, and ltoptions.m4.

In the Src tree; in bfd, binutils, gas, gprof, and rda I added some
includes and some macro calls and reordered a few things.  In these
directories plus in ld, opcodes, and newlib I regenerated everthing by
running "aclocal;automake -cygnus;autoconf".  Except in rda where
-cygnus was not used.

In the GCC tree I updated Makfile.am in libgfortran, libgomp, and zlib
to include "-I .."  in the ACLOCAL_AMFLAGS argument and I made one other
change in the libgfortran Makefile.am to link libgfortran with gcc
instead of with gfortran.  After that I regenerated everthing.  In
boehm-gc, libffi, libgfortran, libgomp, libmudflap, libssp, and zlib: I
ran "aclocal -I ..  -I ../config;automake;autoconf".  In libjava and
libstdc++-v4 I added "-I ."  to the aclocal options and in libobjc I
skipped the automake step because it doesn't use automake.

Here are ChangeLog files and diffs for both GCC and the Src tree.

Testing with more platforms would be greatly appreciated.

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.

<Actual ToT Libtool code not included in this patch.>

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.

Index: Makefile.am
===================================================================
--- Makefile.am	(revision 123081)
+++ 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



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.

Index: Makefile.am
===================================================================
--- Makefile.am	(revision 123081)
+++ 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.


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.

Index: Makefile.am
===================================================================
--- Makefile.am	(revision 123081)
+++ 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 \



libstdc++-v3/ChangeLog:

2007-03-22  Steve Ellcey  <sje@cup.hp.com>
	* 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.


++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++


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.

Index: src-release
===================================================================
RCS file: /cvs/src/src/src-release,v
retrieving revision 1.22
diff -u -r1.22 src-release
--- src-release	9 Feb 2007 15:15:38 -0000	1.22
+++ src-release	9 Mar 2007 23:37:34 -0000
@@ -49,8 +49,8 @@
 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.



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.

Index: acinclude.m4
===================================================================
RCS file: /cvs/src/src/bfd/acinclude.m4,v
retrieving revision 1.16
diff -u -r1.16 acinclude.m4
--- acinclude.m4	31 May 2006 15:14:35 -0000	1.16
+++ acinclude.m4	9 Mar 2007 23:36:49 -0000
@@ -49,6 +49,9 @@
 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: configure.in
===================================================================
RCS file: /cvs/src/src/bfd/configure.in,v
retrieving revision 1.222
diff -u -r1.222 configure.in
--- configure.in	1 Mar 2007 15:48:36 -0000	1.222
+++ configure.in	9 Mar 2007 23:37:07 -0000
@@ -19,7 +19,10 @@
 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)],
@@ -95,9 +98,6 @@
 
 # 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



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.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/binutils/configure.in,v
retrieving revision 1.75
diff -u -r1.75 configure.in
--- configure.in	28 Feb 2007 01:29:32 -0000	1.75
+++ configure.in	9 Mar 2007 23:36:12 -0000
@@ -11,7 +11,9 @@
 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],
@@ -53,9 +55,6 @@
     AC_MSG_ERROR(Unrecognized host system type; please check config.sub.)
 fi
 
-AC_PROG_CC
-AC_GNU_SOURCE
-
 AC_PROG_YACC
 AM_PROG_LEX
 


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

Index: acinclude.m4
===================================================================
RCS file: /cvs/src/src/gas/acinclude.m4,v
retrieving revision 1.6
diff -u -r1.6 acinclude.m4
--- acinclude.m4	2 Aug 2006 14:26:07 -0000	1.6
+++ acinclude.m4	9 Mar 2007 23:35:46 -0000
@@ -71,6 +71,9 @@
 $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



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

Index: acinclude.m4
===================================================================
RCS file: /cvs/src/src/gprof/acinclude.m4,v
retrieving revision 1.3
diff -u -r1.3 acinclude.m4
--- acinclude.m4	31 May 2006 15:14:37 -0000	1.3
+++ acinclude.m4	9 Mar 2007 23:35:04 -0000
@@ -4,6 +4,9 @@
 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



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

Index: acinclude.m4
===================================================================
RCS file: /cvs/src/src/rda/acinclude.m4,v
retrieving revision 1.2
diff -u -r1.2 acinclude.m4
--- acinclude.m4	31 May 2006 15:14:39 -0000	1.2
+++ acinclude.m4	9 Mar 2007 23:34:41 -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



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.