bug#26471: Automake 1.15 generates a recheck target that depends on all, breaking parallel builds

[Mathieu Lirzin]

Hi Seth,

Mathieu Lirzin  writes:

> Seth Fowler  writes:
>
>> I recently ran into what appears to be a bug in automake and I thought it 
>> would be a good idea to let you know.
>>
>> We had noticed that running “make recheck -j8” if some source files
>> were dirty would cause random build failures. The symptom was that the
>> same file was getting built more than once by different make
>> processes, which led to the resulting objects being corrupted. We’d
>> see messages like this:
>>
>> libtool:   error: ‘foo.lo’ is not a valid libtool object
>>
>> I dug into this a little and the root cause of the problem seems to be
>> that unlike the other top-level targets generated by automake (check,
>> install, etc.), recheck depends on “all” instead of “all-am”. “all”
>> doesn’t declare very many dependencies - it just launches a new copy
>> of make that builds “all-am”. Because recheck also depends on other
>> targets (e.g. everything in check_PROGRAMS) which might depend on some
>> of the same things as “all-am”, in a parallel build the original make
>> process and the make process spawned by “all” can end up attempting to
>> build the same targets.
>>
>> I fixed this for our project by copying the generated recheck rule
>> into our Makefile.am and replacing “all” with “all-am”. After doing
>> this, I could no longer reproduce the problem with “make recheck -j8”.
>>
>> It seems like that change should be made in automake itself. Or maybe I just 
>> missed something - I’m far from an automake guru. =)
>
> Seems like a bug.

Any news?  Would be great if you could provide a way to reproduce this
issue.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#25335: automake - dejagnu RUNTESTDEFAULTFLAGS overrides AM_RUNTESTFLAGS

[Mathieu Lirzin]

Mathieu Lirzin  writes:

> Carnë Draug  writes:
>
>> There are 3 variables used by automake when calling dejagnu's
>> runtest:
>>
>>   $RUNTESTDEFAULTFLAGS - default from automake
>>   $AM_RUNTESTFLAGS - set by package developer
>>   $RUNTESTFLAGS - for user configuration
>>
>> However, AM_RUNTESTFLAGS is used first and is therefore overwritten
>> by RUNTESTDEFAULTFLAGS.  My use case is that I am not using recursive
>> make and therefore want to set dejagnu's srcdir to the testsuite
>> directory.  But RUNTESTDEFAULTFLAGS then sets it to $srcdir. Here's
>> the lines causing my issue:
>>
>> RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
>> [...]
>> if $(RUNTEST) $(AM_RUNTESTFLAGS) $(RUNTESTDEFAULTFLAGS)
>> $(RUNTESTFLAGS); \
>> [...]
>>
>> A possible fix is to swap their order (simple patch attached).
>
> It seems like the right thing to do.  This has been fixed by commit
> 3126fa4c6b69c043e20af9381563069c0f2a0ba0
>
>> Another issue I am having with this is that the recipe to create the
>> site.exp file, also built by automake, sets dejagnu's srcdir to the
>> Makefile $srcdir again.  I am unsure how best to fix that (I guess a
>> maintainer variable).
>
> I am not sure to understand the issue correctly.  Can you try to explain
> it again?  I have no experience with DejaGNU, so don't hesitate to be
> explicit.

I am closing this since the main issue described was the order of
options.

Feel free to open a new bug if you want to report something about how
$(srcdir) is handled.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29638: Same five tests fail with 1.15 on RHEL 7.4

[Mathieu Lirzin]

Hello,

Mathieu Lirzin  writes:

> Dennis Clarke  writes:
>
>> The five failed tests are :
>>
>> FAIL: t/aclocal.sh
>> FAIL: t/automake-cmdline.tap 4 - list of options terminated by '--' (stderr)
>> FAIL: t/automake-cmdline.tap 17 - unambiguous incomplete long option
>> FAIL: t/maken3.sh
>> FAIL: t/maken3-w.sh
>
> My impression is that those failing tests are checking the edge cases
> of Getopt::Long which is system dependent and not the functional
> behavior of Automake.  As a consequence it seems reasonable to narrow
> the tests to more conservative Getopt::Long behaviors.

Here is a patch that should fix this issue.

>From 83d5d37bc8f0adb0e20a6fe7ab68029d2479dd32 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Thu, 18 Jan 2018 11:19:13 +0100
Subject: [PATCH] tests: Don't check 'Getopt::Long' corner cases

Depending on the installed 'Getopt::Long' perl module, command-line
handling may vary a bit.  As a consequence we prefer not to check
command-line corners cases.  This change fixes automake bug#29638.

* t/aclocal.sh (am_create_testdir): Don't expect "--versi" to be
interpreted as "--version".
* t/automake-cmdline.tap: Don't expect "--vers" to be interpreted as
"--version" and things after "--" to be interpreted as file arguments.
(do_check): Display the actual command output.
* t/maken3.sh (check_targets): "--force" is not a documented option, so
don't use it.
---
 t/aclocal.sh   |  2 --
 t/automake-cmdline.tap | 13 ++---
 t/maken3.sh|  2 +-
 3 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/t/aclocal.sh b/t/aclocal.sh
