GNU bug report logs - #16714
make check failures when ACLOCAL=aclocal is in environment

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16714 in the body.
You can then email your comments to 16714 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rachel Mant <rachel <at> rachelmant.com>
To: bug-automake <at> gnu.org
Subject: make check failures
Date: Mon, 10 Feb 2014 11:17:10 +0000

[Message part 1 (text/plain, inline)]

Hello,
    Attached is my test-log for automake 1.14.1 which sports an 
alarming number of failures despite having upgraded my system's m4 and 
autoconf just fine to their newest versions.

-- 
Kind regards,
And Best wishes,
Rachel Mant.

[Message part 2 (text/html, inline)]

[test-suite.log (text/plain, attachment)]

Message #8 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Rachel Mant <rachel <at> rachelmant.com>
Cc: 16714 <at> debbugs.gnu.org,
 GNU bug tracker automated control server <control <at> debbugs.gnu.org>
Subject: Re: bug#16714: make check failures
Date: Mon, 21 Apr 2014 11:21:08 +0100

tags 16714 + moreinfo
severity 16714 + minor
stop

On 02/10/2014 11:17 AM, Rachel Mant wrote:
> Hello,
>    Attached is my test-log for automake 1.14.1 which sports an alarming
>    number of failures despite having upgraded my system's m4 and
>    autoconf just fine to their newest versions.
> 
It seems something went horribly wrong with your build.  Can you
reproduce the issue in a clean build?  If yes, can you describe
the exact step you took to get such a build?

Thanks,
  Stefano

Message #15 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Rachel Mant <rachel <at> rachelmant.com>
To: 16714 <at> debbugs.gnu.org
Subject: Re: bug#16714: make check failures
Date: Mon, 21 Apr 2014 11:43:57 +0100

[Message part 1 (text/plain, inline)]

On 21/04/14 11:21, Stefano Lattarini wrote:
> tags 16714 + moreinfo
> severity 16714 + minor
> stop
>
> On 02/10/2014 11:17 AM, Rachel Mant wrote:
>> Hello,
>>     Attached is my test-log for automake 1.14.1 which sports an alarming
>>     number of failures despite having upgraded my system's m4 and
>>     autoconf just fine to their newest versions.
>>
> It seems something went horribly wrong with your build.  Can you
> reproduce the issue in a clean build?  If yes, can you describe
> the exact step you took to get such a build?
>
> Thanks,
>    Stefano
>
Hi Stefano,
    I'd literally run this command sequence inside the sources folder:

    CC="gcc -m64" CFLAGS="-O2" ./configure --prefix=/usr
    make && make check

    This was having just literally downloaded automake from the Kent 
mirror, and decompressed it.
    the build itself went just fine, but as you can see, make check 
threw fits.

-- 
Kind regards,
And Best wishes,
Rachel Mant.

[Message part 2 (text/html, inline)]

Message #18 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Rachel Mant <rachel <at> rachelmant.com>, 16714 <at> debbugs.gnu.org
Subject: Re: bug#16714: make check failures
Date: Mon, 21 Apr 2014 14:44:12 +0100

On 04/21/2014 11:43 AM, Rachel Mant wrote:
> On 21/04/14 11:21, Stefano Lattarini wrote:
>> tags 16714 + moreinfo
>> severity 16714 + minor
>> stop
>>
>> On 02/10/2014 11:17 AM, Rachel Mant wrote:
>>> Hello,
>>>     Attached is my test-log for automake 1.14.1 which sports an alarming
>>>     number of failures despite having upgraded my system's m4 and
>>>     autoconf just fine to their newest versions.
>>>
>> It seems something went horribly wrong with your build.  Can you
>> reproduce the issue in a clean build?  If yes, can you describe
>> the exact step you took to get such a build?
>>
>> Thanks,
>>    Stefano
>>
> Hi Stefano,
>     I'd literally run this command sequence inside the sources folder:
> 
>     CC="gcc -m64" CFLAGS="-O2" ./configure --prefix=/usr
>     make && make check
> 
>     This was having just literally downloaded automake from the Kent mirror, and decompressed it.
>     the build itself went just fine, but as you can see, make check threw fits.
> 
Hmm, a better look in your test-suite.log files revealed this clearly
broken definitions (not the doubled quotation):

  ACLOCAL='"/build/automake-1.14.1/t/wrap/aclocal-1.14"'
  AUTOMAKE='"/build/automake-1.14.1/t/wrap/automake-1.14"'

