GNU logs - #19418, boring messages

Message sent to bug-automake@HIDDEN:

Subject: bug#19418: AC_CONFIG_FILES / stamp-h? problem
Resent-From: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Sat, 20 Dec 2014 15:50:01 +0000
Resent-Message-ID: <handler.19418.B.14190905565075 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 19418 <at> debbugs.gnu.org
From: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>
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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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/=

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>
Subject: bug#19418: Acknowledgement (AC_CONFIG_FILES / stamp-h? problem)
Message-ID: <handler.19418.B.14190905565075.ack <at> debbugs.gnu.org>
References: <EF66BBEB19BADC41AC8CCF5F684F07FC56F6250A@HIDDEN>
X-Gnu-PR-Message: ack 19418
X-Gnu-PR-Package: automake
Reply-To: 19418 <at> debbugs.gnu.org
Date: Sat, 20 Dec 2014 15:50:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-automake@HIDDEN

If you wish to submit further information on this problem, please
send it to 19418 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
19418: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19418
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-automake@HIDDEN:

Subject: bug#19418: AC_CONFIG_FILES / stamp-h? problem
References: <EF66BBEB19BADC41AC8CCF5F684F07FC56F6250A@HIDDEN>
In-Reply-To: <EF66BBEB19BADC41AC8CCF5F684F07FC56F6250A@HIDDEN>
Resent-From: Mike Frysinger <vapier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-automake@HIDDEN
Resent-Date: Mon, 21 Feb 2022 04:04:01 +0000
Resent-Message-ID: <handler.19418.B19418.16454162283365 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Jeff Squyres (jsquyres)" <jsquyres@HIDDEN>
Cc: 19418 <at> debbugs.gnu.org
From: Mike Frysinger <vapier@HIDDEN>
Message-Id: <20220221040341.794B9343420@HIDDEN>
Date: Mon, 21 Feb 2022 04:03:41 +0000 (UTC)
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Last modified: Mon, 21 Feb 2022 04:15:02 UTC

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