Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).

Dave Korn
Tue Dec 9 18:12:00 GMT 2008

    Hi gang (and Chuck in particular!)

  I've been having problems with the latest update to autoconf2.5 (2.63-1).
The problem can be made to reliably appear and disappear by rolling my install
forwards and back (to 2.61-1).

  It arises in generating the config sections of the libtool script, which
I've seen when reconfiguring gcc.  Specifically, I cd into the libjava/ subdir
of the gcc-4.3.2 tarball, run "autoconf -I .." (the libtool m4 files all live
in the toplevel src dir), and compare the newly generated configure file to
the original.  (I don't know if it's something to do with the way in which GCC
implements libtool.  I tried reconfiguring binutils but it's got a check in
and is very precise about wanting autoconf-2.59 and not 2.61 or 2.63.)

  There are of course tons of minor changes, but the big difference is in the
section of the configure script that writes the local libtool script.  There
is a section setting global configuration variables at the start of libtool,
wrapped in "### [BEGIN|END] LIBTOOL CONFIG", and at the end of the script are
various per-language-tag configuration settings wrapped similarly in

  In the original configure script and in the 2.61-generated version, these
sections contain dozens of definitions.  In the 2.61-generated version, these
sections are almost empty: the global libtool config section contains a single
definition, pic_mode, which is redundantly repeated twice, and the per-tag
sections each contain only a single definition of pic_mode (setting it from
the language specific version).

  I started debugging it a bit.  I have a log file containing three million
lines of m4 trace output.  I decided to take a quick look at what happened to
the definition of macro_version, which is usually one of the first things in
the config sections; it originates from LTVERSION_VERSION in ltversion.m4,
(see trace #1) and is invoked by AC_REQUIRE from LT_INIT (trace #2).

  In the trace file, I can see LTVERSION_VERSION being AC_DEFUN'd, then later
being AC_REQUIRE'd and getting expanded; I can see it calling _LT_DECL for
macro_version and see lt_dict_add_subkey being invoked to add macro_version
into lt_decl_dict, but it looks for some reason as if the value which was
assigned ('2.1a') isn't being added into the dictionary with it? (trace #3)

  Later, at output generation time, I see _AC_OUTPUT_MAIN_LOOP calling
_LT_LIBTOOL_TAGS, which iterates through lt_decl_varnames.  I see that
macro_version is in lt_decl_varnames, but when its turn comes up it fails to
retrieve anything of interest (trace #4), which I think is down to no value
having been attached to the variable when it was entered in the dictionary.

  I don't speak M4, and anyway this is just a distraction from the main job
I was trying to do at the time, so this is as far as I've looked at it.  I've
kept the autom4te.cache dirs and trace logs around, in case they'll be of any

[Well, I guess I'm back.  I have an email backlog to catch up with, feel free
to ping me off-list with links to posts in the archives I need to respond to.]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace1.log
Type: text/x-log
Size: 280 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace2.log
Type: text/x-log
Size: 10162 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace3.log
Type: text/x-log
Size: 17788 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace4.log
Type: text/x-log
Size: 11381 bytes
Desc: not available
URL: <>
-------------- next part --------------
Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list