Re: rhel8 test failure confirmation?
Note that 'config.h' is older (4 seconds) than './configure', which shouldn't be the case as it should get updated with new values. Indeed. That is the same sort of thing as I was observing with nodef. But what (at any level) could be causing that to happen? Files just aren't getting updated as they should be. I haven't yet tried older releases of automake to see if their tests succeed on the systems that are failing now. That's next on my list. Thanks for looking into it, Karl
Re: rhel8 test failure confirmation?
Bogdan , Fri Mar 03 2023 14:56:07 GMT+0100 (Central
European Standard Time)
Bogdan , Fri Mar 03 2023 11:21:25 GMT+0100 (Central
European Standard Time)
Karl Berry , Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux,
Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice if someone
could run a make check there (from automake dev).
git clone -q git://git.savannah.gnu.org/automake.git
cd automake
./bootstrap
./configure && make >
make -j8 VERBOSE=1 check keep_testdirs=yes >
(choose whatever -j value you like)
[...]
This, along with my observation (below), MAY actually point to
some issue with Autoconf. Old systems work, new don't.
I take that back (for now). See below.
[...]
When I run
make check TESTS='t/nodef.sh t/backcompat2.sh t/backcompat3.sh
t/get-sysconf.sh t/lex-depend.sh
t/remake-aclocal-version-mismatch.sh t/subdir-add2-pr46.sh
t/testsuite-summary-reference-log.sh'
I get failures in t/backcompat2.sh. Sometimes, like once-twice in
ten runs.
I've added a simple 'debug' in the form of the 'stat' command and:
--
[...]
--
Note that 'config.h' is older (4 seconds) than './configure',
which shouldn't be the case as it should get updated with new values.
What's funny, when I run just the failing test alone, it works 10
times in a row. A "Schroedinger bug" - when you try to observe, you
change the environment and the bug disappears :).
I'll try to do some more digging later.
[...]
Anyway, to the point: I did a simple change - un-define the value on
the "else" path. Diff attached (not pretty, because it's just for
testing).
Since the change, I've done 22 test runs of the same test set (the
one with 8 tests, not the single one which always passed) and saw
completely no failures.
If it works for everybody, then perhaps some _AM_UNSET_OPTION macro
should be created in options.m4, to keep the code nice, and that
committed to the main code instead of my patch.
If it works, there may be other places worth checking.
Never mind. The tests are failing again. Sorry for the noise.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
Re: if vs. ifdef in Makefile.am
On Friday 2023-03-03 13:14, ljh wrote: >Thanks for the hint. I did not know this before. > >Found it here, autoconf manual 16.3: > cd to the directory where you want the object files and executables to > go and run the configure script. configure automatically checks for > the source code in the directory that configure is in and in ... > This is known as a VPATH build. > >$ bash ../src/autogen.sh >autoreconf: 'configure.ac' or 'configure.in' is required >$ > >But `autoreconf -i` only runs in directory where configure.ac lives. It >generates a lot temporary files in the source directory. https://lists.gnu.org/archive/html/automake/2023-01/msg5.html
Re: rhel8 test failure confirmation?
Bogdan , Fri Mar 03 2023 11:21:25 GMT+0100 (Central
European Standard Time)
Karl Berry , Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux,
Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice if someone
could run a make check there (from automake dev).
git clone -q git://git.savannah.gnu.org/automake.git
cd automake
./bootstrap
./configure && make >
make -j8 VERBOSE=1 check keep_testdirs=yes >
(choose whatever -j value you like)
[...]
This, along with my observation (below), MAY actually point to some
issue with Autoconf. Old systems work, new don't.
I take that back (for now). See below.
[...]
When I run
make check TESTS='t/nodef.sh t/backcompat2.sh t/backcompat3.sh
t/get-sysconf.sh t/lex-depend.sh t/remake-aclocal-version-mismatch.sh
t/subdir-add2-pr46.sh t/testsuite-summary-reference-log.sh'
I get failures in t/backcompat2.sh. Sometimes, like once-twice in
ten runs.
I've added a simple 'debug' in the form of the 'stat' command and:
--
[...]
--
Note that 'config.h' is older (4 seconds) than './configure', which
shouldn't be the case as it should get updated with new values.
What's funny, when I run just the failing test alone, it works 10
times in a row. A "Schroedinger bug" - when you try to observe, you
change the environment and the bug disappears :).
I'll try to do some more digging later.
Done a bit more digging into how AM_INIT_AUTOMAKE works. No idea how
or if caching of M4 'defines' works, but from a programming point of
view, I see setting the [no-define] option conditionally:
m4_ifval([$3], [_AM_SET_OPTION([no-define])])dnl
and checking it unconditionally:
_AM_IF_OPTION([no-define]
and I ask myself: what if on the next run the value is still
(un)defined when it shouldn't be? It shouldn't be defined, because we
start with the empty value as the third parameter in the
t/backcompat2.sh test, but...
Anyway, to the point: I did a simple change - un-define the value on
the "else" path. Diff attached (not pretty, because it's just for
testing).
Since the change, I've done 22 test runs of the same test set (the
one with 8 tests, not the single one which always passed) and saw
completely no failures.
If it works for everybody, then perhaps some _AM_UNSET_OPTION macro
should be created in options.m4, to keep the code nice, and that
committed to the main code instead of my patch.
If it works, there may be other places worth checking.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
diff --git a/m4/init.m4 b/m4/init.m4
index 9b809ad5b..a79500695 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -62,7 +62,7 @@ dnl Distinguish between old-style and new-style calls.
m4_ifval([$2],
[AC_DIAGNOSE([obsolete],
[$0: two- and three-arguments forms are deprecated.])
-m4_ifval([$3], [_AM_SET_OPTION([no-define])])dnl
+m4_ifval([$3], [_AM_SET_OPTION([no-define])], [m4_ifdef(_AM_MANGLE_OPTION([no-define]), [m4_undefine(_AM_MANGLE_OPTION([no-define])])])dnl
AC_SUBST([PACKAGE], [$1])dnl
AC_SUBST([VERSION], [$2])],
[_AM_SET_OPTIONS([$1])dnl
Re: if vs. ifdef in Makefile.am
Hi, Thanks for the hint. I did not know this before. Found it here, autoconf manual 16.3: cd to the directory where you want the object files and executables to go and run the configure script. configure automatically checks for the source code in the directory that configure is in and in ... This is known as a VPATH build. $ bash ../src/autogen.sh autoreconf: 'configure.ac' or 'configure.in' is required $ But `autoreconf -i` only runs in directory where configure.ac lives. It generates a lot temporary files in the source directory. $ tree -a . ?? build ?? ?? config.h ?? ?? config.log ?? ?? config.status ?? ?? foo ?? ?? ?? .deps ?? ?? ?? ?? libfoo_la-foo.Plo ?? ?? ?? libfoo.la ?? ?? ?? libfoo_la-foo.lo ?? ?? ?? libfoo_la-foo.o ?? ?? ?? .libs ?? ?? ?? ?? libfoo.la - ../libfoo.la ?? ?? ?? ?? libfoo_la-foo.o ?? ?? ?? ?? libfoo.lai ?? ?? ?? ?? libfoo.so - libfoo.so.5.2.3 ?? ?? ?? ?? libfoo.so.5 - libfoo.so.5.2.3 ?? ?? ?? ?? libfoo.so.5.2.3 ?? ?? ?? Makefile ?? ?? libtool ?? ?? main ?? ?? ?? .deps ?? ?? ?? ?? main.Po ?? ?? ?? .libs ?? ?? ?? ?? main ?? ?? ?? main ?? ?? ?? main.o ?? ?? ?? Makefile ?? ?? Makefile ?? ?? stamp-h1 ?? src ?? aclocal.m4 ?? ar-lib ?? autogen.sh ?? autom4te.cache ?? ?? output.0 ?? ?? output.1 ?? ?? output.2 ?? ?? requests ?? ?? traces.0 ?? ?? traces.1 ?? ?? traces.2 ?? compile ?? config.guess ?? config.h.in ?? config.sub ?? configure ?? configure.ac ?? depcomp ?? foo ?? ?? foo.c ?? ?? foo.h ?? ?? Makefile.am ?? ?? Makefile.in ?? install-sh ?? ltmain.sh ?? m4 ?? ?? libtool.m4 ?? ?? lt~obsolete.m4 ?? ?? ltoptions.m4 ?? ?? ltsugar.m4 ?? ?? ltversion.m4 ?? main ?? ?? main.c ?? ?? Makefile.am ?? ?? Makefile.in ?? Makefile.am ?? Makefile.in ?? missing 12 directories, 56 files $ $ ./main/.libs/main main foo main: ../../src/main/main.c:18: main: Assertion `0' failed. $ $ ldd ./main/.libs/main linux-vdso.so.1 (0x7ffd6c1fe000) libasan.so.6 = /lib/x86_64-linux-gnu/libasan.so.6 (0x7f826b13) libfoo.so.5 = /home/ljh/Documents/hello_autotools/build/./main/.libs/../../foo/.libs/libfoo.so.5 (0x7f826b12b000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f826af56000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f826af5) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f826af2e000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f826adea000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f826adce000) /lib64/ld-linux-x86-64.so.2 (0x7f826bb18000) $
Re: rhel8 test failure confirmation?
Karl Berry , Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice if someone
could run a make check there (from automake dev).
git clone -q git://git.savannah.gnu.org/automake.git
cd automake
./bootstrap
./configure && make >
make -j8 VERBOSE=1 check keep_testdirs=yes >
(choose whatever -j value you like)
Confirmed here as well (OpenMandriva with Autoconf 2.71). Tested
Automake at the current 'master' and a little older branch.
Even in a pristine environment, on a different physical machines, I find
that a few tests fail, usually taken from the list below. Not always
the same tests fail, but I don't think it's directly related to
parallelism.
It's not. I run tests sequentially and also get failures. Randomly
in time, but always in the same test (and just one).
In the one I've looked into most, t/nodef.sh, it seems to be about disk
writes not taking effect. That test runs the usual autotool sequence
twice, both times writing to the same file named `output' and then
grepping it, e.g.:
grep 'DEFS.*-DVERSION=\\"UnIqUe' output && exit 1
If I put a sleep 1 between the two autotool invocations, it passes. If I
don't, it fails, because the second grep reads the `output' file written
by the first. Or so it seems. Which is crazy.
Certainly looks that way, but for me, it's more like
Autoconf/configure/config.status NOT updating the right files
(config.h in my case).
I could chalk it up to weird (extremely broken) hard disk behavior on
one machine, but not two different machines with completely dissimilar
hardware (including disks). It seems it must be in the os, in my case
Alma Linux:
$ grep ^VERSION= /etc/os-release
VERSION="8.7 (Stone Smilodon)"
(But I'd be very surprised if it is Alma-specific.)
All the tests pass fine on CentOS 7.
This, along with my observation (below), MAY actually point to some
issue with Autoconf. Old systems work, new don't.
Sigh. --thanks, karl.
Approximate lists of tests that "usually" fail:
FAIL: t/backcompat2.sh
FAIL: t/backcompat3.sh
FAIL: t/get-sysconf.sh
FAIL: t/lex-depend.sh
FAIL: t/nodef.sh
FAIL: t/remake-aclocal-version-mismatch.sh
FAIL: t/subdir-add2-pr46.sh
FAIL: t/testsuite-summary-reference-log.sh
When I run
make check TESTS='t/nodef.sh t/backcompat2.sh t/backcompat3.sh
t/get-sysconf.sh t/lex-depend.sh t/remake-aclocal-version-mismatch.sh
t/subdir-add2-pr46.sh t/testsuite-summary-reference-log.sh'
I get failures in t/backcompat2.sh. Sometimes, like once-twice in
ten runs.
I've added a simple 'debug' in the form of the 'stat' command and:
--
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating config.h
config.status: config.h is unchanged
+ cat config.h
/* config.h. Generated from config.h.in by configure. */
/* #undef PACKAGE */
/* #undef VERSION */
+ LC_ALL=C
+ stat ./configure
File: ./configure
Size: 106382 Blocks: 208IO Block: 4096 regular file
Device: 8,6 Inode: 6328331 Links: 1
Access: (0700/-rwx--) Uid: ( 1000/ bogdan) Gid: ( 1006/ bogdan)
Access: 2023-03-02 21:42:36.138654005 +0100
Modify: 2023-03-02 21:42:36.251653430 +0100
Change: 2023-03-02 21:42:36.252653424 +0100
Birth: 2023-03-02 21:42:36.138654005 +0100
+ LC_ALL=C
+ stat config.h
File: config.h
Size: 101 Blocks: 8 IO Block: 4096 regular file
Device: 8,6 Inode: 6328337 Links: 1
Access: (0600/-rw---) Uid: ( 1000/ bogdan) Gid: ( 1006/ bogdan)
Access: 2023-03-02 21:42:32.677671613 +0100
Modify: 2023-03-02 21:42:32.683671582 +0100
Change: 2023-03-02 21:42:32.693671531 +0100
Birth: 2023-03-02 21:42:32.677671613 +0100
+ grep '^ *# *define *PACKAGE *"pkgname" *$' config.h
+ am_exit_trap 1
--
Note that 'config.h' is older (4 seconds) than './configure', which
shouldn't be the case as it should get updated with new values.
What's funny, when I run just the failing test alone, it works 10
times in a row. A "Schroedinger bug" - when you try to observe, you
change the environment and the bug disappears :).
I'll try to do some more digging later.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
Re: if vs. ifdef in Makefile.am
On Friday 2023-03-03 11:13, ljh wrote: >ifdef is not wrong. But ifdef is not portable.
Re: if vs. ifdef in Makefile.am
ifdef is not wrong. In GCC, `-DFOO=1` means `-DFOO` -D name Predefine name as a macro, with definition 1. -D name=definition
Re: if vs. ifdef in Makefile.am
On Friday 2023-03-03 10:40, ljh wrote: >--disable-assert is 1/3 of the way and cd is the other 2/3.
Re: if vs. ifdef in Makefile.am
Hi, --disable-assert is 1/3 of the way
Re: if vs. ifdef in Makefile.am
On Friday 2023-03-03 09:36, ljh wrote: >Jacob Bachmeyer wrote: >>$ (mkdir test-build; cd ./test-build && ../src/configure --enable-assert ...) >> >>$ (mkdir release-build; cd ./release-build && ../src/configure >>--disable-assert ...) > >It seems the other project is on the right way. > ># cmake -S . -B debug_dir -DCMAKE_BUILD_TYPE=Debug ># cmake -S . -B release_dir -DCMAKE_BUILD_TYPE= Release > >I do not know if Autotools can be used as easily like this? Of course it can. You even replied to the mail! (So maybe read it?) (--disable-assert could be seen as the stand-in for CMAKE_BUILD_TYPE.)
Re: if vs. ifdef in Makefile.am
Hi, It seems the other project is on the right way. I do not know if Autotools can be used as easily like this? # cmake -S . -B debug_dir -DCMAKE_BUILD_TYPE=Debug # cmake -S . -B release_dir -DCMAKE_BUILD_TYPE= Release It sets -g in Debug, -O3 in Release for build command. It sets -DNDEBUG in Release, so NDEBUG is available in .c source code. It sets CMAKE_BUILD_TYPE which can be used in CMakeLists.txt script.