index 8cc8d5cc3..008493d5d 100644
--- a/t/aclocal.sh
+++ b/t/aclocal.sh
@@ -58,6 +58,4 @@ cat stderr >&2
 grep 'unrecognized option.*--ver' stderr
 grep '[Tt]ry.*--help.*for more information' stderr
 
-$ACLOCAL --versi
-
 :
diff --git a/t/automake-cmdline.tap b/t/automake-cmdline.tap
index c4441efe6..306231faa 100644
--- a/t/automake-cmdline.tap
+++ b/t/automake-cmdline.tap
@@ -18,7 +18,7 @@
 
 . test-init.sh
 
-plan_ 17
+plan_ 14
 
 # Usage: bad_cmdline DESCRIPTION REGEX-FOR-STDERR [ARGS-FOR-AUTOMAKE...]
 do_check ()
@@ -28,18 +28,11 @@ do_check ()
   regex=$1; shift
   AUTOMAKE_fails -d "$desc (run)" -- "$@"
   command_ok_ "$desc (stderr)" grep "$regex" stderr
+  cat stderr
 }
 
 do_check 'invalid long option' 'unrecognized option.*--voo' --voo
 
-# Older perl has a buggy Getopt::Long which makes this fail.
-if $PERL -e 'require 5.8.2;'; then
-  do_check "list of options terminated by '--'" \
-   'input file.*--voo' -- --voo
-else
-  skip_row_ 2 -r "older perl with buggy Getopt::Long"
-fi
-
 do_check "empty argument" \
  'empty argument' ''
 
@@ -58,6 +51,4 @@ do_check "'--help' as option argument" \
 do_check "ambiguous incomplete option" \
  'unrecognized option.*--ver' --ver
 
-command_ok_ "unambiguous incomplete long option" $AUTOMAKE --vers
-
 :
diff --git a/t/maken3.sh b/t/maken3.sh
index c37743cb7..8fe1d3269 100644
--- a/t/maken3.sh
+++ b/t/maken3.sh
@@ -181,7 +181,7 @@ check_targets || exit 1
 # TODO: add BUILT_SOURCES to sub2, fix fallout.
 sed 's/##//' < Makefile.am > t
 mv -f t Makefile.am
-$AUTOMAKE -Wno-override --force Makefile
+$AUTOMAKE -Wno-override Makefile
 ./configure
 check_targets || exit 1
 
-- 
2.15.1


Can you confirm this works on your system?

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#28967: How can I resolve this

[Eric Blake]

On 10/24/2017 06:36 AM, Sostom M N wrote:
> I am trying to run autoreconf , and this is what i get:
> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of
> AM_PATH_LOG4C

Most likely, log4c.m4 defines AM_PATH_LOG4C incorrectly, with
insufficient quoting (by the way, the AM_ namespace is reserved for
automake, but log4c.m4 doesn't belong to automake, so the macro should
be using a different name in the first place), and that initial error
then causes knock-on effects...

> /usr/share/aclocal/log4c.m4:7:   run info Automake 'Extending aclocal'
> /usr/share/aclocal/log4c.m4:7:   or see
> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of
> AM_PATH_LOG4C
> /usr/share/aclocal/log4c.m4:7:   run info Automake 'Extending aclocal'
> /usr/share/aclocal/log4c.m4:7:   or see
> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
> automake: error: global options already processed
> automake: Please contact .
>  at /usr/share/automake-1.15/Automake/Channels.pm line 662,  line 105.
> Automake::Channels::msg("automake", "", "global options already processed")

that confuse automake itself.  But we'd have to see the contents of
log4c.m4 to know for sure.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#28967: How can I resolve this

[Mathieu Lirzin]

Hello,

Mathieu Lirzin  writes:

> Sostom M N  writes:
>
>> I am trying to run autoreconf , and this is what i get:
>> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of 
>> AM_PATH_LOG4C
>> /usr/share/aclocal/log4c.m4:7: run info Automake 'Extending aclocal'
>> /usr/share/aclocal/log4c.m4:7: or see 
>> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
>> /usr/share/aclocal/log4c.m4:7: warning: underquoted definition of 
>> AM_PATH_LOG4C
>> /usr/share/aclocal/log4c.m4:7: run info Automake 'Extending aclocal'
>> /usr/share/aclocal/log4c.m4:7: or see 
>> http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
>> automake: error: global options already processed
>> automake: Please contact .
>> at /usr/share/automake-1.15/Automake/Channels.pm line 662,  line 105.
>> Automake::Channels::msg("automake", "", "global options already processed") 
>> called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212
>> Automake::ChannelDefs::prog_error("global options already processed") called 
>> at /usr/share/automake-1.15/Automake/Options.pm line 421
>> Automake::Options::process_global_option_list(HASH(0x2f920b0)) called at 
>> /usr/bin/automake line 5337
>> Automake::scan_autoconf_traces("configure.ac") called at /usr/bin/automake 
>> line 5437
>> Automake::scan_autoconf_files() called at /usr/bin/automake line 8259
>> autoreconf: automake failed with exit status: 29
>
> I would need more context.  Could you give me some instructions to
> reproduce this bug?

Any news?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37