Can you report the output of an 'env' invocation?  You seem to have
a borked environment...

Message #21 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Rachel Mant <rachel <at> rachelmant.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 16714 <at> debbugs.gnu.org
Subject: Re: bug#16714: make check failures
Date: Mon, 21 Apr 2014 14:49:46 +0100

[Message part 1 (text/plain, inline)]

On 21/04/14 14:44, Stefano Lattarini wrote:
> On 04/21/2014 11:43 AM, Rachel Mant wrote:
>> On 21/04/14 11:21, Stefano Lattarini wrote:
>>> tags 16714 + moreinfo
>>> severity 16714 + minor
>>> stop
>>>
>>> On 02/10/2014 11:17 AM, Rachel Mant wrote:
>>>> Hello,
>>>>      Attached is my test-log for automake 1.14.1 which sports an alarming
>>>>      number of failures despite having upgraded my system's m4 and
>>>>      autoconf just fine to their newest versions.
>>>>
>>> It seems something went horribly wrong with your build.  Can you
>>> reproduce the issue in a clean build?  If yes, can you describe
>>> the exact step you took to get such a build?
>>>
>>> Thanks,
>>>     Stefano
>>>
>> Hi Stefano,
>>      I'd literally run this command sequence inside the sources folder:
>>
>>      CC="gcc -m64" CFLAGS="-O2" ./configure --prefix=/usr
>>      make&&  make check
>>
>>      This was having just literally downloaded automake from the Kent mirror, and decompressed it.
>>      the build itself went just fine, but as you can see, make check threw fits.
>>
> Hmm, a better look in your test-suite.log files revealed this clearly
> broken definitions (not the doubled quotation):
>
>    ACLOCAL='"/build/automake-1.14.1/t/wrap/aclocal-1.14"'
>    AUTOMAKE='"/build/automake-1.14.1/t/wrap/automake-1.14"'
>
> Can you report the output of an 'env' invocation?  You seem to have
> a borked environment...
>
I have no definitions for either of those in my env block. Attached is a 
sanitised version (removal of what user I'm logged in as and other 
sensitive info).
I have to note that this is the only thing I've ever `make check`'d 
which has failed. I'm not running a standard distro as what I'm running 
is derived off of CLFS.

-- 
Kind regards,
And Best wishes,
Rachel Mant.

[Message part 2 (text/html, inline)]

[env (text/plain, attachment)]

Message #24 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Rachel Mant <rachel <at> rachelmant.com>
Cc: 16714 <at> debbugs.gnu.org, Stefano Lattarini <stefano.lattarini <at> gmail.com>
Subject: Re: bug#16714: make check failures
Date: Tue, 18 Jan 2022 06:02:17 +0000 (UTC)

retitle 16714 make check failures when ACLOCAL=aclocal is in environment
tag 16714 = confirmed
thankyou

looks like your redundant $ACLOCAL in the environment is breaking things.
there should be no reason to have that:
  ACLOCAL=aclocal -I /usr/share/aclocal

that said, we shouldn't be blowing up with $ACLOCAL is set in the env.
i can repro with that pretty easily under current git:
  ./configure
  make
  make check
  <no failures>
  ACLOCAL=aclocal make check
  <lots of failures>

Message #27 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org, 16714 <at> debbugs.gnu.org
Subject: Re: bug#16714: make check failures
Date: Sat, 22 Jan 2022 18:58:57 -0700

      ACLOCAL=aclocal make check
      <lots of failures>

I guess our internal make check initialization should unset ACLOCAL if
it's set?  Maybe with a warning, since it might be expected. Is
something more needed? --thanks, karl.

Message #34 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 16714 <at> debbugs.gnu.org
Subject: [PATCH/committed] tests: fix quoting in eval
Date: Mon, 24 Jan 2022 00:59:28 -0500

