libtool in binutils question

libtool in binutils question

[Steve Ellcey]

OK, I am going to try and raise the libtool issue again.  So far all
I've gotten is complete silence from the GCC list so I will try the
binutils list.  Are there any plans to update the version of libtool in
binutils?  It has been 7 months since we took anything from libtool and
they have done some restructuring since then (fewer files are needed).
I have built both binutils and GCC on HP-UX with the latest libtool and
had no problems.  I described the process I followed in
http://sources.redhat.com/ml/binutils/2001-11/msg00762.html, and while
it did involve using an automake and autoconf newer then binutils (and
GCC) currently require, I had no problems with the build itself.

Please check one of the following:

	[ ] What a brilliant idea, why didn't we think of that.
	[ ] What a stupid suggestion, go away and stop bugging us.
	[ ] Other (please explain).

Steve Ellcey
sje@cup.hp.com

Re: libtool in binutils question

[Alexandre Oliva]

On Jan 11, 2002, Steve Ellcey <sje@cup.hp.com> wrote:

> OK, I am going to try and raise the libtool issue again.

Sorry that I've been so unresponsive.  I keep promising to myself I'm
going to look into it, but I never have the time to do it :-(

> Are there any plans to update the version of libtool in binutils?

Yes, but see above.

> I described the process I followed in
> http://sources.redhat.com/ml/binutils/2001-11/msg00762.html, and while
> it did involve using an automake and autoconf newer then binutils (and
> GCC) currently require, I had no problems with the build itself.

I'm not sure we're ready to switch over to autoconf 2.5x, but I don't
see a problem in using automake 1.5.  The autoconf 2.5x issues are the
most relevant ones that have been causing me to postpone this task.
I'd rather make the upgrade independently, so that we spread the
breakage along a longer period (instead of breaking everything at once
and then not knowing where to start trying to fix it :-) but if a
newer libtool requires autoconf 2.5x (*) , we should start by officially
adopting autoconf 2.5x, and only then upgrading libtool.  If you can
show that both the src and the gcc repositories keep working after all
their autoconf-generated configure scripts are rebuilt, I'm game, but
I've heard reports that said we were not ready for that yet.

And then, there's the other issue: do we really want to require all
developers of GCC and tools hosted in the src repo to be forced to
switch to autoconf 2.5x?  I'd rather not make that a requirement, but
if a newer libtool forces that decision, we may have to eventually
take that route.


* one would probably expect me to know that, being officially one of
the maintainers of libtool, but I've been away from it for so long
that I don't know what's going on over there :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: libtool in binutils question

[Maciej W. Rozycki]

On 11 Jan 2002, Alexandre Oliva wrote:

> I'm not sure we're ready to switch over to autoconf 2.5x, but I don't
> see a problem in using automake 1.5.  The autoconf 2.5x issues are the
> most relevant ones that have been causing me to postpone this task.
> I'd rather make the upgrade independently, so that we spread the
> breakage along a longer period (instead of breaking everything at once
> and then not knowing where to start trying to fix it :-) but if a
> newer libtool requires autoconf 2.5x (*) , we should start by officially
> adopting autoconf 2.5x, and only then upgrading libtool.  If you can
> show that both the src and the gcc repositories keep working after all
> their autoconf-generated configure scripts are rebuilt, I'm game, but
> I've heard reports that said we were not ready for that yet.

 As of 1.4.2 libtool doesn't require anything over autoconf 2.13, AFAIK. 
Actually the AC_PROG_LIBTOOL macro has not been updated to autoconf 2.5x
yet and running `autoconf -W all' on it produces a number of problem
reports.  It seems to run fine nevertheless. 

 One of the issues I know of with updating to autoconf 2.5x is as follows. 
The Cygnus top-level configure script passes target_alias (via
"--target=") down to sub-configures as this is needed for setting tooldir
properly.  Unfortunately, autoconf 2.5x considers cross-tools are to be
build unconditionally whenever target_alias is set and it sets
program_prefix then.  As a result all programs get installed under
"${target_alias}-<program>" names.  Apparently this is a desired property
of autoconf now. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: libtool in binutils question

[Ian Lance Taylor]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:

>  One of the issues I know of with updating to autoconf 2.5x is as follows. 
> The Cygnus top-level configure script passes target_alias (via
> "--target=") down to sub-configures as this is needed for setting tooldir
> properly.  Unfortunately, autoconf 2.5x considers cross-tools are to be
> build unconditionally whenever target_alias is set and it sets
> program_prefix then.  As a result all programs get installed under
> "${target_alias}-<program>" names.  Apparently this is a desired property
> of autoconf now. 

It's been true for a while that if host_alias != target_alias, the
default for program_prefix is "${target_alias}-".  That is true of
autoconf 2.13, for example.  Are you saying that autoconf 2.5x sets
program_prefix whenever target_alias is set, even if it is the same as
host_alias?  I think that would be a bad change, as it makes it much
harder to configure an entire tree correctly.

Ian

Re: libtool in binutils question

[Maciej W. Rozycki]

On 11 Jan 2002, Ian Lance Taylor wrote:

> It's been true for a while that if host_alias != target_alias, the
> default for program_prefix is "${target_alias}-".  That is true of
> autoconf 2.13, for example.  Are you saying that autoconf 2.5x sets
> program_prefix whenever target_alias is set, even if it is the same as
> host_alias?  I think that would be a bad change, as it makes it much
> harder to configure an entire tree correctly.

 That's exactly what happens and I agree it is a dubious feature, to say
at least.  I complained to the maintainer sending the following patch, but
he rejected it stating this is intended behaviour.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

2001-11-19  Maciej W. Rozycki  <macro@ds2.pg.gda.pl>

	* lib/autoconf/general.m4 (AC_CANONICAL_HOST):  Don't set
	program_prefix if target_alias equals host_alias.

autoconf-2.52-target_prefix.patch
diff -up --recursive --new-file autoconf-2.52.macro/acgeneral.m4 autoconf-2.52/acgeneral.m4
--- autoconf-2.52.macro/acgeneral.m4	Wed Jul  4 15:05:43 2001
+++ autoconf-2.52/acgeneral.m4	Sun Nov 18 15:27:47 2001
@@ -1774,7 +1774,7 @@ _AC_CANONICAL_SPLIT([target])
 
 # The aliases save the names the user supplied, while $host etc.
 # will get canonicalized.
-test -n "$target_alias" &&
+test -n "$target_alias" && test "x$target_alias" != "x$host_alias" &&
   test "$program_prefix$program_suffix$program_transform_name" = \
     NONENONEs,x,x, &&
   program_prefix=${target_alias}-[]dnl

Re: libtool in binutils question

[Zack Weinberg]

On Fri, Jan 11, 2002 at 07:54:13PM -0200, Alexandre Oliva wrote:
> 
> I'm not sure we're ready to switch over to autoconf 2.5x, but I don't
> see a problem in using automake 1.5.  The autoconf 2.5x issues are the
> most relevant ones that have been causing me to postpone this task.

I tried to make the gcc repository ready for autoconf 2.5x last May,
you might remember, and didn't succeed.  The major trouble was with
language runtime libraries.  The kluge to avoid having AC_PROG_CC barf
because we're in the middle of putting together the cross compiler it
tries to use, doesn't work anymore with 2.5x.  The suggested
replacement (AC_NO_EXECUTABLES) prohibits you from using link tests
anywhere in the same script.  Several of the language runtimes _need_
link tests.

see thread at http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01712.html,
or jump to the conclusions,
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01986.html.

The situation may have improved since, for example, if libtool.m4 now
wants autoconf 2.50, presumably it works with 2.5x.

I would like to see us require 2.5x autoconf if only because it will
let us clean up gcc/configure.in considerably.  But we aren't ready
yet.  (Debian's autoconf packages let 2.13 and 2.50 coexist, and
detect which version a script needs when you run autoconf.  If that
were an upstream feature of 2.50 I'd have started on gcc/configure.ac
long ago.)

zw

Re: libtool in binutils question

[Steve Ellcey]

> And then, there's the other issue: do we really want to require all
> developers of GCC and tools hosted in the src repo to be forced to
> switch to autoconf 2.5x?  I'd rather not make that a requirement, but
> if a newer libtool forces that decision, we may have to eventually
> take that route.

OK, I went back to see why I needed autoconf 2.5 and I found I needed it
to bootstrap the latest libtool sources (CVS top-of-tree).  I needed to
do that in order to create ltmain.sh which is created during the libtool
build process.  Once I had ltmain.sh I copied it and libtool.m4 into the
binutils (and gcc) trees and tried running automake/autoconf with
autoconf 2.13.  Unfortunately, it did not work because the new
libtool.m4 requires autoconf 2.50.

From the libtool ChangeLog:

2001-08-01  Ossama Othman  <ossama@doc.ece.uci.edu>

        * libtool.m4 (AC_LIBTOOL_SETUP): Require Autoconf-2.50 via the
        AC_PREREQ autoconf macro since the new libtool macros utilize
        macros from that version of Autoconf.

Steve Ellcey
sje@cup.hp.com