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

Message received at 19418 <at> debbugs.gnu.org:

Received: (at 19418) by debbugs.gnu.org; 21 Feb 2022 04:03:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 20 23:03:48 2022
Received: from localhost ([127.0.0.1]:34416 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLzvQ-0000sC-JE
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 23:03:48 -0500
Received: from woodpecker.gentoo.org ([140.211.166.183]:40130
 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <vapier@HIDDEN>) id 1nLzvP-0000rz-7L
 for 19418 <at> debbugs.gnu.org; Sun, 20 Feb 2022 23:03:47 -0500
Received: by smtp.gentoo.org (Postfix, from userid 559)
 id 794B9343420; Mon, 21 Feb 2022 04:03:41 +0000 (UTC)
From: Mike Frysinger <vapier@HIDDEN>
To: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>
Subject: Re: AC_CONFIG_FILES / stamp-h? problem
Message-Id: <20220221040341.794B9343420@HIDDEN>
Date: Mon, 21 Feb 2022 04:03:41 +0000 (UTC)
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 19418
Cc: 19418 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

On Sat, 20 Dec 2014 15:48:49 +0000, Jeff Squyres (jsquyres) wrote:
> 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 our m4 code.

it's been ... a while.  have you managed to track this down yourself ?
or is this issue still plaguing the project ?
-mike

Message received at submit <at> debbugs.gnu.org:

Received: (at submit) by debbugs.gnu.org; 20 Dec 2014 15:49:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 20 10:49:16 2014
Received: from localhost ([127.0.0.1]:53080 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Y2MHL-0001Jm-8I
	for submit <at> debbugs.gnu.org; Sat, 20 Dec 2014 10:49:15 -0500
Received: from eggs.gnu.org ([208.118.235.92]:38724)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MHG-0001Jb-HN
 for submit <at> debbugs.gnu.org; Sat, 20 Dec 2014 10:49:12 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MHA-0004Rq-3G
 for submit <at> debbugs.gnu.org; Sat, 20 Dec 2014 10:49:10 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:43994)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <jsquyres@HIDDEN>) id 1Y2MHA-0004Rm-0Q
 for submit <at> debbugs.gnu.org; Sat, 20 Dec 2014 10:49:04 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40420)
 by lists.gnu.org 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 eggs.gnu.org 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 rcdn-iport-9.cisco.com ([173.37.86.80]:2654)
 by eggs.gnu.org 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;
 d=cisco.com; i=@cisco.com; l=5133; q=dns/txt; s=iport;
 t=1419090532; x=1420300132; h=from:to:subject:date:message-id:
 content-transfer-encoding:mime-version;
 bh=pGvIqVf1NvJdk7ZaJhxVrYumofd1uRtvg2jscsd7bpk=;
 b=hMEtAWjKo31WyGfRg6jEc4OOJmmneLYGDQYWK2ep/FeZGXgfKCRMpLCm
 6RjAtKTETFdVPC5ZwwGIB0elFIkuqEdx636pS99/aYwc1ZdeaLteNdSIF
 j99zZ5W7qgRWySQZ11WHJHRP/L1QeUclv0MAABCaB3AGHIOXVy4BFTTPY 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlYFAE2ZlVStJA2N/2dsb2JhbABbgwZSWATGKoVwAoERFgEBAQEBfYQOAQQ6UQEqFEImAQQTCIgkDapwpSABAQEHAQEBAR6PQTqDFIETBYw4gVeDPoF/gUGDAQ0jiCaELoM5IoNub4FFfgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="378478704"
Received: from alln-core-8.cisco.com ([173.36.13.141])
 by rcdn-iport-9.cisco.com with ESMTP; 20 Dec 2014 15:48:50 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81])
 by alln-core-8.cisco.com (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 xmb-rcd-x01.cisco.com ([169.254.1.21]) by xhc-rcd-x07.cisco.com
 ([173.37.183.81]) 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-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.133.233]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-detected-operating-system: by eggs.gnu.org: 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> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

Greetings.=0A=
=0A=
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=
=0A=
Short version=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
=0A=
The nightly "make distcheck" failed last night in the Open MPI project (www=
.open-mpi.org) due to several stamp-h? files being left in the build tree.=
=0A=
=0A=
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 Makefile.in. 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=
=0A=
Is this a known issue?  Or is there a common user/application error that ca=
n cause this kind of behavior?=0A=
=0A=
This behavior occurs with AC 2.69, AM 1.14.1, and LT 2.4.2.=0A=
=0A=
More detail=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
=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=
=0A=
Let me give some specifics.  In a clean Open MPI git checkout:=0A=
=0A=
1. run "autoreconf -ivf"=0A=
2. run "./configure --prefix=3D/blah"=0A=
3. run "find . -name stamp-h\?"=0A=
=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=
=0A=
-----=0A=
./opal/include/stamp-h1=0A=
./ompi/include/stamp-h2=0A=
./oshmem/include/stamp-h3=0A=
./opal/mca/hwloc/hwloc191/hwloc/include/private/autogen/stamp-h4=0A=
./opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/stamp-h5=0A=
./opal/mca/common/libfabric/libfabric/stamp-h6=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=
-----=0A=
=0A=
The first stamp-h1 - stamp-h6 files are generated by Open MPI's main config=
ure script.=0A=
=0A=
Indeed, looking at the main config.status, you can see that $config_headers=
 agrees with this ordering:=0A=
=0A=
-----=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=
on/libfabric/libfabric/config.h"=0A=
-----=0A=
=0A=
The problem is in Open MPI's top-level Makefile.in (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=
.=0A=
=0A=
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=
=0A=
-----=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=
    opal/mca/hwloc/hwloc191/hwloc/include/hwloc/autogen/stamp-h6=0A=
-----=0A=
=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=
=0A=
*** Note that the libfabric/config.h is the newly-added=0A=
    AC_CONFIG_HEADERS file.=0A=
=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=
s.=0A=
=0A=
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. =
 :-(=0A=
=0A=
So before I try to recreate this in a small example even further, let me as=
k two questions:=0A=
=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=
=0A=
Thanks for your time.=0A=
=0A=
--=0A=
Jeff Squyres=0A=
jsquyres@HIDDEN=0A=
For corporate legal information go to: http://www.cisco.com/web/about/doing=
_business/legal/cri/=