We need to escape the quotes so eval sees them when expanding the
variable value, not when quoting the variable name itself.

* t/local.mk: Escape quotes to eval.
---
 t/local.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/local.mk b/t/local.mk
index b22f1ade93d7..31d43e86856e 100644
--- a/t/local.mk
+++ b/t/local.mk
@@ -51,7 +51,7 @@ AM_TESTS_ENVIRONMENT = \
     am_test_lib_sourced \
     test_lib_sourced \
   ; do \
-    eval test x"\$${$$v}" = x || unset $$v; \
+    eval test x\"\$${$$v}\" = x || unset $$v; \
   done;
 # We want warning messages and explanations for skipped tests to go to
 # the console if possible, so set up 'stderr_fileno_' properly.
-- 
2.34.1

Message #37 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 16714 <at> debbugs.gnu.org
Subject: [PATCH] tests: clear autotools env vars
Date: Mon, 24 Jan 2022 01:10:55 -0500

Fixes automake bug https://bugs.gnu.org/16714.

The testsuite will try and retain these env vars when recursively
running itself, but doesn't distinguish between vars coming from
the env where the tests were launched.  This breaks if the user
happens to `export ACLOCAL=alocal` before `make check`.

This gets a little more confusing in that the Makefile appears to
export these already:
ACLOCAL = ".../automake/pre-inst-env" aclocal-1.16

In reality, while those are set in the make execution environment,
they aren't exported into the process environment, so children
(i.e. shell processes in make rules) don't have them set.  That's
why tests work for most people today.

However, if the user has first exported "ACLOCAL" in the parent
make environment (regardless of value), then make's value will
reset the process environment, and then that will leak into the
children.  That's why we see errors that look like the makefile
env vars are leaking for these people.

At any rate, the fix is to update the test harness to clear these
vars that the test suite relies upon, especially the ones that are
also set in the Makefiles.  That includes AUTOUPDATE even though
it currently isn't used inside any of the tests.

* t/local.mk: Add ACLOCAL, AUTOCONF, AUTOHEADER, AUTOMAKE, and
AUTOUPDATE to the env unset list.
* t/ax/runtest.in: Likewise.
---
 t/ax/runtest.in | 5 +++++
 t/local.mk      | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/t/ax/runtest.in b/t/ax/runtest.in
index 499b852999e8..91a5afd5228a 100644
--- a/t/ax/runtest.in
+++ b/t/ax/runtest.in
@@ -45,6 +45,11 @@ export srcdir
 # test scripts, but not from the environment.
 # Keep this in sync with the 'Makefile.am:AM_TESTS_ENVIRONMENT'.
 for v in \
+  ACLOCAL \
+  AUTOCONF \
+  AUTOHEADER \
+  AUTOMAKE \
+  AUTOUPDATE \
   required \
   am_test_protocol \
   am_serial_tests \
diff --git a/t/local.mk b/t/local.mk
index 31d43e86856e..8a7cab3b232a 100644
--- a/t/local.mk
+++ b/t/local.mk
@@ -42,6 +42,11 @@ TESTS =
 # Keep this in sync with the similar list in ax/runtest.in.
 AM_TESTS_ENVIRONMENT = \
   for v in \
+    ACLOCAL \
+    AUTOCONF \
+    AUTOHEADER \
+    AUTOMAKE \
+    AUTOUPDATE \
     required \
     am_test_protocol \
     am_serial_tests \
-- 
2.34.1

Message #40 received at 16714 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: vapier <at> gentoo.org
Cc: 16714 <at> debbugs.gnu.org
Subject: Re: bug#16714: [PATCH] tests: clear autotools env vars
Date: Mon, 24 Jan 2022 19:03:46 -0700

    Subject: bug#16714: [PATCH] tests: clear autotools env vars

Looks good to me. Thanks.

Message #47 received at 16714-done <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 16714-done <at> debbugs.gnu.org
Subject: Re: bug#16714: [PATCH] tests: clear autotools env vars
Date: Tue, 25 Jan 2022 04:41:45 +0000 (UTC)

should be resolved for the next release, thanks

Previous Next

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