Discussion:
[RFA/PATCH] Darwin fixes for ltconfig, ltcf-c.sh
(too old to reply)
Klee Dienes
2002-11-13 16:55:09 UTC
Permalink
The enclosed patch fixes the Darwin support in the top-level libtool
support files of the binutils and GDB source repository. For the most
part it just adds more Darwin-specific config blocks to ltconfig and
ltcf-c.sh, and fixes a couple of nits in the existing Darwin support.

The only non-Darwin-specific patch is the change to default
CONFIG_SHELL to /bin/sh in ltconfig ... this prevents ltconfig from
silently setting max_cmd_len to "none" if CONFIG_SHELL is not passed to
ltconfig.


2002-11-12 Klee Dienes <***@apple.com>

* ltconfig: Default CONFIG_SHELL to /bin/sh if no value is
passed in
by the environment. Recognize "macos10" as specifying a
Darwin-based system. Remove extra '$' in library_names_spec
for the
Darwin configuration.
* ltcf-c.sh: Move the Darwin config-block from the
"$with_gnu_ld =
yes" section to the "$with_gnu_ld = no" section (Darwin doesn't
use
GNU ld as it's linker). Use ac_cv_prog_cc_pic to set pic
flags, not
lt_cv_prog_cc_pic. Add a Darwin block for pic flags when using
GCC
as well as when using the system compiler. Recognize "macos10"
as
specifying a Darwin-based system in all clauses.
Andrew Cagney
2002-11-13 17:57:25 UTC
Permalink
These files are part of libtool. From src/MAINTAINERS.

Andrew

ltconfig; ltmain.sh
libtool: http://gnu.org
Changes need to be done in tandem with the official LIBTOOL
sources or submitted to the master file maintainer and brought
in via a merge.
Klee Dienes
2002-11-13 18:32:33 UTC
Permalink
I believe libtool-1.4.3 already has correct Darwin support, although I
haven't done overly much testing with it.

I submitted a patch to the current GDB/binutils libtool because it was
unclear when the next libtool merge might be, because I didn't want to
get in the way of the folks doing the autoconfiscation work, and
because there was existing precedent (see the ChangeLog entries for
2002-01-27 and 2001-11-13, for example).

I'm certainly willing to try to push through an upgrade of the
GDB/binutils libtool to 1.4.3 if that's what's necessary, though; let
me know and I'll put together a patch.
Post by Andrew Cagney
These files are part of libtool. From src/MAINTAINERS.
Andrew
ltconfig; ltmain.sh
libtool: http://gnu.org
Changes need to be done in tandem with the official LIBTOOL
sources or submitted to the master file maintainer and brought
in via a merge.
Klee Dienes
2002-12-05 06:04:33 UTC
Permalink
The following patch updates the following directories to use the latest
versions of libtool, autoconf, and automake:

bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils

ltmain.sh (GNU libtool) 1.4.3
autoconf (GNU Autoconf) 2.56
automake (GNU automake) 1.7.1
gettext (GNU gettext) 0.11.5

To apply the patch, I put the following four files in a directory, and
ran 'files.sh' in the top-level directory of the GDB/Binutils tree,
then configured and built with 'build.sh' (the script was necessary in
order to pass --enable-maintainer-mode to only the subdirectories for
which it was appropriate). I then did a full build to verify that
maintainer-mode was working, and used the files generated by
--enable-maintainer-mode as the final versions. I'm not including the
ChangeLog entries for all of the auto-generated files, as they're not
overly interesting; I plan to generate them with a perl script based on
the result of the build. I'm also not including the diffs to the
generated files, since they were about 6Mb, and not all that
interesting. I'm happy to provide either if requested.
Hans-Peter Nilsson
2002-12-05 13:26:53 UTC
Permalink
Post by Klee Dienes
The following patch updates the following directories to use the latest
Bravo! Great! ... Could you please do this for GCC
gcc-3_4-basic-improvements-branch too?

Thanks!

brgds, H-P
Alan Modra
2002-12-05 22:03:03 UTC
Permalink
Post by Hans-Peter Nilsson
Post by Klee Dienes
The following patch updates the following directories to use the latest
Bravo! Great!
Agreed, but it needs a little more work. I ran Klee's script (minus
the rm and cvs update - I want to keep a few local mods!) last night
and my binutils builds went uneventfully. There were a few make
warnings about commands being overridden, but that's a minor problem.
The big problem, as others have noted, is that "make install" doesn't
install properly on a native build. ie. with --build=i686-linux
--host=i686-linux --target=i686-linux I get tools installed as
i686-linux-$tool rather than plain $tool. It seems that
program_prefix is now set by configure whenever --target is
specified, which I suppose is not a bad idea. I'm happy to have the
tools installed as i686-linux-$tool, but I want them installed as
$tool too!

One other nit: Your changelog mentions binutils/configure where
you're in fact patching the toplevel configure. You probably need to
explain why this particular patch was necessary too.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Andrew Cagney
2002-12-05 15:43:13 UTC
Permalink
Er, wow! Few technical hurdles to overcome first.

Anyone know what happens if only half the directories get converted?

There is a problem with libiberty and utils because GCC have their feet
stuck in the ice (unless src, again splits off from GCC, but I suspect
here we don't want to).
Post by Klee Dienes
bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils
bfd, binutils, gas, gprof, ld and opcodes are all BINUTILS.
mmalloc, sim and gdb are all GDB.
I'd drop rda from the list.

I don't understand this:

-
$(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y y.tab.c c-exp.tmp --
$(YFLAGS)
+
$(SHELL) $(YLWRAP) $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- "$(YACC)"
$(YFLAGS)

isn't it independant of the switch?

Same with this?

- AC_DEFINE(HAVE_LONG_DOUBLE)
+ AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type
works])

(or did the new autoconf change the interface causing a warning if the
three parameters were not present?).

Andrew
Klee Dienes
2002-12-05 16:22:07 UTC
Permalink
- $(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y y.tab.c c-exp.tmp --
$(YFLAGS)
+ $(SHELL) $(YLWRAP) $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- "$(YACC)"
$(YFLAGS)
isn't it independant of the switch?
It's a result of using the ylwrap from autoconf-1.7, which is needed
since the rules for the binutils/ parsers are automatically generated
by automake.
Same with this?
- AC_DEFINE(HAVE_LONG_DOUBLE)
+ AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type
works])
(or did the new autoconf change the interface causing a warning if the
three parameters were not present?).
Not even a warning: it blows out autoheader with an error. The new
AC_DEFINE interface deprecates the use of a template file, and instead
requires all the information to be provided by the AC_DEFINE commands
(it's particularly annoying since the warning about the existence of a
template file is about 10 lines long, ALL CAPS, and can't be turned off
with --warnings=none).

I actually made a point of not fixing any warnings during the
conversion that weren't symptoms of real errors. My reasoning is that
once the flag day part of the conversion is done, we can fix the
warnings in individual directories individually, but that for the
initial conversion it was best to keep it as simple as possible.
Andrew Cagney
2002-12-05 17:00:50 UTC
Permalink
- $(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- $(YFLAGS)
+ $(SHELL) $(YLWRAP) $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- "$(YACC)" $(YFLAGS)
isn't it independant of the switch?
It's a result of using the ylwrap from autoconf-1.7, which is needed since the rules for the binutils/ parsers are automatically generated by automake.
Does it work now?
Same with this?
- AC_DEFINE(HAVE_LONG_DOUBLE)
+ AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type works])
(or did the new autoconf change the interface causing a warning if the three parameters were not present?).
Not even a warning: it blows out autoheader with an error. The new AC_DEFINE interface deprecates the use of a template file, and instead requires all the information to be provided by the AC_DEFINE commands (it's particularly annoying since the warning about the existence of a template file is about 10 lines long, ALL CAPS, and can't be turned off with --warnings=none).
Ulgh. Same here though, does this work with autoconf 2.13++ (the
current offical autoconf)?

