GNU bug report logs - #19418
AC_CONFIG_FILES / stamp-h? problem

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: automake; Reported by: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>; dated Sat, 20 Dec 2014 15:50:01 UTC; Maintainer for automake is bug-automake@HIDDEN.

Message received at submit <at>

Received: (at submit) by; 20 Dec 2014 15:49:16 +0000
From debbugs-submit-bounces <at> Sat Dec 20 10:49:16 2014
Received: from localhost ([]:53080
	by with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at>>)
	id 1Y2MHL-0001Jm-8I
	for submit <at>; Sat, 20 Dec 2014 10:49:15 -0500
Received: from ([]:38724)
 by with esmtp (Exim 4.80)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MHG-0001Jb-HN
 for submit <at>; Sat, 20 Dec 2014 10:49:12 -0500
Received: from Debian-exim by with spam-scanned (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MHA-0004Rq-3G
 for submit <at>; Sat, 20 Dec 2014 10:49:10 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from ([2001:4830:134:3::11]:43994)
 by with esmtp (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MHA-0004Rm-0Q
 for submit <at>; Sat, 20 Dec 2014 10:49:04 -0500
Received: from ([2001:4830:134:3::10]:40420)
 by with esmtp (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MH4-00089u-B4
 for bug-automake@HIDDEN; Sat, 20 Dec 2014 10:49:03 -0500
Received: from Debian-exim by with spam-scanned (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MGy-0004Qb-G4
 for bug-automake@HIDDEN; Sat, 20 Dec 2014 10:48:58 -0500
Received: from ([]:2654)
 by with esmtp (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MGy-0004QN-7n
 for bug-automake@HIDDEN; Sat, 20 Dec 2014 10:48:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5133; q=dns/txt; s=iport;
 t=1419090532; x=1420300132; h=from:to:subject:date:message-id:
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="378478704"
Received: from ([])
 by with ESMTP; 20 Dec 2014 15:48:50 +0000
Received: from ( [])
 by (8.14.5/8.14.5) with ESMTP id sBKFmnZC006613
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
 for <bug-automake@HIDDEN>; Sat, 20 Dec 2014 15:48:50 GMT
Received: from ([]) by
 ([]) with mapi id 14.03.0195.001;
 Sat, 20 Dec 2014 09:48:49 -0600
From: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>
To: "bug-automake@HIDDEN" <bug-automake@HIDDEN>
Subject: AC_CONFIG_FILES / stamp-h? problem
Thread-Topic: AC_CONFIG_FILES / stamp-h? problem
Thread-Index: AdAcbHJ+MYYPOBrgQ/+SrLOk1vAIbQ==
Date: Sat, 20 Dec 2014 15:48:49 +0000
Message-ID: <EF66BBEB19BADC41AC8CCF5F684F07FC56F6250A@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-detected-operating-system: by Genre and OS details not
X-detected-operating-system: by Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, 
 <mailto:debbugs-submit-request <at>>
List-Archive: <>
List-Post: <mailto:debbugs-submit <at>>
List-Help: <mailto:debbugs-submit-request <at>>
List-Subscribe: <>, 
 <mailto:debbugs-submit-request <at>>
Errors-To: debbugs-submit-bounces <at>
Sender: "Debbugs-submit" <debbugs-submit-bounces <at>>
X-Spam-Score: -4.0 (----)

I have found what appears to be a subtle bug in the Autotools, and I *think=
* it may be in Automake.  ...but I am not sure; it could also be a bug in o=
ur m4 code.=0A=
Short version=0A=
The nightly "make distcheck" failed last night in the Open MPI project (www= due to several stamp-h? files being left in the build tree.=
Close examination shows that the order of $config_headers in config.status =
-- and therefore the initial generation of stamp-h? files in the build tree=
 -- appears to differ from the numbering of stamp-h? files in the top-level=
 Automake-generated Hence, the "distclean-hdr" rule is attempt=
ing to remove different stamp-h? files than were created by config.status, =
ultimately resulting in "make distcheck" failing.=0A=
Is this a known issue?  Or is there a common user/application error that ca=
n cause this kind of behavior?=0A=
This behavior occurs with AC 2.69, AM 1.14.1, and LT 2.4.2.=0A=
More detail=0A=
There had been a commit earlier yesterday that added another AC_CONFIG_HEAD=
ERS file in the Open MPI configury.  This new file seemed to trigger this n=
ew behavior (i.e., "make distcheck" was not failing before last night).=0A=
Let me give some specifics.  In a clean Open MPI git checkout:=0A=
1. run "autoreconf -ivf"=0A=
2. run "./configure --prefix=3D/blah"=0A=
3. run "find . -name stamp-h\?"=0A=
Here's the stamp-h? files that I see -- note that the files marked by (*) a=
re generated by sub-configure scripts that are invoked by Open MPI's main c=
onfigure script; they're not important to this analysis, and are listed her=
e just for completeness:=0A=
(*) ./opal/libltdl/stamp-h1=0A=
(*) ./opal/mca/event/libevent2021/libevent/stamp-h1=0A=
(*) ./ompi/mca/io/romio/romio/adio/include/stamp-h1=0A=
(*) ./ompi/contrib/vt/vt/extlib/otf/stamp-h1=0A=
(*) ./ompi/contrib/vt/vt/stamp-h1=0A=
The first stamp-h1 - stamp-h6 files are generated by Open MPI's main config=
ure script.=0A=
Indeed, looking at the main config.status, you can see that $config_headers=
 agrees with this ordering:=0A=
$ egrep '^config_headers=3D' config.status=0A=
config_headers=3D" opal/include/opal_config.h ompi/include/mpi.h oshmem/inc=
lude/shmem.h opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h=
 opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h opal/mca/comm=
The problem is in Open MPI's top-level (which was generated by =
Automake).  The stamp-h? rules and the "rm -f ..." that occurs in distclean=
-hdr appear to differ in stamp-h<DIGIT> ordering than that of config.status=
Both the stamp-h? rules and the distclean-hdr rule reflect the same orderin=
g, so I'll just show the "rm -f ..." that is in distclean-hdr for brevity (=
broken into multiple lines for readability):=0A=
-rm -f \=0A=
    opal/mca/common/libfabric/libfabric/config.h \=0A=
    opal/mca/common/libfabric/libfabric/stamp-h4 \=0A=
    opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/config.h \=0A=
    opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/stamp-h5 \=0A=
    opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/config.h \=0A=
Notice that the "libfabric" directory corresponds to stamp-h4, but the conf=
ig.status-generated stamp file for this directory is stamp-h6. The two hwlo=
c191 stamp files reflect similar mismatched ordering.=0A=
*** Note that the libfabric/config.h is the newly-added=0A=
This all leads "make distclean-hdr" to (attempting to) remove the wrong (an=
d non-existent) stamp files, and therefore "make distcheck" ultimately fail=
Unfortunately, the configury for Open MPI is *quite* complex; it spans many=
 .m4 files across many directories.  I've been trying to create a small rep=
roducer outside of the (very large) Open MPI source tree and have been unab=
le to find the magic set of circumstances to make the same behavior occur. =
So before I try to recreate this in a small example even further, let me as=
k two questions:=0A=
1. Is this a known problem?=0A=
2. Is there a common user-level mistake (i.e., somewhere in our configure/m=
4 code) that could cause this behavior to occur?=0A=
Thanks for your time.=0A=
Jeff Squyres=0A=
For corporate legal information go to:

Acknowledgement sent to "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-automake@HIDDEN. Full text available.
Report forwarded to bug-automake@HIDDEN:
bug#19418; Package automake. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.