Andrew
Klee Dienes
2002-12-05 20:55:37 UTC
Permalink
Post by Andrew Cagney
Post by Klee Dienes
- $(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- $(YFLAGS)
+ $(SHELL) $(YLWRAP) $(srcdir)/c-exp.y y.tab.c c-exp.tmp --
"$(YACC)" $(YFLAGS)
isn't it independant of the switch?
It's a result of using the ylwrap from autoconf-1.7, which is needed
since the rules for the binutils/ parsers are automatically generated
by automake.
Does it work now?
I'm not sure I understand the question, but I'll elaborate on the
situation a bit in hopes that I can answer it anyway.

Automake-1.4p5 generates Makefile.in's that use the syntax:

ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...

Automake-1.7 generates Makefile.in's that use the syntax:

ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...

So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need
to use the ylwrap from automake-1.7 as well, which uses the new syntax
and therefore requires the change to the GDB Makefile.in. I don't
think it's possible to have a version of the GDB Makefile.in that works
with both versions.
Post by Andrew Cagney
Post by Klee Dienes
Same with this?
- AC_DEFINE(HAVE_LONG_DOUBLE)
+ AC_DEFINE([HAVE_LONG_DOUBLE], [], [Define if the `long double' type works])
(or did the new autoconf change the interface causing a warning if
the three parameters were not present?).
Not even a warning: it blows out autoheader with an error. The new
AC_DEFINE interface deprecates the use of a template file, and
instead requires all the information to be provided by the AC_DEFINE
commands (it's particularly annoying since the warning about the
existence of a template file is about 10 lines long, ALL CAPS, and
can't be turned off with --warnings=none).
Ulgh. Same here though, does this work with autoconf 2.13++ (the
current offical autoconf)?
The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.

Is autoconf-2.13 really the current official autoconf? The autoconf
Post by Andrew Cagney
- Why should I upgrade from 2.13?
This version is no longer maintained. It does not address recent
architectures, recent compilers etc. We know that upgrading from 2.13
to 2.5x is not an easy task, especially because the Autoconf 2.13 was
extremely tolerant of incorrect macro invocations, but waiting longer
endangers the portability of your package and only delays the
conversion to newer Autoconf versions. Worse: some maintainers now
spend a significant amount of time fixing bugs in 2.13 or backporting
macros from 2.55.
Or do you mean that autoconf-2.13++ is the current official version for
Binutils/BFD (in which case I withdraw my question)?
Daniel Jacobowitz
2002-12-05 21:03:25 UTC
Permalink
Post by Klee Dienes
Post by Andrew Cagney
Post by Klee Dienes
- $(SHELL) $(YLWRAP) "$(YACC)" $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- $(YFLAGS)
+ $(SHELL) $(YLWRAP) $(srcdir)/c-exp.y y.tab.c c-exp.tmp -- "$(YACC)" $(YFLAGS)
isn't it independant of the switch?
It's a result of using the ylwrap from autoconf-1.7, which is needed
since the rules for the binutils/ parsers are automatically generated
by automake.
Does it work now?
I'm not sure I understand the question, but I'll elaborate on the
situation a bit in hopes that I can answer it anyway.
ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need
to use the ylwrap from automake-1.7 as well, which uses the new syntax
and therefore requires the change to the GDB Makefile.in. I don't
think it's possible to have a version of the GDB Makefile.in that works
with both versions.
But, to clarify even further: if we use the new ylwrap from Automake
1.7, regardless of what version of _automake_ we are using, then Klee's
patch to gdb/Makefile.in will work.

This means that all directories which use both automake and ylwrap must
be converted at the same time however.
Post by Klee Dienes
The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.
Is autoconf-2.13 really the current official autoconf? The autoconf
Or do you mean that autoconf-2.13++ is the current official version for
Binutils/BFD (in which case I withdraw my question)?
Right, that's what Andrew meant, I think.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Andrew Cagney
2002-12-05 21:13:14 UTC
Permalink
Post by Daniel Jacobowitz
Post by Klee Dienes
I'm not sure I understand the question, but I'll elaborate on the
situation a bit in hopes that I can answer it anyway.
ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need
to use the ylwrap from automake-1.7 as well, which uses the new syntax
and therefore requires the change to the GDB Makefile.in. I don't
think it's possible to have a version of the GDB Makefile.in that works
with both versions.
But, to clarify even further: if we use the new ylwrap from Automake
1.7, regardless of what version of _automake_ we are using, then Klee's
patch to gdb/Makefile.in will work.
This means that all directories which use both automake and ylwrap must
be converted at the same time however.
[australian expletive deleted]

But GDB, which doesn't use automake, can start using the new one
(locally) now, and get the patches committed?

Andrew
Daniel Jacobowitz
2002-12-05 21:16:57 UTC
Permalink
Post by Andrew Cagney
Post by Daniel Jacobowitz
Post by Klee Dienes
I'm not sure I understand the question, but I'll elaborate on the
situation a bit in hopes that I can answer it anyway.
ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need
to use the ylwrap from automake-1.7 as well, which uses the new syntax
and therefore requires the change to the GDB Makefile.in. I don't
think it's possible to have a version of the GDB Makefile.in that works
with both versions.
But, to clarify even further: if we use the new ylwrap from Automake
1.7, regardless of what version of _automake_ we are using, then Klee's
patch to gdb/Makefile.in will work.
This means that all directories which use both automake and ylwrap must
be converted at the same time however.
[australian expletive deleted]
But GDB, which doesn't use automake, can start using the new one
(locally) now, and get the patches committed?
Probably not. It expects it to be in the toplevel directory. Might be
able to override YLWRAP for now.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Andrew Cagney
2002-12-05 21:08:30 UTC
Permalink
Post by Klee Dienes
The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.
So the three argument form fixes can be committed now?
Post by Klee Dienes
I'm not sure I understand the question, but I'll elaborate on the situation a bit in hopes that I can answer it anyway.
ylwrap PROGRAM INPUT [OUTPUT DESIRED]... -- [ARGS]...
ylwrap INPUT [OUTPUT DESIRED]... -- PROGRAM [ARGS]...
So if we use automake-1.7 to build Makefile.in binutils/ld/gas, we need to use the ylwrap from automake-1.7 as well, which uses the new syntax and therefore requires the change to the GDB Makefile.in. I don't think it's possible to have a version of the GDB Makefile.in that works with both versions.
Right. But can the fixes be committed now (while we potentially twiddle
our thums waiting for the end of the northern winter :-). I get the
feeling that the answer is no. Outch!

Andrew
Klee Dienes
2002-12-05 21:18:35 UTC
Permalink
Post by Andrew Cagney
Post by Klee Dienes
The 3-argument form works with both autoconf-2.13 and autoconf-2.50+.
So the three argument form fixes can be committed now?
Yes, that should be fine, though I'd have to do a test-configure/build
of it to be 100% sure.
Post by Andrew Cagney
Right. But can the fixes be committed now (while we potentially
twiddle our thums waiting for the end of the northern winter :-). I
get the feeling that the answer is no. Outch!
We could use YLWRAP = $(srcdir)/ylwrap instead of YLWRAP =
$(srcdir)/../ylwrap, and then include the new-style ylwrap in the GDB
directory, if we chose to. I suspect it'd be better just to wait until
we are willing/able to use automake to generate the makefiles for
binutils/ld/gas, but I have no strong opinion either way.
DJ Delorie
2002-12-05 16:28:20 UTC
Permalink
Post by Andrew Cagney
There is a problem with libiberty and utils because GCC have their
feet stuck in the ice
Plus the libiberty master *is* gcc, so you can't apply the patches to
just the src side anyway. The libiberty in src is a "mere copy" of
the one in gcc. You must apply libiberty patches to gcc either at the
same time or before applying them to src (and now is a bad time to
change gcc's libiberty).

Utils is not part of gcc.
Post by Andrew Cagney
(unless src, again splits off from GCC, but I suspect here we don't
want to).
Sorry, won't happen for libiberty.
Klee Dienes
2002-12-05 17:37:07 UTC
Permalink
As far as I can tell offhand, none of the other patches depend on
libiberty being updated, so one option is to upgrade the other
directories, and leave libiberty alone.

The downside of this is that gcc/binutils folks now need to keep
multiple versions of the tools around, and I imagine it would play hell
with --enable-maintainer-mode.

In what way is it a bad time to change libiberty? I'm not arguing with
the statement, just trying to understand the constraints a bit better.
Would it be possible to convert the libiberty on the bib-branch, and
import the binutils/gdb version from there?
Post by DJ Delorie
Post by Andrew Cagney
There is a problem with libiberty and utils because GCC have their
feet stuck in the ice
Plus the libiberty master *is* gcc, so you can't apply the patches to
just the src side anyway. The libiberty in src is a "mere copy" of
the one in gcc. You must apply libiberty patches to gcc either at the
same time or before applying them to src (and now is a bad time to
change gcc's libiberty).
Utils is not part of gcc.
Post by Andrew Cagney
(unless src, again splits off from GCC, but I suspect here we don't
want to).
Sorry, won't happen for libiberty.
DJ Delorie
2002-12-05 17:42:28 UTC
Permalink
Post by Klee Dienes
As far as I can tell offhand, none of the other patches depend on
libiberty being updated, so one option is to upgrade the other
directories, and leave libiberty alone.
That would be fine. If you had a patch that depended on libiberty
being upgraded, I'd probably question it anyway.
Post by Klee Dienes
The downside of this is that gcc/binutils folks now need to keep
multiple versions of the tools around, and I imagine it would play
hell with --enable-maintainer-mode.
You didn't propose changing gcc, newlib, cygwin, sid, or many other
projects, so this will be an issue regardless.
Post by Klee Dienes
In what way is it a bad time to change libiberty?
GCC is getting ready to branch for a release. After the branch, we'll
merge bib and be back to the usual openness.
Post by Klee Dienes
Would it be possible to convert the libiberty on the bib-branch, and
import the binutils/gdb version from there?
By the time the issues are worked out for gdb/binutils and the switch
made there, gcc will hopefully have branched. Plus the gcc head is
more stable than the branch anyway, which is what I'd prefer be the
main copy for everyone else.

How much of a hurry are you in, anyway?
Klee Dienes
2002-12-05 18:28:05 UTC
Permalink
My primary interest in all of this is to fully merge the Apple
Binutils/GDB sources into the FSF tree, which requires some changes to
libtool that are only in more recent versions of libtool/autoconf.

My secondary interest is that I seem to spend a lot of time hacking
Binutils/GDB makefiles, and I'd like that process to be as painless as
possible.

I'm in a moderate hurry for the gdb/binutils changes, mainly because
Apple needs to have some form of the changes to enable the FSF sources
to build properly on our platform, and I find the mental load of
maintaining the divergent sources to be a headache, particularly when
preparing patches.

I'm in no particular hurry for the libiberty changes, since it doesn't
use libtool anyway and the current build setup works fine for Apple in
the short-term. I eventually hope to libtool-ize libiberty as well,
but that can certainly wait until an appropriate time in the GCC
release cycle.
Post by DJ Delorie
By the time the issues are worked out for gdb/binutils and the switch
made there, gcc will hopefully have branched. Plus the gcc head is
more stable than the branch anyway, which is what I'd prefer be the
main copy for everyone else.
How much of a hurry are you in, anyway?
H. J. Lu
2002-12-05 17:30:58 UTC
Permalink
Post by Andrew Cagney
Er, wow! Few technical hurdles to overcome first.
Anyone know what happens if only half the directories get converted?
There is a problem with libiberty and utils because GCC have their feet
stuck in the ice (unless src, again splits off from GCC, but I suspect
here we don't want to).
That is my major concern. I have toolchain setups of gcc 2.96 + the
current binutils, gcc 3.2 + the current binutils, gcc 3.2-redhat-8 +
the current binutils and gcc 3.3 + the current binutils. Will they
ever work together?



H.J.
Maciej W. Rozycki
2002-12-05 15:44:10 UTC
Permalink
Post by Klee Dienes
The following patch updates the following directories to use the latest
bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils
ltmain.sh (GNU libtool) 1.4.3
autoconf (GNU Autoconf) 2.56
automake (GNU automake) 1.7.1
gettext (GNU gettext) 0.11.5
Does it work for both native and cross builds? Last time I checked,
autoconf 2.5x considered all binutils builds are for cross tools because
of the --target option set unconditionally by the top-level configure and
as a result prefixed all tool names with $target_alias upon install. The
patch doesn't seem to deal with it.

Otherwise -- nice work, thanks.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
Klee Dienes
2002-12-05 17:01:32 UTC
Permalink
Ah, indeed it does. I had tested a cross-build, but didn't think to
test 'make install' on the completed build. I'll take a look, thanks.
Post by Maciej W. Rozycki
Does it work for both native and cross builds? Last time I checked,
autoconf 2.5x considered all binutils builds are for cross tools because
of the --target option set unconditionally by the top-level configure and
as a result prefixed all tool names with $target_alias upon install.
The
patch doesn't seem to deal with it.
Otherwise -- nice work, thanks.
Daniel Jacobowitz
2002-12-05 16:10:07 UTC
Permalink
Post by Klee Dienes
The following patch updates the following directories to use the latest
bfd binutils gas gdb gprof ld libiberty mmalloc opcodes rda sim utils
ltmain.sh (GNU libtool) 1.4.3
autoconf (GNU Autoconf) 2.56
automake (GNU automake) 1.7.1
gettext (GNU gettext) 0.11.5
To apply the patch, I put the following four files in a directory, and
ran 'files.sh' in the top-level directory of the GDB/Binutils tree,
then configured and built with 'build.sh' (the script was necessary in
order to pass --enable-maintainer-mode to only the subdirectories for
which it was appropriate). I then did a full build to verify that
maintainer-mode was working, and used the files generated by
--enable-maintainer-mode as the final versions. I'm not including the
ChangeLog entries for all of the auto-generated files, as they're not
overly interesting; I plan to generate them with a perl script based on
the result of the build. I'm also not including the diffs to the
generated files, since they were about 6Mb, and not all that
interesting. I'm happy to provide either if requested.
Modulo other people's concerns, I pretty much like it. I've got two of
my own though.

1. Please make sure to coordinate with Nathanael Nerode, who is in the
middle of extensive autoconf-related work in the GCC repository.

2. I'd really, really like it if we had tarballs of the _exact_
version of all four autotools up on sources.redhat.com, and we required
(requested) all maintainers to download and use exactly those versions
when regenerating things. That makes it vaguely possible to hand-check
configure diffs. Red Hat and Debian ship slightly different versions
of autoconf 2.13...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
DJ Delorie
2002-12-05 16:29:45 UTC
Permalink
Post by Daniel Jacobowitz
2. I'd really, really like it if we had tarballs of the _exact_
version of all four autotools up on sources.redhat.com,
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
Daniel Jacobowitz
2002-12-05 16:35:49 UTC
Permalink
Post by DJ Delorie
Post by Daniel Jacobowitz
2. I'd really, really like it if we had tarballs of the _exact_
version of all four autotools up on sources.redhat.com,
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
Let me rephrase that in two parts:
- keep them updated with the new ones
- be more enthusiastic about recommending people use them. Most do
not.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
DJ Delorie
2002-12-05 16:36:57 UTC
Permalink
Post by Daniel Jacobowitz
Post by DJ Delorie
Post by Daniel Jacobowitz
2. I'd really, really like it if we had tarballs of the _exact_
version of all four autotools up on sources.redhat.com,
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
- keep them updated with the new ones
- be more enthusiastic about recommending people use them. Most do
not.
Hey, I didn't say it was perfect ;-)

I suppose we could rig up some auto-autoconf-commit script that just
did the right thing whenever configure.in's are committed.
Maciej W. Rozycki
2002-12-05 16:39:54 UTC
Permalink
Post by Daniel Jacobowitz
Post by DJ Delorie
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
- keep them updated with the new ones
- be more enthusiastic about recommending people use them. Most do
not.
Too bad special versions are required at all. It's a major PITA to keep
specific versions for various packages
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
Daniel Jacobowitz
2002-12-05 16:44:30 UTC
Permalink
Post by Maciej W. Rozycki
Post by Daniel Jacobowitz
Post by DJ Delorie
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
- keep them updated with the new ones
- be more enthusiastic about recommending people use them. Most do
not.
Too bad special versions are required at all. It's a major PITA to keep
specific versions for various packages
It's not that they're special - it's that they're _consistent_ that
matters.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Elena Zannoni
2002-12-05 17:14:58 UTC
Permalink
Post by Daniel Jacobowitz
Post by Maciej W. Rozycki
Post by Daniel Jacobowitz
Post by DJ Delorie
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
- keep them updated with the new ones
- be more enthusiastic about recommending people use them. Most do
not.
Too bad special versions are required at all. It's a major PITA to keep
specific versions for various packages
It's not that they're special - it's that they're _consistent_ that
matters.
Can a note with a link be added to the 'contribute' gdb page?
I, for instance, keep loosing the reference.

Elena
Post by Daniel Jacobowitz
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Klee Dienes
2002-12-05 17:54:48 UTC
Permalink
I actually found the files in ftp://sources.redhat.com/pub/binutils to
be an impediment to using the correct versions. For a long time I had
no idea they even existed, and then once I found out about them, it was
even more confusing, since they weren't the versions that were actually
used.

I'd argue that we should:

1) Specify the versions of autoconf/automake/libtool/gettext by
reference to official tarballs from ftp.gnu.org. In general, define
the version used to be "the most recent officially released version of
each tool".

and either

2a) Consider updates to generated files caused by re-configuring with
the most recent released version of the tools as an "obvious fix".

or (even better)

2b) Configure the CVS repository to run autoreconf using the most
recent versions whenever a new configure.in/Makefile.in/Makefile.am is
committed.

The idea here is that it's relatively straightforward for a
binutils/gdb maintainer to know what to do when updating a
configuration file (get the most recent version of the tools from the
FSF and use them), and that we have a natural tendency to stay
up-to-date with automake/autoconf changes, without having flag-day
style upgrades become an issue.
Post by DJ Delorie
They're in ftp://sources.redhat.com/pub/binutils/ already. Have been
for years.
Maciej W. Rozycki
2002-12-05 18:10:28 UTC
Permalink
Post by Klee Dienes
The idea here is that it's relatively straightforward for a
binutils/gdb maintainer to know what to do when updating a
configuration file (get the most recent version of the tools from the
FSF and use them), and that we have a natural tendency to stay
up-to-date with automake/autoconf changes, without having flag-day
style upgrades become an issue.
That would be the most acceptable approach to me. Of the tools involved,
only autoconf changed significantly recently with its transition from 2.13
to 2.50. But versions 2.5x are around long enough now to get more or less
stabilized, so hesitating from going forward and making an upgrade can
only impede development.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
Doug Evans
2002-12-05 18:58:22 UTC
Permalink
Post by Klee Dienes
1) Specify the versions of autoconf/automake/libtool/gettext by
reference to official tarballs from ftp.gnu.org.
This places a requirement on the maintainers of ftp.gnu.org
to not delete said tarballs until binutils has been updated.
I dont' think you or they want that kind of coupling.
Better to uncouple things and have your own tarballs.
Then you can upgrade according to your schedule, not theirs.
Klee Dienes
2002-12-05 20:10:56 UTC
Permalink
As long as the versions of the tools are specified by a version string
referencing an official version in README-maintainer-mode, and not by
"whatever version is on sourceware.cygnus.com", I'm happy.

In practice I can't imagine there would be a problem with versions
disappearing from the FSF site before we had upgraded to the current
version (the current autoconf repository has versions of autoconf going
back to 1996). But if that's a concern, we can always replicate
official FSF releases to a local directory and cache them there.
Post by Doug Evans
Post by Klee Dienes
1) Specify the versions of autoconf/automake/libtool/gettext by
reference to official tarballs from ftp.gnu.org.
This places a requirement on the maintainers of ftp.gnu.org
to not delete said tarballs until binutils has been updated.
I dont' think you or they want that kind of coupling.
Better to uncouple things and have your own tarballs.
Then you can upgrade according to your schedule, not theirs.
Ian Lance Taylor
2002-12-05 20:24:40 UTC
Permalink
Post by Klee Dienes
As long as the versions of the tools are specified by a version string
referencing an official version in README-maintainer-mode, and not by
"whatever version is on sourceware.cygnus.com", I'm happy.
That works until there is a bug which is a problem for the binutils
but there is not yet a new release.

It's not a theoretical point. That's the reason we started using
versions stored on sources.redhat.com in the first place.

Ian
Klee Dienes
2002-12-05 22:29:35 UTC
Permalink
Sure, but is it really a common situation where we are neither able to
revert to a previous released version of libtool, or get a release of
the upstream tools made with the needed fix in a timely fashion?

[ Here I wake up from my optimistic reverie and proceed to answer my
own rhetorical question: ]

The answer to this, of course, is "yes," and I agree that poor
backwards compatibility from autoconf-2.13 to autoconf-2.50 is the real
source of the problem here. My point is that the current solution
doesn't seem to be addressing the real problem --- we have essentially
created our own forked versions of all of the autotools, with no
visible plans to re-merge to the FSF version, and no intent to maintain
the forked version on our own.

I'm not arguing that it will never be necessary to fork our own version
of autotools in the case of a short-term emergency (well actually, I
might argue that, but I'm not arguing it here). I'm just arguing that
a forked version of binutils with no clear upstream referent is a
particularly bad state of affairs:

-rw-r--r-- 1 77 1002 259210 Feb 27 2000
autoconf-000227.tar.bz2
-rw-r--r-- 1 77 1002 292827 Feb 27 2000
automake-000227.tar.bz2
-rw-r--r-- 1 77 1002 519132 Feb 27 2000
gettext-000227.tar.bz2
-rw-r--r-- 1 77 1002 370603 Feb 27 2000
libtool-000227.tar.bz2
Post by Ian Lance Taylor
Post by Klee Dienes
As long as the versions of the tools are specified by a version string
referencing an official version in README-maintainer-mode, and not by
"whatever version is on sourceware.cygnus.com", I'm happy.
That works until there is a bug which is a problem for the binutils
but there is not yet a new release.
It's not a theoretical point. That's the reason we started using
versions stored on sources.redhat.com in the first place.
Ian
Maciej W. Rozycki
2002-12-06 13:24:57 UTC
Permalink
Post by Doug Evans
Post by Klee Dienes
1) Specify the versions of autoconf/automake/libtool/gettext by
reference to official tarballs from ftp.gnu.org.
This places a requirement on the maintainers of ftp.gnu.org
to not delete said tarballs until binutils has been updated.
I dont' think you or they want that kind of coupling.
Historically this is not a problem. The maintainers of ftp.gnu.org are
not that hasty in deleting old stuff (which is the right way). There are
old releases of autoconf back to 2.7, automake back to 1.0, gettext 0.10
and libtool 1.0. The worst that happens is moving stuff from /gnu to
/old-gnu.
Post by Doug Evans
Better to uncouple things and have your own tarballs.
Then you can upgrade according to your schedule, not theirs.
Of course archiving copies separately is not a problem, either. Then you
can write: "Get copies from ftp.gnu.org, or use versions archived here."
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
DJ Delorie
2002-12-06 14:44:37 UTC
Permalink
Post by Maciej W. Rozycki
Historically this is not a problem.
Legally it is. The first time they delete something we need, our
distribution becomes instantly illegal.

And traditionally, the GPL hasn't allowed you to put the
responsibility of providing sources on someone else.
Maciej W. Rozycki
2002-12-06 15:31:14 UTC
Permalink
Post by DJ Delorie
Post by Maciej W. Rozycki
Historically this is not a problem.
Legally it is. The first time they delete something we need, our
distribution becomes instantly illegal.
And traditionally, the GPL hasn't allowed you to put the
responsibility of providing sources on someone else.
I don't understand -- AFAIK, the GNU GPL doesn't enforce everyone making
use of files generated by autoconf/automake/gettext/libtool to distribute
sources of the said tools. As I understand, only if binutils use modified
tools, the relevant sources need to be made available. For versions using
such tools, making the patches available is obvious (for practical
reasons, too). Whether the original sources of the tools the patches
apply to need to be made available is unclear to me -- I can't decipher it
from the GNU GPL. It won't hurt certainly.

Anyway referring to ftp.gnu.org as the primary source of original
versions of tools the way I wrote should be fine legally, too.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
DJ Delorie
2002-12-06 16:20:27 UTC
Permalink
IANAL, but...
Post by Maciej W. Rozycki
I don't understand -- AFAIK, the GNU GPL doesn't enforce everyone
making use of files generated by autoconf/automake/gettext/libtool
to distribute sources of the said tools.
The preferred form for making modifications to configure is to edit
configure.in. Autoconf is not usually a standard part of the
operating system (esp when we require specific versions). Therefore,
it is a script used to control compilation, and must be considered
part of the source.

The only exception is that autoconf itself disclaims this connection,
and explicitly allows you to distribute configure without distributing
autoconf itself. I didn't check the other tools. I guess we're safe
legally.

We still have the problem of needing a specific version of the tools,
though.
Post by Maciej W. Rozycki
As I understand, only if binutils use modified tools, the relevant
sources need to be made available.
There's nothing in the GPL that even mentions patches.
Andrew Cagney
2002-12-05 18:59:15 UTC
Permalink
I actually found the files in ftp://sources.redhat.com/pub/binutils to be an impediment to using the correct versions. For a long time I had no idea they even existed, and then once I found out about them, it was even more confusing, since they weren't the versions that were actually used.
As a maintainer you should bring peoples attention to the fact that they
used the wrong autoconf the moment you notice it.
1) Specify the versions of autoconf/automake/libtool/gettext by reference to official tarballs from ftp.gnu.org. In general, define the version used to be "the most recent officially released version of each tool".
Reality check. If the offical autoconf has a bug, GDB and BINUTILS will
be forced to use a local version :-/
and either
2a) Consider updates to generated files caused by re-configuring with the most recent released version of the tools as an "obvious fix".
This is already the case. However, it doesn't address the problem of an
erant maintainer.
or (even better)
2b) Configure the CVS repository to run autoreconf using the most recent versions whenever a new configure.in/Makefile.in/Makefile.am is committed.
No. That discussion was considered for GDB and indent. Here the
problem is in maintainers being able to follow a procedure. Not a need
for a new tool.
The idea here is that it's relatively straightforward for a binutils/gdb maintainer to know what to do when updating a configuration file (get the most recent version of the tools from the FSF and use them), and that we have a natural tendency to stay up-to-date with automake/autoconf changes, without having flag-day style upgrades become an issue.
Andrew
Maciej W. Rozycki
2002-12-06 13:34:33 UTC
Permalink
Post by Andrew Cagney
1) Specify the versions of autoconf/automake/libtool/gettext by reference to official tarballs from ftp.gnu.org. In general, define the version used to be "the most recent officially released version of each tool".
Reality check. If the offical autoconf has a bug, GDB and BINUTILS will
be forced to use a local version :-/
Well, if that happens, the affected tool should be fixed eventually
(assuming the discoverer of the bug bothered submitting fixes to the
relevant maintainer). Until then, it's much better to make a patch that
fixes the bug available, than to prepare own tarballs (or apart from).
This way one may apply required patches to new versions of the tool. This
simplifies local maintenance of the tool as other patches or newer
versions may be required for other software.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
Ben Elliston
2002-12-05 21:26:51 UTC
Permalink
Klee> The idea here is that it's relatively straightforward for a
Klee> binutils/gdb maintainer to know what to do when updating a
Klee> configuration file (get the most recent version of the tools
Klee> from the FSF and use them), and that we have a natural
Klee> tendency to stay up-to-date with automake/autoconf changes,
Klee> without having flag-day style upgrades become an issue.

The flag day has less to do with the binutils and GCC development
process and more to do with Autoconf development. Some poor decisions
have been made there recently with respect to backward compatibility.

Ben
Alexandre Oliva
2002-12-30 19:41:09 UTC
Permalink
Sorry I'm a bit late in following up. I don't follow these lists as
closely as GCC, and this should have been copied there, at least for
the parts that affects the top level, since those are shared.
Post by Klee Dienes
ltmain.sh (GNU libtool) 1.4.3
Can't do that. The copy we use is from a newer code base than the 1.4
branch of libtool. It's taken from a 1.5-to-be (multi-language)
branch from quite a while ago, back when the ltcf-*.sh scripts hadn't
been merged into libtool.m4.
Post by Klee Dienes
* .cvsignore: Add autom4te.cache.
Please don't. autom4te.cache is an aberration. It shouldn't be
created by default, and it shouldn't be left dangling there in the
source tree. I'd much rather have rules that remove it as soon as
configure is rebuilt.
Post by Klee Dienes
* acinclude.m4: Remove include of libtool.m4.
Can't let you do that, Dave. This causes us to use whatever
libtool.m4 happens to be in aclocal.m4's search path, which is very
likely not compatible with ltmain.sh from the top level. That's why
we use libtool.m4 from the top level and keep all the libtool files in
sync. I wouldn't mind updating to the libtool current CVS tree, which
would get us rid of a number of files in the top level, but this takes
a lot of testing on many different platforms.
Post by Klee Dienes
* configure.in: Use AC_PROG_LEX instead of AM_PROG_LEX.
* configure: Pass --build=$host_alias to sub-makes if no other
value is specified.
Huh? configure is generated from configure.in. Besides, it's wrong
in principle. --build is not to be the same as --host, it's the other
way round (even though autoconf 2.13 got it backwards). Gotta find
out why we depend on build being defaulted to host and fixing that
instead.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
Klee Dienes
2003-01-01 01:16:06 UTC
Permalink
Post by Alexandre Oliva
Sorry I'm a bit late in following up. I don't follow these lists as
closely as GCC, and this should have been copied there, at least for
the parts that affects the top level, since those are shared.
Yes, my bad: at the time I had hoped to keep the changes contained to
the gdb/binutils side of the source tree. I did end up following up
with a revised patch to the gcc and newlib mailing lists, though, which
is probably a more interesting patch to comment on regardless:

http://sources.redhat.com/ml/binutils/2002-12/msg00293.html

I'm currently preparing a patch to update the gcc directories (boehm-gc
fastjar gcc libf2c libffi libjava libobjc libstdc++-v3 zlib) as well,
but it'll probably be another day or two before it's ready for posting
(the automake conversion is being particularly troublesome).
Post by Alexandre Oliva
Post by Klee Dienes
ltmain.sh (GNU libtool) 1.4.3
Can't do that. The copy we use is from a newer code base than the 1.4
branch of libtool. It's taken from a 1.5-to-be (multi-language)
branch from quite a while ago, back when the ltcf-*.sh scripts hadn't
been merged into libtool.m4.
Yes, I discovered that when I went to update the gcc directories to
autoconf-2.57. I've since updated to the current libtool top-of-tree
(1.4e-1.1168 2002/12/21), since no currently released libtool supports
tagged configurations.
Post by Alexandre Oliva
Post by Klee Dienes
* .cvsignore: Add autom4te.cache.
Please don't. autom4te.cache is an aberration. It shouldn't be
created by default, and it shouldn't be left dangling there in the
source tree. I'd much rather have rules that remove it as soon as
configure is rebuilt.
I could certainly agree that autom4te.cache is an aberration, but I'm
not clear why it's inappropriate to filter it out from the CVS
repository. For those who do use it, it's nice to have not showing up
in diff and update operations, and for those who don't, the existence
of the rule does no harm.
Post by Alexandre Oliva
Post by Klee Dienes
* acinclude.m4: Remove include of libtool.m4.
Can't let you do that, Dave. This causes us to use whatever
libtool.m4 happens to be in aclocal.m4's search path, which is very
likely not compatible with ltmain.sh from the top level. That's why
we use libtool.m4 from the top level and keep all the libtool files in
sync. I wouldn't mind updating to the libtool current CVS tree, which
would get us rid of a number of files in the top level, but this takes
a lot of testing on many different platforms.
Given that in theory anyone running aclocal or autoconf should be
running "official" and well-defined versions of those tools, they
should also be getting correct values for the contents of libtool.m4.
If their installed libtool.m4 is incompatible with the shipped
ltmain.sh, who is to say that their installed acgeneral.m4 won't be
incompatible with a shipped libtool.m4? I'd argue that libtool.m4 is
part of the autoconf environment, and that we should just require
people running aclocal or autoconf to have the correct installations of
the tools (as in theory we already do).
Post by Alexandre Oliva
Post by Klee Dienes
* configure.in: Use AC_PROG_LEX instead of AM_PROG_LEX.
* configure: Pass --build=$host_alias to sub-makes if no other
value is specified.
Huh? configure is generated from configure.in. Besides, it's wrong
in principle. --build is not to be the same as --host, it's the other
way round (even though autoconf 2.13 got it backwards). Gotta find
out why we depend on build being defaulted to host and fixing that
instead.
configure is generated automatically now, but it wasn't when I prepared
this patch.

If you look at the second patch I prepared
(http://sources.redhat.com/ml/binutils/2002-12/msg00293.html), you'll
see that I learned the error of my ways (as defined by
http://sources.redhat.com/ml/autoconf/2002-02/msg00059.html), and
updated the top-level configure to only pass --build, --host, and
--target when explicitly told to by the user (and updated the
sub-configures to behave properly in response to that).

This patch is now broken as of the autoconfiscation of the top-level,
which unfortunately reverts to the previous behavior of passing
--build, --host, and --target down to the sub-configures at all times.
I'm working to make a patch for this, but am still caught up on
updating the GCC directories to work properly with automake-1.7.2, so
it will probably be another day or two.
Alexandre Oliva
2003-01-12 13:21:10 UTC
Permalink
Post by Klee Dienes
Post by Alexandre Oliva
Post by Klee Dienes
* acinclude.m4: Remove include of libtool.m4.
Can't let you do that, Dave. This causes us to use whatever
libtool.m4 happens to be in aclocal.m4's search path, which is very
likely not compatible with ltmain.sh from the top level. That's why
we use libtool.m4 from the top level and keep all the libtool files in
sync. I wouldn't mind updating to the libtool current CVS tree, which
would get us rid of a number of files in the top level, but this takes
a lot of testing on many different platforms.
Given that in theory anyone running aclocal or autoconf should be
running "official" and well-defined versions of those tools, they
should also be getting correct values for the contents of libtool.m4.
If their installed libtool.m4 is incompatible with the shipped
ltmain.sh, who is to say that their installed acgeneral.m4 won't be
incompatible with a shipped libtool.m4? I'd argue that libtool.m4 is
part of the autoconf environment, and that we should just require
people running aclocal or autoconf to have the correct installations
of the tools (as in theory we already do).
I disagree, and the libtool manual recommends this practice precisely
to make sure the libtool files remain in sync. I see the revised
patch you just posted still has ChangeLog entries that say they're
removing the include statements. I hope it was just a mistake. If it
was not, please remove those changes and post a new patch, this time
copying gcc-***@gcc.gnu.org instead of ***@gcc.gnu.org. Letting
random macros kick in from the user's installation of aclocal is a
mistake in general (or not kicking in at all, in case the
officially-recommended versions of automake and libtool were installed
in different prefixes), since there's no way to make sure they're
compatible with other files that may depend on it. That's why there
is AC_PREREQ, but there's no such thing that affects aclocal's
behavior, so we're better off making sure we use the right version of
these files.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
Michael Elizabeth Chastain
2002-12-05 18:15:40 UTC
Permalink
Post by Klee Dienes
1) Specify the versions of autoconf/automake/libtool/gettext by
reference to official tarballs from ftp.gnu.org. In general, define
the version used to be "the most recent officially released version of
each tool".
I'm not a heavy autotools guy, but I do try to maintain a standardized
build + test enviroment for gdb testing. I agree with the idea of
referring to official tarballs from ftp.gnu.org. I strongly think that
the pointer should say "autoconf 2.56", for example, rather than "the
most recent officialy released version of autoconf".

If the pointer said "most recent officially released version of
autoconf", and I followed those instructions, then I would unwittingly
be using a different version of autoconf (2.57) then the version you are
standardizing on (2.56). I would prefer an absolute version number,
and we kick it forward when we are happy with the new release + when
the project is not frozen in that regard.

I'm comfortable with the ftp://sources.redhat.com/pub/binutils mirror if
we really do enforce that the versions in there are the versions that
we use. But I'm more comfortable if src/README-maintainer-mode points
directly to ftp.gnu.org. It seems easier to manage a version list in
README-maintainer-mode rather than ftp://sources.redhat.com/pub/binutils.
Also as a gdb maintainer I can notice changes in README-maintainer-mode
easier than I can notice changes in ftp://sources.redhat.com/pub/binutils.

(BTW the top level src/README-maintainer-mode file still refers to
ftp://sourceware.cygnus.com).

Michael C
Klee Dienes
2002-12-05 18:37:22 UTC
Permalink
That sounds fine to me. My main interest here is to make updating to
the most recent
version of the released tools be considered the "standard" thing to do.

On Thursday, December 5, 2002, at 01:15 PM, Michael Elizabeth Chastain
Post by Michael Elizabeth Chastain
Post by Klee Dienes
1) Specify the versions of autoconf/automake/libtool/gettext by
reference to official tarballs from ftp.gnu.org. In general, define
the version used to be "the most recent officially released version of
each tool".
I'm not a heavy autotools guy, but I do try to maintain a standardized
build + test enviroment for gdb testing. I agree with the idea of
referring to official tarballs from ftp.gnu.org. I strongly think that
the pointer should say "autoconf 2.56", for example, rather than "the
most recent officialy released version of autoconf".
Nathanael Nerode
2002-12-05 19:07:28 UTC
Permalink
Post by Daniel Jacobowitz
1. Please make sure to coordinate with Nathanael Nerode, who is in the
middle of extensive autoconf-related work in the GCC repository.
I really would like to see the tree using autoconf 2.5x as soon as
possible; if this can be done before I autoconfiscate the top level
(which is not autoconfiscated yet) it will save me an awful lot of
trouble, since I can then use autoconf 2.5x for that autoconfiscation.
:-/

Your patch as is updates
bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils

Can you please work up a patch for gcc 3.4 to update
boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc
libstdc++-v3 zlib

And a patch for Insight
itcl libgui

And one for Dejagnu
dejagnu expect

And for Newlib & Cygwin
libgloss newlib winsup

And one for
sid

and one for
intl

--
However, I think that it's OK to update one directory at a time,
provided we specify clearly what's going on, and get it all done before
the next release of anything.

Accordingly, I suggest getting clean patches for small sets of
directories, making sure they work, getting them reviewed, and then
putting them in; and then starting on the next set. Keep sending update
notices to the various lists regarding which directories use the 'new'
tools and which use the 'old'. If you can make scripts which work
correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means
do so *first*, and mark those scripts as "compatibile with both", of
course; but I expect that will only happen for the simplest directories.

If this is acceptable to other people in the various groups of course.

I expect this will generate a certain amount of breakage, but then so
did my changes. In both cases, it needs to be done, we just have to
make sure all the breakage gets fixed.

--Nathanael

P.S.
It was mentioned that autoconf2.5 scripts will have trouble with
building because of the top level passing down --target unconditionally.

Unfortunately I think some other aspects of the configure scripts
require --target to be passed down unconditionally. :-/ Otherwise I'd
just change it.
Andrew Cagney
2002-12-05 19:31:11 UTC
Permalink
Post by Nathanael Nerode
I really would like to see the tree using autoconf 2.5x as soon as
possible; if this can be done before I autoconfiscate the top level
(which is not autoconfiscated yet) it will save me an awful lot of
trouble, since I can then use autoconf 2.5x for that autoconfiscation.
:-/
Your patch as is updates
bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils
Can you please work up a patch for gcc 3.4 to update
boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc
libstdc++-v3 zlib
Just a step back here. Some of the directories listed below belong to
the FSF, but some don't. I don't think anyone can be asking Klee to
update non FSF code. That's why I asked Klee to drop RDA from the
original list.
Post by Nathanael Nerode
And a patch for Insight
itcl libgui
And one for Dejagnu
dejagnu expect
And for Newlib & Cygwin
libgloss newlib winsup
And one for
sid
and one for
intl
--
However, I think that it's OK to update one directory at a time,
provided we specify clearly what's going on, and get it all done before
the next release of anything.
I don't think we can guarentee that, but I think we can live with the
consequences :-/
Post by Nathanael Nerode
Accordingly, I suggest getting clean patches for small sets of
directories, making sure they work, getting them reviewed, and then
putting them in; and then starting on the next set. Keep sending update
notices to the various lists regarding which directories use the 'new'
tools and which use the 'old'. If you can make scripts which work
correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means
do so *first*, and mark those scripts as "compatibile with both", of
course; but I expect that will only happen for the simplest directories.
If this is acceptable to other people in the various groups of course.
I expect this will generate a certain amount of breakage, but then so
did my changes. In both cases, it needs to be done, we just have to
make sure all the breakage gets fixed.
Andrew
Post by Nathanael Nerode
--Nathanael
P.S.
It was mentioned that autoconf2.5 scripts will have trouble with
building because of the top level passing down --target unconditionally.
Unfortunately I think some other aspects of the configure scripts
require --target to be passed down unconditionally. :-/ Otherwise I'd
just change it.
Zack Weinberg
2002-12-05 21:31:52 UTC
Permalink
Post by Nathanael Nerode
Accordingly, I suggest getting clean patches for small sets of
directories, making sure they work, getting them reviewed, and then
putting them in; and then starting on the next set. Keep sending update
notices to the various lists regarding which directories use the 'new'
tools and which use the 'old'. If you can make scripts which work
correctly under *both* autoconf 2.5x *and* autoconf 2.13, by all means
do so *first*, and mark those scripts as "compatibile with both", of
course; but I expect that will only happen for the simplest directories.
I'd like to remind everyone involved that last I checked it was flat
impossible to do what libstdc++-v3/configure.in needs to do, using
autoconf 2.5x. I am not particularly sanguine about the situation
having changed, since it involved the undocumented AC_NO_EXECUTABLES
macro that as far as I know nobody but us has a use for -- and we're
not using it, because it doesn't do what we need it to do. Until that
is resolved, which will involve submitting patches to autoconf,
getting them accepted upstream, and waiting for a release, gcc
*cannot* move to autoconf 2.5x. We are not being stick-in-the-muds
because we want to.

(Please, I beg of you, prove me wrong about this problem.)

I am concerned about the prospect of having the src repository update
to 2.5x while the gcc repository is still stuck with 2.13. Having
different parts of the combined tree need different versions of
autotools is a recipe for disaster.

But I do see a way forward. It goes like this. One directory at a
time, we go through and do whatever it takes to get that directory's
configure.in to work properly with both 2.13 and 2.5x, independent of
what version of autoconf was used to generate configure in other
directories. This may involve submitting patches to the autoconf
maintainers. Whoever volunteers to do this must be willing to
maintain these scripts in that state indefinitely -- I did it for the
gcc subdirectory a year or so ago and I discovered a couple weeks back
that it had mysteriously broken.

Once the entire tree makes it into this state, we have a flag day
where we bump AC_PREREQ and regenerate everything. And only then can
we start using 2.5x specific features in configure scripts.

As for libtool and automake, my suggestion is, as usual, that both
should be eradicated from the face of the Earth; as this proposal is
probably a non-starter, I decline to discuss what to do with them any
further.

zw
Alan Modra
2002-12-05 22:29:45 UTC
Permalink
Post by Zack Weinberg
But I do see a way forward. It goes like this. One directory at a
time, we go through and do whatever it takes to get that directory's
configure.in to work properly with both 2.13 and 2.5x, independent of
what version of autoconf was used to generate configure in other
directories. This may involve submitting patches to the autoconf
maintainers. Whoever volunteers to do this must be willing to
maintain these scripts in that state indefinitely -- I did it for the
gcc subdirectory a year or so ago and I discovered a couple weeks back
that it had mysteriously broken.
I'm concerned that this proposal may be raising the bar too high.
How long has it been since some poor fool^H^H^H^H^H^H^H^H^Hbrave soul
attempted to modernize binutils configury?

It seems that the major impact of configuring parts of a tree using
different autoconf versions will be on people using
--enable-maintainer-mode, so another solution might be to extend
--enable-maintainer-mode to accept a list of directories. I suspect
most developers will only want --enable-maintainer-mode in the
particular area they work on.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Ian Lance Taylor
2002-12-05 22:55:38 UTC
Permalink
Post by Alan Modra
I'm concerned that this proposal may be raising the bar too high.
How long has it been since some poor fool^H^H^H^H^H^H^H^H^Hbrave soul
attempted to modernize binutils configury?
It's only been a bit over five years since I reworked binutils
configury to use automake and libtool.

I guess it was about two years before that that Ken Raeburn and I
changed the binutils to use autoconf.

I'm sure I don't know why autoconf 2.5 is not called autoconf 3.
Still, switching to autoconf 2.5 is surely a smaller change than
either of those.

It should be easy enough to extend AC_PREREQ a bit to make sure that
people use the correct version of autoconf for the directory in
question.

Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.

Ian
Alan Modra
2002-12-05 23:19:09 UTC
Permalink
Post by Ian Lance Taylor
Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.
It would need to be on a per-directory basis. Something like

--enable-maintainer-mode=\
"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Ian Lance Taylor
2002-12-05 23:40:04 UTC
Permalink
Post by Alan Modra
Post by Ian Lance Taylor
Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.
It would need to be on a per-directory basis. Something like
--enable-maintainer-mode=\
"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"
Yes, I suppose that would be required to support a single
--enable-maintainer-mode at the top level.

On the other hand, I personally usually run a basic configure at the
top level, and then run configure again in the subdirectories for
which I want to use --enable-maintainer-mode.

Ian
Andrew Cagney
2002-12-05 23:47:38 UTC
Permalink
Post by Ian Lance Taylor
Yes, I suppose that would be required to support a single
--enable-maintainer-mode at the top level.
On the other hand, I personally usually run a basic configure at the
top level, and then run configure again in the subdirectories for
which I want to use --enable-maintainer-mode.
So _thats_ how to avoids maintainer mode on all but one directory...

Andrew
Mike Stump
2002-12-05 23:45:52 UTC
Permalink
Post by Alan Modra
Post by Ian Lance Taylor
Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.
It would need to be on a per-directory basis. Something like
--enable-maintainer-mode=\
"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"
This is beyond gross. :-(

Better to require

autoconf-2.14
autoconf

and then have each directory know which one to use, and require the
advanced user to have these.

OAUTOCONF = autoconf-2.14
AUTOCONF = autoconf

and then use $(AUTOCONF) for new uses, and $(OAUTOCONF) for old uses.

Also, we need a version check on the old autoconf to be sure that it
isn't too new.
Alan Modra
2002-12-06 00:26:06 UTC
Permalink
Post by Mike Stump
Post by Alan Modra
Post by Ian Lance Taylor
Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.
It would need to be on a per-directory basis. Something like
--enable-maintainer-mode=\
"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"
This is beyond gross. :-(
Sniff. I'm sure I could make it a lot more gross. :)
Post by Mike Stump
Better to require
autoconf-2.14
autoconf
and then have each directory know which one to use, and require the
advanced user to have these.
OAUTOCONF = autoconf-2.14
AUTOCONF = autoconf
and then use $(AUTOCONF) for new uses, and $(OAUTOCONF) for old uses.
Also, we need a version check on the old autoconf to be sure that it
isn't too new.
The trouble with this idea is that older autoconf and automake aren't
installed as $tool-$version, and last I checked, current autoconf
doesn't install with a version suffix. Old tools really need to be
installed with a different --prefix. Hmm, I suppose a few symbolic
links would cure that problem. What happens if you need three three
or four different versions of autoconf?
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Zack Weinberg
2002-12-06 00:30:53 UTC
Permalink
Post by Alan Modra
The trouble with this idea is that older autoconf and automake aren't
installed as $tool-$version, and last I checked, current autoconf
doesn't install with a version suffix. Old tools really need to be
installed with a different --prefix. Hmm, I suppose a few symbolic
links would cure that problem. What happens if you need three three
or four different versions of autoconf?
Debian has a clever wrapper script (in the autoconf2.13 package) that
causes configure to get regenerated using 2.13 unless there's an
AC_PREREQ(2.5x) line in configure.in, or configure.in is named
configure.ac.

But I think that we really just ought to get the transition done,
assuming that it is in fact possible.

zw
Klee Dienes
2002-12-08 10:48:52 UTC
Permalink
Post by Alan Modra
Post by Ian Lance Taylor
Perhaps --enable-maintainer-mode could be extended to specify a PATH
to use to find the tools.
It would need to be on a per-directory basis. Something like
--enable-maintainer-mode=\
"gdb:/usr/local/000227/bin,libstdc++-v3:/usr/local/oldauto/bin,*:yes"
What if the rules generated by --enable-maintainer-mode were to pass a
version number to each of the tools when using them to re-generate
files? The version number passed would be the same version number used
to generate the existing version of the generated files. Then the
autotools could either dispatch to the correct version of the tool
based on the version number, or
perhaps generate an error if the version numbers did not match. In
order to upgrade the generated files in a directory to a newer version,
the user would have to explicitly run autoreconf or run he appropriate
autotools directly.

This would make it a lot harder for a maintainer to accidentally use
the wrong version of an autotool when regenerating files in a
directory. It would also make it possible to write a top-level script
that would explicitly re-generate all of the files in a tree with
explicitly specified versions (or at least verify that the versions
being used were correct).

Regardless of how we choose to do it, though, I think it's important
that maintainers be able to update individual subdirectories to newer
versions of the autotools independently of each other (even if the way
we choose to do that is to say "don't run global
--enable-maintainer-mode, and be aware of the versions of the autotools
you are using"). If we don't, the bar for updating versions of
autotools is just too high. Trying to coordinate a simultaneous
upgrade of even a simple change across the combined src+gcc repository
is a huge amount of work --- if that's the only way to do upgrades, it
seems much more likely that the upgrades will tend to not get done.
The thought of even *touching* sid is daunting to me, much less the
thought of trying to claim that I've changed all of its Makefiles and
understand the changes.
Christopher Faylor
2002-12-05 22:08:30 UTC
Permalink
Post by Nathanael Nerode
Can you please work up a patch for gcc 3.4 to update
boehm-gc fastjar gcc libf2c libffi libiberty libjava libobjc
libstdc++-v3 zlib
And a patch for Insight
itcl libgui
And one for Dejagnu
dejagnu expect
And for Newlib & Cygwin
libgloss newlib winsup
Remember that any changes to configury in newlib or cygwin *require
approval*. Please don't just check in changes in these directories.
CVS commit permission in gdb or binutils does not imply permission for
cygwin, newlib, or most of the other directories in the 'src'
repository.

cgf
Maciej W. Rozycki
2002-12-06 13:52:16 UTC
Permalink
Post by Nathanael Nerode
It was mentioned that autoconf2.5 scripts will have trouble with
building because of the top level passing down --target unconditionally.
Unfortunately I think some other aspects of the configure scripts
require --target to be passed down unconditionally. :-/ Otherwise I'd
just change it.
Well, at least ${tooldir} requires to be set properly (that's typically
${exec_prefix}/${target_alias}) and currently it is done by passing
--target which sets ${target_alias}. However it may be possible to set
${tooldir} based on ${host_alias} or even ${build_alias}, as ${*_alias}
variables are empty if not set by a user. I think the order should be:

if test "x${target_alias}" != x; then
# Cross-tools
tooldir = '${exec_prefix}'/${target_alias}
elif test "x${host_alias}" != x; then
# Native tools for a different host
tooldir = '${exec_prefix}'/${host_alias}
elif test "x${build_alias}" != x; then
# Native tools using an explicit alias
tooldir = '${exec_prefix}'/${build_alias}
else
# Native tools using a default alias
tooldir = '${exec_prefix}'/${build}
fi

And then only pass these of --build, --host, --target to subdirectories
which have their respective ${*_alias} variable set. Obviously
${program_prefix} should either only be set if ${target_alias} is not
empty or use the above outline, too.

I'll check if the approach works for me -- anyone interested is invited
to do that, too.

Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: ***@ds2.pg.gda.pl, PGP key available +
Klee Dienes
2002-12-08 10:48:55 UTC
Permalink
Post by Nathanael Nerode
Unfortunately I think some other aspects of the configure scripts
require --target to be passed down unconditionally. :-/ Otherwise I'd
just change it.
There's a useful thread on the host/target/build business in
http://sources.redhat.com/ml/autoconf/2002-02/msg00059.html (which I
imagine you're already familiar with, but it makes a nice reference).

I did some preliminary experiments with modifying what the top-level
configure passes down, and at least from the binutils/gdb side of
things, it looked promising. I ended up changing the top-level
configure semantics to match that of autoconf:

configure --build=BUILD --host=HOST --target=TARGET UNDEFS

1. You aren't allowed to specify --host, --build, --target, and undefs
at the same time.
2. Build defaults to undefs.
3. If undefs is not specified, then build defaults to the current
host, as determined by config.guess.
4. Host defaults to undefs.
5. If undefs is not specified, then host defaults to build.
6. Target defaults to undefs.
7. If undefs is not specified, then target defaults to host.

passing --host means you cross compile (whatever the relationship
between host and build)
passing --target means you build a cross-tool (whatever the
relationship between host and target).

--host and --target are only passed to sub-configures if they were
explicitly passed to the top-level configure on the command-line.

This fixed the problem with things installing in the wrong places; the
only fallout was that the emulation-selection code in binutils/ needed
to be changed to refer to $target instead of $target_alias. A basic
gcc build appeared to work, but I didn't try anything more complicated
than a stadard cross-compile setup.
Klee Dienes
2003-01-12 10:31:45 UTC
Permalink
The following is the current state-of-the art of my autoconf-2.5x
conversion of the gcc/gdb/binutils repositories. It updates the
following directories:

common: libiberty
src: bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils
gcc: boehm-gc fastjar gcc libf2c libffi libjava libobjc libstdc++-v3
zlib

It does *not* update the following directories:

common: include texinfo config etc contrib
src: blt cgen cpu dejagnu expect intl itcl iwidgets libgloss libgui
newlib readline tcl tk winsup sid"
gcc: libbanshee libchill libio libmudflap libstdc++"

I used the following versions of the various tools:

libtool: 1.4e (top-of-tree, with the attached patch)
autoconf: 2.57 (with the attached patch)
automake: 1.7.2
gettext: 0.11.5
autogen: 5.5

The attached archive contains the following files:

ChangeLog:
setup.sh: Script to convert to autotools-2.5x and build an uberbaum
tree
autoconf.txt: Fixes to autoconf-2.57 required by this patch.
common-diffs.txt Patches to directories shared by 'src' and gcc.
gcc-diffs.txt Patches to the gcc directories.
libtool-diffs.txt Patch to libtool-1.4e required by this patch.
src-diffs.txt Patches to the 'src' directories.
top-diffs.txt Patches to top-level files in both 'src' and gcc.
Nathanael Nerode
2003-01-12 16:13:56 UTC
Permalink
Post by Klee Dienes
The following is the current state-of-the art of my autoconf-2.5x
conversion of the gcc/gdb/binutils repositories. It updates the
common: libiberty
src: bfd binutils gas gdb gprof ld mmalloc opcodes rda sim utils
gcc: boehm-gc fastjar gcc libf2c libffi libjava libobjc
libstdc++-v3 zlib
common: include texinfo config etc contrib
'include' shouldn't have a makefile.
'texinfo' is either imported from outside, or doesn't have a makefile.
'config' doesn't have one.
'contrib' shouldn't have one.
I'm not sure about 'etc', but I think it shouldn't.
Post by Klee Dienes
src: blt cgen cpu dejagnu expect intl itcl iwidgets libgloss
libgui newlib readline tcl tk winsup sid"
I don't know anything about 'blt', but it's not built by the top level,
so shouldn't be an issue.
'cgen' isn't built by the top level currently (although it will be again
sometime in the future) so it's not an issue either.
'dejagnu' is imported from outside, so we shouldn't touch it.
'expect' is imported from outside.
I don't know about 'intl'.
'itcl' is imported from outside. (I think it still is, anyway.)
I don't know about 'iwidgets', but it's not built by the top level, so I
don't think we have to worry about it.
--> 'libgloss' actually needs to be done, I'm afraid.
--> I'm not sure about the status of 'libgui'.
--> 'newlib' actually needs to be done as well.
'readline' is imported from outside.
'tcl' is imported from outside.
'tk' is imported from outside.
--> 'winsup' is Cygwin. It should be done, sometime.
--> 'sid' should be done.
Post by Klee Dienes
gcc: libbanshee libchill libio libmudflap libstdc++"
'libbanshee' is branch only; the branch maintainer should do this.
'libchill' is dead.
'libio' is dead.
'libmudflap' is branch only; the branch maintainer should do this.
'libstdc++' is dead.

In other words, excellent work. :-)
I'll try to make a pass at the remaining directories, but I'm not sure
when I'll get to them.

I'd like to see some version of this in sooner rather than later;
incremental fixes are easier from this point than from the current
point, and it would be nice if it went in during gcc 'stage 1' when
major destabilizing changes are allowed.
Post by Klee Dienes
autoconf: 2.57 (with the attached patch)
Think you can submit the patch to the autoconf maintainers and get it
into mainline autoconf?
Post by Klee Dienes
top-diffs.txt Patches to top-level files in both 'src' and gcc.
Honestly, I've wanted to make the ${x_alias}-->${x} change for the
directory names for a *long* time, but
a) it has to be done synchronously in all subdirectories and
b) it changes developer-visible behavior for cross builds (canonical
name rather than specified name)

If I could get buy-in from gcc, gdb, and binutils for a patch doing just
that, I would put it in right now (and make your diffs for autoconf 2.57
conversion rather shorter). I never submitted it 'cause I figured it
would not be popular.

An alternative, if perhaps sillier, scheme would be to create new
autoconf macros to find the ${build_subdir} and ${target_subdir} values,
and put it in a file included by everyone who cares.

But it's *much* simpler to always use the canonicalized names.

--Nathanael
Zack Weinberg
2003-01-12 17:13:57 UTC
Permalink
Post by Klee Dienes
The following is the current state-of-the art of my autoconf-2.5x
conversion of the gcc/gdb/binutils repositories.
Two general comments:

1) I notice that you made the existing pseudo-AC_PROG_CC/CXX macros
work again with 2.5x; this is wrong. Get rid of them entirely,
use the canonical AC_PROG_CC/CXX, and if they don't work right,
patch autoconf until they do.

2) Why did you disable the shared config.cache? It speeds up 'make
configure' by an order of magnitude, especially on slow machines.

zw
Klee Dienes
2003-01-13 03:32:03 UTC
Permalink
Post by Zack Weinberg
1) I notice that you made the existing pseudo-AC_PROG_CC/CXX macros
work again with 2.5x; this is wrong. Get rid of them entirely,
use the canonical AC_PROG_CC/CXX, and if they don't work right,
patch autoconf until they do.
The original theory was that I was trying to keep the diffs to a
minimum, and that once the switch was flipped on 2.x, we could go back
and make a lot of more interesting cleanups to the configure scripts.
But I think you're right that my changes ended up complicated enough
that I should just replace them with the modern versions; I'll do that.
Post by Zack Weinberg
2) Why did you disable the shared config.cache? It speeds up 'make
configure' by an order of magnitude, especially on slow machines.
I didn't disable the config.cache in the top-level scripts; it's just
that the new default is for autoconf to use a null cache file unless
configured with '-C'. A good portion of my patch is actually present
solely to fix the use of a top-level cache file --- there were a number
of places where whitespace triggered the "value changed between runs"
checks in 2.5x. I did disable the target config.cache, because there
were places where things really were being run with different flags
between runs (for example, the value of libstdcxx_flags varies by
directory), and fixing that seemed beyond the scope of the initial
conversion to 2.5x.
Zack Weinberg
2003-01-13 07:30:47 UTC
Permalink
Post by Klee Dienes
The original theory was that I was trying to keep the diffs to a
minimum, and that once the switch was flipped on 2.x, we could go back
and make a lot of more interesting cleanups to the configure scripts.
That's fair...
Post by Klee Dienes
But I think you're right that my changes ended up complicated enough
that I should just replace them with the modern versions; I'll do that.
It may actually make sense to do the replacement as a separate patch,
introducing a shared aclocal.m4 fragment that backports
AC_NO_EXECUTABLES or similar to 2.13. Put that in first, and your
diffs for the 2.5x conversion get quite a bit simpler.
Post by Klee Dienes
I didn't disable the config.cache in the top-level scripts; it's
just that the new default is for autoconf to use a null cache file
unless configured with '-C'.
I may have misunderstood your patch but I got the definite impression
that you dropped out the only bit that passes down the top-level
--cache-file setting to the sub-configures. Which would mean, even if
the top level was run with -C, the sub-configures would use no cache
file, and wouldn't share caches if they did.

The change of default is wrong, but that's not your fault.
Post by Klee Dienes
I did disable the target config.cache, because there were places
where things really were being run with different flags between runs
(for example, the value of libstdcxx_flags varies by directory), and
fixing that seemed beyond the scope of the initial conversion to 2.5x.
Yeah, that's reasonable. We'll want it back eventually though.

zw

Nathanael Nerode
2002-12-05 22:35:38 UTC
Permalink
Post by Zack Weinberg
I'd like to remind everyone involved that last I checked it was flat
impossible to do what libstdc++-v3/configure.in needs to do, using
autoconf 2.5x. I am not particularly sanguine about the situation
Flat impossible?

Wow.

And for the top level, all I had to do was define my own entire set of
macros to replace the AC_CHECK_TOOL and AC_PROG_* collection. :-)

I'd be interested to hear more about the problem. Why can't it be dealt
with by using private macros?

--Nathanael
Zack Weinberg
2002-12-05 23:15:29 UTC
Permalink
Post by Nathanael Nerode
Post by Zack Weinberg
I'd like to remind everyone involved that last I checked it was flat
impossible to do what libstdc++-v3/configure.in needs to do, using
autoconf 2.5x. I am not particularly sanguine about the situation
Flat impossible?
Wow.
Like I said, I'd be delighted to be proved wrong.
Post by Nathanael Nerode
I'd be interested to hear more about the problem. Why can't it be
dealt with by using private macros?
It was a couple years ago, but I think I still remember pretty
clearly.

First off, you've probably met this stuff (from libstdc++/aclocal.m4):

# Never versions of autoconf add an underscore to these functions.
# Prevent future problems ...
ifdef([AC_PROG_CC_G],[],[define([AC_PROG_CC_G],defn([_AC_PROG_CC_G]))])
ifdef([AC_PROG_CC_GNU],[],[define([AC_PROG_CC_GNU],defn([_AC_PROG_CC_GNU]))])
ifdef([AC_PROG_CXX_G],[],[define([AC_PROG_CXX_G],defn([_AC_PROG_CXX_G]))])
ifdef([AC_PROG_CXX_GNU],[],[define([AC_PROG_CXX_GNU],defn([_AC_PROG_CXX_GNU]))])

# AC_PROG_CC
# FIXME: We temporarily define our own version of AC_PROG_CC. This is
# copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS. We
# are probably using a cross compiler, which will not be able to fully
# link an executable. This is addressed in later versions of autoconf.

AC_DEFUN(LIB_AC_PROG_CC,
[AC_BEFORE([$0], [AC_PROG_CPP])dnl
dnl Fool anybody using AC_PROG_CC.
AC_PROVIDE([AC_PROG_CC])
AC_CHECK_PROG(CC, gcc, gcc)
if test -z "$CC"; then
AC_CHECK_PROG(CC, cc, cc, , , /usr/ucb/cc)
test -z "$CC" && AC_MSG_ERROR([no acceptable cc found in \$PATH])
fi

AC_PROG_CC_GNU

if test $ac_cv_prog_gcc = yes; then
GCC=yes
dnl Check whether -g works, even if CFLAGS is set, in case the package
dnl plays around with CFLAGS (such as to build both debugging and
dnl normal versions of a library), tasteless as that idea is.
ac_test_CFLAGS="${CFLAGS+set}"
ac_save_CFLAGS="$CFLAGS"
CFLAGS=
AC_PROG_CC_G
if test "$ac_test_CFLAGS" = set; then
CFLAGS="$ac_save_CFLAGS"
elif test $ac_cv_prog_cc_g = yes; then
CFLAGS="-g -O2"
else
CFLAGS="-O2"
fi
else
GCC=
test "${CFLAGS+set}" = set || CFLAGS="-g"
fi
])

This is a clone of the 2.13 AC_PROG_CC with some minor modifications:
specifically, the AC_PROG_CC_WORKS call was removed. With autoconf
2.50+, the internal structure of AC_PROG_CC is totally different, and
this definition breaks. (The "newer versions of autoconf" stuff was
someone's attempt to fix it, but it doesn't work.)

Someone on the autoconf team knew about this and tried to help out by
providing an undocumented macro called AC_NO_EXECUTABLES:

# AC_NO_EXECUTABLES
# -----------------
# FIXME: The GCC team has specific needs which the current Autoconf
# framework cannot solve elegantly. This macro implements a dirty
# hack until Autoconf is abble to provide the services its users
# needs.
#
# Several of the support libraries that are often built with GCC can't
# assume the tool-chain is already capable of linking a program: the
# compiler often expects to be able to link with some of such
# libraries.
#
# In several of these libraries, workarounds have been introduced to
# avoid the AC_PROG_CC_WORKS test, that would just abort their
# configuration. The introduction of AC_EXEEXT, enabled either by
# libtool or by CVS autoconf, have just made matters worse.
AC_DEFUN_ONCE([AC_NO_EXECUTABLES],
[m4_divert_push([KILL])

AC_BEFORE([$0], [_AC_COMPILER_EXEEXT_WORKS])
AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])

m4_define([_AC_COMPILER_EXEEXT_WORKS],
[cross_compiling=maybe
])

m4_define([_AC_COMPILER_EXEEXT],
[EXEEXT=
])

m4_define([AC_LINK_IFELSE],
[AC_FATAL([All the tests involving linking were disabled by $0])])

m4_divert_pop()dnl
])# AC_NO_EXECUTABLES

(lang.m4 from autoconf 2.56)

AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf
to barf if an AC_TRY_LINK test appears anywhere in the script being
generated. libstdc++-v3/configure.in has lots of AC_TRY_LINK tests.
They are only executed in a native compilation, but that's not good
enough for AC_NO_EXECUTABLES.

Going over it all again, I realize that we could probably just
redefine AC_NO_EXECUTABLES to do what we want. We'd have to
specialize its definition for every version of autoconf that we cared
about, and check at every new release that it hadn't broken, but it
would work. I guess it's not impossible after all.

zw
Tom Tromey
2002-12-06 17:03:15 UTC
Permalink
Zack> Someone on the autoconf team knew about this and tried to help out by
Zack> providing an undocumented macro called AC_NO_EXECUTABLES:

Zack> # FIXME: The GCC team has specific needs which the current Autoconf
Zack> # framework cannot solve elegantly. This macro implements a dirty
Zack> # hack until Autoconf is abble to provide the services its users
Zack> # needs.

Zack> They are only executed in a native compilation, but that's not good
Zack> enough for AC_NO_EXECUTABLES.

Presumably if AC_NO_EXECUTABLES exists solely for the use of gcc, then
it could be changed to do what gcc actually requires.

Tom
Alexandre Oliva
2002-12-07 20:49:48 UTC
Permalink
Post by Zack Weinberg
AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf
to barf if an AC_TRY_LINK test appears anywhere in the script being
generated.
Please tell me why (2) doesn't make sense.

If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
you expect to get any useful results from AC_TRY_LINK?
Post by Zack Weinberg
libstdc++-v3/configure.in has lots of AC_TRY_LINK tests.
If we know AC_PROG_CC_WORKS fails, it is a mistake to use AC_TRY_LINK
tests. Removing the constraint from autoconf will do us no good.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
Zack Weinberg
2002-12-07 21:06:02 UTC
Permalink
Post by Alexandre Oliva
Post by Zack Weinberg
AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf
to barf if an AC_TRY_LINK test appears anywhere in the script being
generated.
Please tell me why (2) doesn't make sense.
If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
you expect to get any useful results from AC_TRY_LINK?
Because libstdc++'s AC_TRY_LINK tests are only executed in a situation
where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation).

zw
Alexandre Oliva
2002-12-10 02:56:06 UTC
Permalink
Post by Zack Weinberg
Post by Alexandre Oliva
Post by Zack Weinberg
AC_NO_EXECUTABLES has two effects: (1) it disables the equivalent of
AC_PROG_CC_WORKS, which is what we need. But, (2) it causes autoconf
to barf if an AC_TRY_LINK test appears anywhere in the script being
generated.
Please tell me why (2) doesn't make sense.
If AC_PROG_CC_WORKS can't even link a do-nothing program, how would
you expect to get any useful results from AC_TRY_LINK?
Because libstdc++'s AC_TRY_LINK tests are only executed in a situation
where AC_PROG_CC_WORKS would have succeeded (i.e. a native compilation).
I don't get it. Why does being able to link have anything to do with
being native? Being able to *run* tests has to do with being native,
but that's not the point, and autoconf already avoids running tests
when cross-building. But being able to link has to do with whether
the libraries that the compiler links in by default are present or
not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests
while building a library that the compiler driver would attempt to link
in by default, such as newlib, libstdc++ or libgcj.

That said, I'm not sure it should be used for libstdc++, since there's
no reason to use g++: we should use gcc instead, even if we perform
C++ link tests. Ditto for libjava, I suppose, but I realize it would
be far trickier to get libjava to link C programs :-)

Still, I think AC_NO_EXECUTABLES may affect all linking whatsoever,
not only that of the language in effect at the point it appears, which
does indeed make it useless for anything other that newlib. But, for
newlib, preventing link tests *is* the right thing to do, and I
contend that it's the right thing to do for any language affected by
the AC_NO_EXECUTABLES declaration.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
Geoff Keating
2002-12-10 04:59:01 UTC
Permalink
Post by Alexandre Oliva
I don't get it. Why does being able to link have anything to do with
being native? Being able to *run* tests has to do with being native,
but that's not the point, and autoconf already avoids running tests
when cross-building. But being able to link has to do with whether
the libraries that the compiler links in by default are present or
not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests
while building a library that the compiler driver would attempt to link
in by default, such as newlib, libstdc++ or libgcj.
Aah, I see. No, that's not the purpose of AC_NO_EXECUTABLES, or at
least it's not what GCC wants out of it. Some platforms can't link
anything at all without special care. For instance, you might need to
know what board you plan to run the executable on and pass an
appropriate flag (or supply an appropriate crt0 by hand). For another
example, vxworks can't and doesn't link anything, the final link takes
place at runtime on the board, "executables" are created using 'ld
-r', and you can refer to any symbols you like in the hope that
they'll be available later.

It's assumed that in a native case, this sort of thing won't happen,
thus the existing behaviour. Maybe instead you could perform a
configure-time test to see if the platform can link anything at all
(and will fail to link with an obviously bogus symbol), and then base
the decision of whether to run link tests on that, instead of the
current approximation, but there'll still be some cases when linking
is not possible, and other cases (the majority) in which link tests
are possible and desirable.
--
- Geoffrey Keating <***@geoffk.org>
Alexandre Oliva
2002-12-10 05:52:25 UTC
Permalink
Post by Geoff Keating
Post by Alexandre Oliva
I don't get it. Why does being able to link have anything to do with
being native? Being able to *run* tests has to do with being native,
but that's not the point, and autoconf already avoids running tests
when cross-building. But being able to link has to do with whether
the libraries that the compiler links in by default are present or
not. That's the purpose of AC_NO_EXECUTABLES: to disable link tests
while building a library that the compiler driver would attempt to link
in by default, such as newlib, libstdc++ or libgcj.
Aah, I see. No, that's not the purpose of AC_NO_EXECUTABLES, or at
least it's not what GCC wants out of it. Some platforms can't link
anything at all without special care. For instance, you might need to
know what board you plan to run the executable on and pass an
appropriate flag (or supply an appropriate crt0 by hand). For another
example, vxworks can't and doesn't link anything, the final link takes
place at runtime on the board, "executables" are created using 'ld
-r', and you can refer to any symbols you like in the hope that
they'll be available later.
I see. Oh, well... I was missing this bit of info when I designed
AC_NO_EXECUTABLES :-( My apologies...
Post by Geoff Keating
It's assumed that in a native case, this sort of thing won't happen,
thus the existing behaviour. Maybe instead you could perform a
configure-time test to see if the platform can link anything at all
(and will fail to link with an obviously bogus symbol), and then base
the decision of whether to run link tests on that, instead of the
current approximation, but there'll still be some cases when linking
is not possible, and other cases (the majority) in which link tests
are possible and desirable.
I think we'll be better served by declarative macros such as
AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated
sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail
out if it fails, but rather it sets a variable indicating the result
of the test, such that we could base our decision on whether to
perform additional link tests on this variable. Does it sound like
this would work?

Do we actually need AC_*_LINK_MAY_FAIL, or would a single
AC_LINK_MAY_FAIL macro be sufficient for libstdc++ and libgcj's needs?


Or perhaps we could make do with a configure argument that would tell
autoconf it's ok if the initial link test fails. It could even
short-circuit all other configure link tests, such that one might be
able to configure a package containing link tests for a system that
doesn't really support linking. The reason to not have this behavior
enabled by default is that we do want to detect situations when the
compiler is broken (the number of bogus reports caused by them used to
be huge when we didn't do it), but if a standard configure argument
disables the test, I think we're kind of ok.

Thoughts?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
Ian Lance Taylor
2002-12-10 06:17:28 UTC
Permalink
Post by Alexandre Oliva
I think we'll be better served by declarative macros such as
AC_{CC,CXX,...}_LINK_MAY_FAIL, that modify the autoconf-generated
sanity link test for AC_PROG_{CC,CXX,...} such that it does not bail
out if it fails, but rather it sets a variable indicating the result
of the test, such that we could base our decision on whether to
perform additional link tests on this variable. Does it sound like
this would work?
This approach sounds weird to me. The basic problem is that
AC_PROG_CC does the wrong thing for libstdc++ and a few other
configure scripts--namely, it executes the test of whether the
compiler works. It seems to me that AC_PROG_CC should call some
helper macros--perhaps just two--and that libstdc++ should call a
subset of those helper macros--perhaps just one.

Adding macros which change the behaviour of other macros seems
confusing. I don't see the advantage of that at all.

Ian
Tom Tromey
2002-12-08 19:58:17 UTC
Permalink
But, (2) it causes autoconf to barf if an AC_TRY_LINK test appears
anywhere in the script being generated.
Alexandre> Please tell me why (2) doesn't make sense.

Alexandre> If AC_PROG_CC_WORKS can't even link a do-nothing program,
Alexandre> how would you expect to get any useful results from
Alexandre> AC_TRY_LINK?

The autoconf code in question completely disables AC_LINK_IFELSE.
However, we know we can successfully do link tests when building
natively. And, at least in libgcj's case, this knowledge is important
because we use it to make libgcj more functional when built native.

FYI I sent a patch to the autoconf list.

Tom
Joern Rennecke
2002-12-05 22:39:22 UTC
Permalink
Post by Alan Modra
It seems that the major impact of configuring parts of a tree using
different autoconf versions will be on people using
--enable-maintainer-mode, so another solution might be to extend
--enable-maintainer-mode to accept a list of directories. I suspect
most developers will only want --enable-maintainer-mode in the
particular area they work on.
Unfortunately, for CPU port maintainers the area they work on is a
cross-section of gcc, newlib, binutils and gdb.
--
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658
Loading...