bug#68179: Re: automake-1.16j on OpenBSD
Bruno Haible , 2024-02-20 12:44:
Bogdan wrote:
Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
Does it work if you put
AC_LANG([Objective C])
somewhere between the lines
cat >> configure.ac << 'END'
and the first
END
following it (i.e., in the 'configure.ac' file) in the test?
No: With this added configure.ac line (before AC_OUTPUT), the
two tests t/objcxx-minidemo.sh and t/objcxx-deps.sh still fail.
If not, do you know any function name that we could use in
AC_CHECK_LIB to check for libobjc?
[...]
==
produces link errors w.r.t. the symbols
objc_autoreleasePoolPush
objc_autoreleasePoolPop
__objc_exec_class
Is one of them suitable for testing? It depends on the ABI. Looking at
https://opensource.apple.com/source/objc4/objc4-706/runtime/objc-abi.h.auto.html
it seems better to choose one of the symbols
_objcInit
objc_getProperty
objc_setProperty
objc_setProperty_atomic
objc_setProperty_nonatomic
...
objc_copyStruct
objc_copyCppObjectAtomic
_objc_empty_cache
...
But wait! The name of the library 'libobjc' is not standardized either.
I would try to just compile a simple Objective-C++ program and see whether that
works or not. Such as:
That's what I would expect from Autoconf...
[...]
===
Missing symbols with clang on OpenBSD:
objc_msg_lookup_sender
__objc_exec_class
Missing symbols with clang on Ubuntu:
objc_msg_lookup
__objc_exec_class
[...]
Assuming that the library is named "libobjc", I'm attaching a patch
that searches for the above symbols in the library. The tests worked
for me without this, and work after. Feel free to add more rows if the
library name is different.
Gathering the other thread:
> So, in summary, I suggest to use the option '-x' instead of
'--verbose'.
> It makes the t/strip2.sh test succeed on OpenBSD. Then you can
remove the comment "This test needs GNU binutils strip.".
Patch attached.
--
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
From 06852fb43569eac608b95dea838858cd75e37327 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 22 Feb 2024 22:03:29 +0100
Subject: [PATCH] Try to fix Objective-c++ on OpenBSD
---
t/objcxx-deps.sh | 4
t/objcxx-minidemo.sh | 4
2 files changed, 8 insertions(+)
diff --git a/t/objcxx-deps.sh b/t/objcxx-deps.sh
index 1f39507fd..519c33244 100644
--- a/t/objcxx-deps.sh
+++ b/t/objcxx-deps.sh
@@ -21,6 +21,10 @@
cat >> configure.ac << 'END'
AC_PROG_OBJCXX
+AC_CHECK_LIB([objc],[__objc_exec_class])
+AC_CHECK_LIB([objc],[objc_getProperty])
+AC_CHECK_LIB([objc],[objc_msg_lookup_sender])
+AC_CHECK_LIB([objc],[objc_msg_lookup])
AC_OUTPUT
END
diff --git a/t/objcxx-minidemo.sh b/t/objcxx-minidemo.sh
index ec0e8e129..f6f53c151 100644
--- a/t/objcxx-minidemo.sh
+++ b/t/objcxx-minidemo.sh
@@ -23,6 +23,10 @@ required=native
cat >> configure.ac << 'END'
AC_PROG_OBJCXX
AC_CONFIG_HEADERS([config.h])
+AC_CHECK_LIB([objc],[__objc_exec_class])
+AC_CHECK_LIB([objc],[objc_getProperty])
+AC_CHECK_LIB([objc],[objc_msg_lookup_sender])
+AC_CHECK_LIB([objc],[objc_msg_lookup])
AC_OUTPUT
END
--
2.35.1
From 4005c0dee31133571c31e79fb5c248731e135f0c Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 22 Feb 2024 21:01:39 +0100
Subject: [PATCH] Fix strip on OpenBSD and others
---
t/strip2.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/strip2.sh b/t/strip2.sh
index a367dd0fe..e48dddc7a 100644
--- a/t/strip2.sh
+++ b/t/strip2.sh
@@ -15,7 +15,7 @@
# along with this program. If not, see <https://www.gnu.org/licenses/>.
# Ensure install-strip works when STRIP consists of more than one word.
-# This test needs GNU binutils strip. See sister test 'strip3.sh'.
+# See sister test 'strip3.sh'.
required='cc strip'
. test-init.sh
@@ -39,7 +39,7 @@ $ACLOCAL
$AUTOCONF
$AUTOMAKE -a
-./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'
+./configure --prefix="$(pwd)/inst" STRIP='strip -x'
$MAKE
$MAKE install-strip
--
2.35.1
bug#68179: Re: automake-1.16j on OpenBSD
Bruno Haible , 2024-02-19 01:44:
Hello Bogdan,
Can you tell us what actually "c++" is on your system? Like e.g. run
"c++ --version" or "c++ --help"?
$ c++ --version
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin
On my system, Autoconf finds "g++", tests it for an Objective C++
compiler, fails, and the t/objcxx-* tests are simply skipped.
It seems that on your system, "c++" actually works as an Objective
C++ compiler, but somehow the "libobjc" library is not added to the
command line, making the test fail during linking.
Yes, 'c++' works as an Objective-C++ compiler:
How interesting. Especially that it compiles, but doesn't link.
[...]
$ c++ -c hello.mm
$ c++ hello.mm
[3 link errors, due to undefined symbols.]
What Autoconf version do your have and can you upgrade that?
I was testing automake-1.16j.
Good (even though it's 1.16.90 now :) ). Even though this looks like
a typo, I really was asking for Autoconf, suspecting a faulty test
there. But no problem, I see in config.log that it's the
latest-and-greatest 2.72.
I suspect it's not passing the required libraries. If it's the newest
version, can you attach the config.log file?
Find attached the config.log.
Right. And, as I suspected, nothing in any LIBS, LD*, no libobjc found.
Does it work if you put
AC_LANG([Objective C])
somewhere between the lines
cat >> configure.ac << 'END'
and the first
END
following it (i.e., in the 'configure.ac' file) in the test?
If not, do you know any function name that we could use in
AC_CHECK_LIB to check for libobjc?
Fortunately, this looks like just an issue with tests (or Autoconf),
not Automake.
--
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
bug#68179: Re: automake-1.16j on OpenBSD
Bruno Haible , 2024-02-19 01:33:
Hello Bogdan,
Thank you for dealing with the Automake support.
Thank you for testing :)
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
I did not have the STRIPPROG environment variable set.
Right. Going through the logs, through various variables, up a few
levels, this finally leads to the line
./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'
in the test itself, and the test's description:
# Ensure install-strip works when STRIP consists of more than one word.
# This test needs GNU binutils strip. See sister test 'strip3.sh'.
And, frankly, I don't know what to do about this. It's the whole
point of the test to use 'strip --verbose' (well, 'strip' + any word,
actually). Fortunately, doesn't look like a bug in Automake itself.
Perhaps we can test with some other option. Is there some useful
command-line option that your 'strip' accepts, while still performing
its work? Like neither --help nor --version?
Come to think of it, we're not testing if the files actually got
installed, so maybe --help or --version would do after all. If you
change the above line to
./configure --prefix="$(pwd)/inst" STRIP='strip --help'
does the test pass? (You can choose --version as well, I guess.). If
not, any other option you may suggest? We could then re-write the test
a bit to say if 'strip --verbose' works, use that. If not, try --help.
3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?
With the patch, the test succeeds.
Good to hear.
Note, however, that 'defined __sun' is not an appropriate test for
Sun C++ (since g++ also exists on Solaris). For compiler predefined
macros, see here:
https://github.com/cpredef/predef/blob/master/Compilers.md
The question is if we want to detect the compiler or the operating
system. I'm toying around with a SunOS with GCC installed, I'm using
__sun and some of the tests that previously failed, now work. At least
with GCC. But thanks for the reference anyway - if we need something
specific to the Sun compiler, we'll know where to look.
--
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
bug#68179: Re: automake-1.16j on OpenBSD
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?
Can you tell us what actually "c++" is on your system? Like e.g. run
"c++ --version" or "c++ --help"?
On my system, Autoconf finds "g++", tests it for an Objective C++
compiler, fails, and the t/objcxx-* tests are simply skipped.
It seems that on your system, "c++" actually works as an Objective
C++ compiler, but somehow the "libobjc" library is not added to the
command line, making the test fail during linking.
What Autoconf version do your have and can you upgrade that? I
suspect it's not passing the required libraries. If it's the newest
version, can you attach the config.log file?
--
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
bug#68179: Re: automake-1.16j on OpenBSD
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc-mix-c-cxx - can you apply the attached patch and re-run the
test?
--
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/t/yacc-cxx.sh b/t/yacc-cxx.sh
index 3f891dac5..effb6e282 100644
--- a/t/yacc-cxx.sh
+++ b/t/yacc-cxx.sh
@@ -51,9 +51,15 @@ cat > parse1.yy << 'END'
// Valid C++, but deliberately invalid C.
#include
#include
+#ifdef __sun
using std::exit;
using std::free;
using std::malloc;
+#else
+using ::exit;
+using ::free;
+using ::malloc;
+#endif
#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
extern "C" {
#endif
diff --git a/t/yacc-d-cxx.sh b/t/yacc-d-cxx.sh
index 556977c22..3885b68bb 100644
--- a/t/yacc-d-cxx.sh
+++ b/t/yacc-d-cxx.sh
@@ -31,9 +31,15 @@ write_parse ()
#include
// Valid C++, but deliberately invalid C.
#include
+#ifdef __sun
using std::exit;
using std::free;
using std::malloc;
+#else
+using ::exit;
+using ::free;
+using ::malloc;
+#endif
#include "$header"
#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
extern "C" {
diff --git a/t/yacc-mix-c-cxx.sh b/t/yacc-mix-c-cxx.sh
index d454fe244..dfe5feeb3 100644
--- a/t/yacc-mix-c-cxx.sh
+++ b/t/yacc-mix-c-cxx.sh
@@ -95,9 +95,15 @@ cat > parse.yy <<'END'
#include
// Valid C++, but deliberately invalid C.
#include
+#ifdef __sun
using std::exit;
using std::free;
using std::malloc;
+#else
+using ::exit;
+using ::free;
+using ::malloc;
+#endif
#include "parse.hh"
#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
extern "C" {
bug#68832: [PATCH] Testing: POSIX yacc and C++ linkage
Hi.
I have access to just Linux and SunOS and cannot reproduce the error
(the tests pass), but Karl's solution seems reasonable and shouldn't hurt.
Attaching a simple patch which (hopefully) fixes the issue. At
least, it doesn't hurt Linux or SunOS, so it shouldn't make things
worse. Feel free to reformat if needed (indents, empty lines, etc.).
--
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
From a96917db0534c9725d6f91b7fd5fde0abcf26ef1 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 6 Feb 2024 21:55:23 +0100
Subject: [PATCH] Fix yacc tests on OpenIndiana
---
t/yacc-clean-cxx.sh | 8
t/yacc-cxx.sh | 7 +++
t/yacc-d-cxx.sh | 6 ++
t/yacc-mix-c-cxx.sh | 12
4 files changed, 33 insertions(+)
diff --git a/t/yacc-clean-cxx.sh b/t/yacc-clean-cxx.sh
index facd6dbc4..6af2047c0 100644
--- a/t/yacc-clean-cxx.sh
+++ b/t/yacc-clean-cxx.sh
@@ -70,9 +70,17 @@ cat > sub1/parsefoo.yxx << 'END'
%{
// This file should contain valid C++ but invalid C.
#include
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
+
// "std::" qualification required by Sun C++ 5.9.
int yylex (void) { return std::getchar (); }
void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
+
%}
%%
x : 'x' { };
diff --git a/t/yacc-cxx.sh b/t/yacc-cxx.sh
index f6b477c0d..3f891dac5 100644
--- a/t/yacc-cxx.sh
+++ b/t/yacc-cxx.sh
@@ -54,9 +54,16 @@ cat > parse1.yy << 'END'
using std::exit;
using std::free;
using std::malloc;
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
// "std::" qualification required by Sun C++ 5.9.
int yylex (void) { return std::getchar (); }
void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
+
%}
%%
a : 'a' { exit(0); };
diff --git a/t/yacc-d-cxx.sh b/t/yacc-d-cxx.sh
index 255e00a71..556977c22 100644
--- a/t/yacc-d-cxx.sh
+++ b/t/yacc-d-cxx.sh
@@ -35,8 +35,14 @@ write_parse ()
using std::free;
using std::malloc;
#include "$header"
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
int yylex (void) { return 0; }
void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
%}
%%
x : 'x' {};
diff --git a/t/yacc-mix-c-cxx.sh b/t/yacc-mix-c-cxx.sh
index 0e7e2e104..d454fe244 100644
--- a/t/yacc-mix-c-cxx.sh
+++ b/t/yacc-mix-c-cxx.sh
@@ -54,8 +54,14 @@ END
cat > p.y <<'END'
%{
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
int yylex (void) { int new = 0; return new; }
void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
%}
%token ZARDOZ
%%
@@ -93,8 +99,14 @@ using std::exit;
using std::free;
using std::malloc;
#include "parse.hh"
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C" {
+#endif
int yylex (void) { return 0; }
void yyerror (const char *s) {}
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+}
+#endif
%}
%token FOOBAR
%%
--
2.35.1
bug#68119: [GNU automake 1.16.5] test-suite 45 tests failed
Hello.
The attached patch fixes the tests for Python 3.12 (and, hopefully
later ones), while still keeping them working for earlier versions.
A simple fix. Could perhaps be written better (like in a single
Python script), but this is enough.
--
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
From dc9454621fa0fa7bf2a7ab65219f300da0ceff65 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sun, 28 Jan 2024 23:06:27 +0100
Subject: [PATCH] Fix tests for Python 3.12
---
t/ax/am-test-lib.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/ax/am-test-lib.sh b/t/ax/am-test-lib.sh
index fbbb79005..d61fd6662 100644
--- a/t/ax/am-test-lib.sh
+++ b/t/ax/am-test-lib.sh
@@ -635,6 +635,10 @@ python_has_pep3147 ()
am_pep3147_tag=$($PYTHON -c 'import imp; print(imp.get_tag())') \
|| am_pep3147_tag=none
fi
+ if test "$am_pep3147_tag" = "none"; then
+am_pep3147_tag=$($PYTHON -c 'import sys; print(sys.implementation.cache_tag)') \
+ || am_pep3147_tag=none
+ fi
test $am_pep3147_tag != none
}
am_pep3147_tag=
--
2.35.1
bug#54020: Allow user-defined libtool options
Mike Frysinger , 2024-01-17 06:04:
On 14 Jan 2024 18:55, Bogdan wrote:
Mike Frysinger , 2024-01-14 02:06:
On 13 Jan 2024 22:29, Bogdan wrote:
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added documentation and a test case including the '-no-suppress'
option. All tests with 'lt' or 'libtool' in the name pass.
Feel free to rename the variables, I just came up with the names
LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
where the variables are put and the mode they're used in.
why do we need LTCOMPILE_POSTFLAGS ? isn't that just after the compile
command ? $obj_compile expands into e.g.
\$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)
so if someone wants to add flags to C/etc..., they already have knobs
to turn.
which means this would simplify by only having one variable right ?
AM_LTCOMPILE_FLAGS
Seems so, at least for now. At least for C compilers. At least until
$obj_compile becomes something else in the future or something more,
or even now contains (or will contain) other options after $(CFLAGS)
on the command line when using other compilers.
For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
suffice, at least now, as it seems. I've made pre- and post- flags for
better flexibility, to be future-proof.
i don't see there ever being a future need here. libtool's design is that
it stops processing after the first non-argument after --mode=compile, and
everything else is a wrapped command which libtool blindly executes. those
commands should have their own set of flags, and libtool is irrelevant at
that point, so giving it a libtool-centric name that is used regardless of
the wrapped command will never make sense.
And that's probably something I wasn't aware of. If it's
dead/useless code, feel free to remove this part. The fact that I made
a patch doesn't mean that it must be applied as a whole and never changed.
the point of posting patches for review is to review and discuss and learn.
maybe you saw something or an angle that i missed. i don't know everything.
-mike
No problem. I hope I didn't sound rude or something, because that
wasn't the purpose. My mail was (supposed to be) completely neutral. I
don't get angry or something if someone reviews my patch, or modifies
it, or even completely rejects it.
I don't know everything either and I my only purpose with adding 2
flags was to be just-in-case future-proof (so that we don't get a
similar report some time later, saying "can you make a flag like that,
because I need one after the invocation as well?", and not to support
something that already exists.
--
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
bug#54020: Allow user-defined libtool options
Mike Frysinger , 2024-01-14 02:06:
On 13 Jan 2024 22:29, Bogdan wrote:
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added documentation and a test case including the '-no-suppress'
option. All tests with 'lt' or 'libtool' in the name pass.
Feel free to rename the variables, I just came up with the names
LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
where the variables are put and the mode they're used in.
why do we need LTCOMPILE_POSTFLAGS ? isn't that just after the compile
command ? $obj_compile expands into e.g.
\$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)
so if someone wants to add flags to C/etc..., they already have knobs
to turn.
which means this would simplify by only having one variable right ?
AM_LTCOMPILE_FLAGS
Seems so, at least for now. At least for C compilers. At least until
$obj_compile becomes something else in the future or something more,
or even now contains (or will contain) other options after $(CFLAGS)
on the command line when using other compilers.
For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
suffice, at least now, as it seems. I've made pre- and post- flags for
better flexibility, to be future-proof.
i don't see there ever being a future need here. libtool's design is that
it stops processing after the first non-argument after --mode=compile, and
everything else is a wrapped command which libtool blindly executes. those
commands should have their own set of flags, and libtool is irrelevant at
that point, so giving it a libtool-centric name that is used regardless of
the wrapped command will never make sense.
-mike
And that's probably something I wasn't aware of. If it's
dead/useless code, feel free to remove this part. The fact that I made
a patch doesn't mean that it must be applied as a whole and never changed.
--
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
bug#54020: Allow user-defined libtool options
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added documentation and a test case including the '-no-suppress'
option. All tests with 'lt' or 'libtool' in the name pass.
Feel free to rename the variables, I just came up with the names
LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
where the variables are put and the mode they're used in.
why do we need LTCOMPILE_POSTFLAGS ? isn't that just after the compile
command ? $obj_compile expands into e.g.
\$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)
so if someone wants to add flags to C/etc..., they already have knobs
to turn.
which means this would simplify by only having one variable right ?
AM_LTCOMPILE_FLAGS
-mike
Seems so, at least for now. At least for C compilers. At least until
$obj_compile becomes something else in the future or something more,
or even now contains (or will contain) other options after $(CFLAGS)
on the command line when using other compilers.
For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
suffice, at least now, as it seems. I've made pre- and post- flags for
better flexibility, to be future-proof.
--
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
bug#8362: make install prefix inserted in source code with generated python files
Mike Frysinger , 2024-01-13 07:26:
On 21 Mar 2023 23:05, Bogdan wrote:
Third, and most important (I think) is that we need to note that
"prog/x.py" is GENERATED, but is NOT marked so. Adding
BUILT_SOURCES = prog/x.py
i don't think this is a correct use of BUILT_SOURCES.
https://www.gnu.org/software/automake/manual/automake.html#Sources
that var is meant for generating headers before Automake's depgen logic
can kick in. that sounds minor, but in practice it means that every
built source is generated before anything else is compiled. which can
insert a bubble into parallel build pipelines. so we would prefer it
only be used for things that matter to header dependency generation.
-mike
You're probably right. Perhaps not meant for this purpose, but I
think BUILT_SOURCES is the only way to make generated code files
visible to the build system, no matter if for dependencies or not. How
do I e.g. have a .c file generated by 'configure' to be properly built
if I can't list it in Makefile.am (because it's a .c.in file in the
beginning)?
This was just my simple hack to help the author. There are better
solutions in this case (the ones I wrote later about), and perhaps the
author's build system/Makefile.am's/dependencies should be fixed in
the first place.
--
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
[bug#54412] [bug#64837] Fix Python on Debian
Hello.
Referring to the discussion related to the upcoming release, I
confirm defect #64837 on Debian GNU/Linux 12 (bookworm) and I confirm
that the last patch in #54412 (the one attached in the defect in
Message#14 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412#14,
not the one inlined) fixes the issue.
I'm also attaching a "double-safe" version, with a simple try-except
added, falling back to the old default, just in case. Also tested,
also fixes the issue.
You can apply whichever you choose.
--
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
From 9eb9f92cd45f2f85e50ff1367319b3af8e5106b9 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 9 Jan 2024 22:31:57 +0100
Subject: [PATCH] Double-safe patch for Python 3.10
---
m4/python.m4 | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/m4/python.m4 b/m4/python.m4
index 8d4e4d215..c97ffd203 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -256,7 +256,17 @@ except ImportError:
am_cv_python_pythondir=`$PYTHON -c "
$am_python_setup_sysconfig
if can_use_sysconfig:
- sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
+ try:
+if hasattr(sysconfig, 'get_default_scheme'):
+ scheme = sysconfig.get_default_scheme()
+else:
+ scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+ # Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+ scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('purelib', scheme, vars={'base':'$am_py_prefix'})
+ except:
+sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
else:
from distutils import sysconfig
sitedir = sysconfig.get_python_lib(0, 0, prefix='$am_py_prefix')
@@ -298,7 +308,17 @@ sys.stdout.write(sitedir)"`
am_cv_python_pyexecdir=`$PYTHON -c "
$am_python_setup_sysconfig
if can_use_sysconfig:
- sitedir = sysconfig.get_path('platlib', vars={'platbase':'$am_py_exec_prefix'})
+ try:
+if hasattr(sysconfig, 'get_default_scheme'):
+ scheme = sysconfig.get_default_scheme()
+else:
+ scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+ # Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+ scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('platlib', scheme, vars={'platbase':'$am_py_exec_prefix'})
+ except:
+sitedir = sysconfig.get_path('platlib', vars={'platbase':'$am_py_exec_prefix'})
else:
from distutils import sysconfig
sitedir = sysconfig.get_python_lib(1, 0, prefix='$am_py_exec_prefix')
--
2.35.1
bug#64837: [bug#54412] [bug#64837] Fix Python on Debian
Hello.
Referring to the discussion related to the upcoming release, I
confirm defect #64837 on Debian GNU/Linux 12 (bookworm) and I confirm
that the last patch in #54412 (the one attached in the defect in
Message#14 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412#14,
not the one inlined) fixes the issue.
I'm also attaching a "double-safe" version, with a simple try-except
added, falling back to the old default, just in case. Also tested,
also fixes the issue.
You can apply whichever you choose.
--
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
From 9eb9f92cd45f2f85e50ff1367319b3af8e5106b9 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 9 Jan 2024 22:31:57 +0100
Subject: [PATCH] Double-safe patch for Python 3.10
---
m4/python.m4 | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/m4/python.m4 b/m4/python.m4
index 8d4e4d215..c97ffd203 100644
--- a/m4/python.m4
+++ b/m4/python.m4
@@ -256,7 +256,17 @@ except ImportError:
am_cv_python_pythondir=`$PYTHON -c "
$am_python_setup_sysconfig
if can_use_sysconfig:
- sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
+ try:
+if hasattr(sysconfig, 'get_default_scheme'):
+ scheme = sysconfig.get_default_scheme()
+else:
+ scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+ # Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+ scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('purelib', scheme, vars={'base':'$am_py_prefix'})
+ except:
+sitedir = sysconfig.get_path('purelib', vars={'base':'$am_py_prefix'})
else:
from distutils import sysconfig
sitedir = sysconfig.get_python_lib(0, 0, prefix='$am_py_prefix')
@@ -298,7 +308,17 @@ sys.stdout.write(sitedir)"`
am_cv_python_pyexecdir=`$PYTHON -c "
$am_python_setup_sysconfig
if can_use_sysconfig:
- sitedir = sysconfig.get_path('platlib', vars={'platbase':'$am_py_exec_prefix'})
+ try:
+if hasattr(sysconfig, 'get_default_scheme'):
+ scheme = sysconfig.get_default_scheme()
+else:
+ scheme = sysconfig._get_default_scheme()
+if scheme == 'posix_local':
+ # Debian's default scheme installs to /usr/local/ but we want to find headers in /usr/
+ scheme = 'posix_prefix'
+sitedir = sysconfig.get_path('platlib', scheme, vars={'platbase':'$am_py_exec_prefix'})
+ except:
+sitedir = sysconfig.get_path('platlib', vars={'platbase':'$am_py_exec_prefix'})
else:
from distutils import sysconfig
sitedir = sysconfig.get_python_lib(1, 0, prefix='$am_py_exec_prefix')
--
2.35.1
bug#68141: automake-1.16j on Ubuntu
Karl Berry , 2023-12-31 00:37:
FAIL: t/python-prefix
Log file is attached.
I think it is the same issue as reported at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64837 .
Thanks for the report. I hope Mike or Bogdan can look at it. I have
trouble discerning fixes for anything Python-related. -k
Hi.
From what I last read, the "new" paths were some new invention of
Ubuntu/Debian(?) and not some general change in Python 3.10, so we
can't simply base on the version number, I guess.
This test (and maybe other?) already has some path-related 'make'
targets, so apparently, such were needed (if not here, than in other
tests, where I wrote such targets myself), and apparently it's not
just a matter of simply changing the hardcoded "site-packages" to
hardcoded "dist-packages", but some more tweaking needs to be done.
I don't have Python 3.10 or Ubuntu/Debian, but maybe I'll play with
this anyway, I'll see. It may be a bit of a guessing game with more
than 1 attempt. Fortunately, it's "just" the test that's failing
because the paths are different and it's e.g. not Automake failing to
install files at all.
--
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
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Karl Berry , Tue Sep 05 2023 23:15:16 GMT+0200 (Central European Summer Time) Karl: The same problem was also reported as bug 65730, with a patch Thanks Zack. I had just composed a reply saying just about exactly the same thing as you wrote :). I will merge the patches and try Bogdan's test, no problem. -k P.S. Bogdan, sorry that I wasn't thinking more clearly when I asked you to write the more complicated version. No problem, new "experience points" earned :). M4 and all Autoconf macros (knowledge about their existence) are still a bit out of my range. Especially AC_PROVIDE_IFELSE, which I don't even have in my Autoconf manual (it *is* found in the code, but not in the manual)... Bogdan
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Karl Berry , Fri Sep 01 2023 00:28:04 GMT+0200
(Central European Summer Time)
One way to maintain compatibility
Thank you very much, Nick. That is all excellent to know.
Bogdan: I will adjust the patch, one way or another.
Nothing more for you to do here after all :). --thanks, karl.
Okay, no problem. Happy to have "triggered" this to move forward :)
--
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
[bug#65600] [PATCH] Allow parameters AM_PROG_LEX
Hi.
In reference to:
https://lists.gnu.org/archive/html/automake/2023-07/msg7.html.
The attached patch allows the AM_PROG_LEX macro to accept
parameters, to accommodate for the fact that AC_PROG_LEX now (since
Autoconf 2.70) requires one. The values accepted by AM_PROG_LEX are
passed to AC_PROG_LEX the following way:
- an empty value is passed as empty, resulting in an Autoconf warning
(just like it is now),
- the word 'yywrap' is passed unchanged,
- the word 'noyywrap' is passed unchanged,
- the word 'empty' results in an empty value (and thus an Autoconf
warning)
- any other word results in a syntax warning and an empty value being
passed (resulting in an Autoconf warning).
Since it's Autoconf 2.70 that started using the parameter, I've
bumped the required value. You may change back if needed.
My M4 "knowledge" is simply basing on other examples and doing
whatever that doesn't result in an error, so you may change the code
as needed (m4_define, m4_warn, m4_expand).
Test for the parameters is added. All tests matching *lex*sh pass.
+11-20s to testing time.
--
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
From b159d82cb474d8ff4fc76e843b871a6d808e70bc Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 29 Aug 2023 20:31:55 +0200
Subject: [PATCH] Add params to AM_PROG_LEX
---
m4/lex.m4 | 15 ++-
t/lex-args.sh | 104 +
t/list-of-tests.mk | 1 +
3 files changed, 118 insertions(+), 2 deletions(-)
create mode 100644 t/lex-args.sh
diff --git a/m4/lex.m4 b/m4/lex.m4
index 7b0511526..bc3555773 100644
--- a/m4/lex.m4
+++ b/m4/lex.m4
@@ -10,10 +10,21 @@
# ---
# Autoconf leaves LEX=: if lex or flex can't be found. Change that to a
# "missing" invocation, for better error output.
+# Make sure to pass any supported parameters (since Autoconf 2.70).
AC_DEFUN([AM_PROG_LEX],
-[AC_PREREQ([2.50])dnl
+[AC_PREREQ([2.70])dnl
AC_REQUIRE([AM_MISSING_HAS_RUN])dnl
-AC_REQUIRE([AC_PROG_LEX])dnl
+m4_define([params], [])dnl
+m4_case([$1],
+ [], [m4_define([params], [])],
+ [yywrap], [m4_define([params], [yywrap])],
+ [noyywrap], [m4_define([params], [noyywrap])],
+ [empty],[m4_define([params], [])],
+ [m4_define([params], [])
+m4_warn([syntax], ['$0': calling AM_PROG_LEX with an unknown argument '$1'.
+You should use one of: 'yywrap', 'noyywrap', 'empty', or an empty value. Using an empty value.])])
+
+AC_PROG_LEX(m4_expand([params]))
if test "$LEX" = :; then
LEX=${am_missing_run}flex
fi])
diff --git a/t/lex-args.sh b/t/lex-args.sh
new file mode 100644
index 0..eea1e34f6
--- /dev/null
+++ b/t/lex-args.sh
@@ -0,0 +1,104 @@
+#! /bin/sh
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+# Autoconf new requires AC_PROG_LEX to be called with either 'yywrap'
+# or 'noyywrap' as the parameter (previously, the macro had no parameters).
+# After updating AM_PROG_LEX, check that either the required parameter values
+# are passed down to AC_PROG_LEX, the defaults are used, or a warning is
+# issued (and the default is used).
+# (parts copied from t/lex-clean.sh)
+
+required='cc lex'
+. test-init.sh
+
+expected_errmsg='AC_PROG_LEX without either yywrap or noyywrap'
+
+cp configure.ac configure.bak
+
+cat > Makefile.am << 'END'
+bin_PROGRAMS = foo
+foo_SOURCES = main.c lexer.l
+LDADD = $(LEXLIB)
+END
+
+cat > lexer.l << 'END'
+%{
+#define YY_NO_UNISTD_H 1
+%}
+%%
+"GOOD" return EOF;
+.
+END
+
+cat > main.c << 'END'
+int main (void) { return yylex (); }
+int yywrap (void) { return 1; }
+END
+
+for failing in '' '([empty])' '([])' '()';
+do
+ echo "== Testing AM_PROG_LEX with >$failing<"
+
+ cat configure.bak - > configure.ac <&1 | grep "$expected_errmsg") \
+ || (cat configure.ac && exit 1)
+ rm -rf autom4te*.cache
+done;
+
+for working in '([noyywrap])' '([yywrap])';
+do
+ echo "== Testing AM_PROG_LEX with >$working<"
+
+ cat configure.bak - > configure.ac <&1 | grep "
bug#19614: Split packaging invocation to catch errors
Nick Bowler , Tue Jul 18 2023 08:55:53 GMT+0200
(Central European Summer Time)
On 2023-07-17, Karl Berry wrote:
Hi Dimitrios, Bogdan - back on this bug from 2015 (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19614
Bogdan sent a patch that splits the tar and compress into separate
invocations. It seems basically good to me, but the dist-formats test
fails because it builds multiple archive formats (.tar.gz, .tar.bz2,
etc.) in parallel, and so removing $(distdir).tar (and .err) files are
subject to a race condition.
dist-gzip: distdir
- tardir=$(distdir) && $(am__tar) | eval GZIP= gzip $(GZIP_ENV) -c
$(distdir).tar.gz
+ tardir=$(distdir) && $(am__tar) > $(distdir).tar 2>$(distdir).tarerr
So my question is, will it suffice in this limited case to just put $$
into the filenames? It seems like it should be ok to me, but I'm not
sure I have enough imagination to know why that would fail. I can't see
figuring out how to run mktemp here.
With the tar file generation as a separate command, it should be
straightforward to avoid this problem by just moving the tar generation
and error checking commands into a separate rule. Then changing all the
various dist-xyz commands to depend on that instead of distdir. Example:
$(distdir).tar: distdir
commands to tar it
dist-gzip: $(distdir).tar
commands to gzip it
and so on. Then there should be no race with parallel "make dist" as
the tar file will only be generated once.
Probably a better idea than mine, e.g.
tmpname=`mktemp $(distdir)/dist.XX`
tardir=$(distdir) && $(am__tar) > $(tmpname).tar 2>$(distdir).err
or
tardir=$(distdir) && $(am__tar) > $(distdir)-$RANDOM.tar 2>$(distdir).err
[...]
--
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
bug#54063: automake cannot run without generated Texinfo manual
Karl Berry , Fri Jul 14 2023 23:32:21 GMT+0200
(Central European Summer Time)
I could distribute just the .texi.in file and still get
autoreconf/automake/packaging to work. Right now, I get an error
about a missing .texi file
I thought Mike's fix (-e ... /dev/null) should already have fixed that?
Well, to be honest, I simply made the fix for the code that was
present in the repo, assuming it would behave the same as the official
version. Indeed, it seems that it works even without my fix. Oh well,
at least one more chance to get the output filename (if present).
Well, in any case, it's not bad to check for the .texi.in, so I'm happy
you posted about it.
> echo '@setfilename bar.texi' >foo.texi
Shouldn't the above read "bar.info" instead of "bar.texi"?
Oops, certainly so! Sharp eyes. Fortunately in my actual test file I got
it right, so I think my description of the (non-)behavior I saw still
stands ... --thanks again, karl.
OK, better typo in a mail than in the repo/docs.
P.S. Still working on several more patches from you. Thanks for all!
Nice to hear :). It's good that you check them so thoroughly, not
just the code but also asking "is this the way it should work?".
--
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
bug#54063: automake cannot run without generated Texinfo manual
Karl Berry , Fri Jul 14 2023 00:34:39 GMT+0200
(Central European Summer Time)
Bogdan, Pat, Gavin, all - back on this bug:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
Subject: bug#54063: - special case] Try .texi.in when .texi missing
Bogdan - the basic idea of your patch seemed fine, to use .texi.in when
.texi is missing.
After investigating the behavior of @setfilename and Automake, as far as
I can tell, it simply does not work. (Pat, I don't understand how it
worked for you.) As far as I could see, Automake reads the @setfilename,
and changes the .info rule accordingly, but the .texi.info suffix rule
does not run.(*) Automake also does not change the HTMLS variable for
@setfilename, as Pat previously noted.
*That* deep I didn't look.
Therefore, I did not think we should test the case of @setfilename being
different from the basename in .texi.in, since that's not a case that's
supported in Automake. I tweaked your new test
txinfo-no-texi-but-texi-in. I also added a second item to the new test,
to check the results when the .texi.in has no @setfilename.
Then I wondered what the point was of reading .texi.in at all, if the
@setfilename had to match the basename. But I guess the answer is, it
could find an @include version.texi.
[...]
As I wrote, my reason and my part of the issue was that I could
distribute just the .texi.in file and still get
autoreconf/automake/packaging to work. Right now, I get an error about
a missing .texi file, so for the time being, I package a stub .texi
file and generate the "real" .texi file with ./configure.
My point wasn't about reading the .texi.in file if .texi doesn't
exist, just to get the output filename. My point was not to throw
errors if no file with an output filename could be found and use
.texi.in instead (if it exists). Simpler than skipping the check
altogether and assume that the developer will provide all the input
files at the time when they're needed (./configure, autogen.sh-like,
whatever).
The presence of a .texi[.in] file at all, or an @setfilename directive
within the texi file if it is there, remains optional.
As previously discussed in this bug, I added a warning to automake.texi
about @setfilename having to match the basename if it's present. I think
a check+warning for that could usefully be added to the code in this
function (scan_texinfo_file), but I just can't cope with spending more
time on this issue. I also don't want to think about adding "full"
support for @setfilename to Automake, given that @setfilename is no
longer required or especially recommended for Texinfo.
Fine by me. It's you who decides. I just wanted to (re-)add my point
of view and the source of my idea/problem.
Wow, this is all confusing.
Indeed. And more complicated than I thought (as usual).
I sure hope it works out (closing the bug,
probably prematurely). --thanks, karl.
Thanks. Hope I helped at least to push this forward.
Just one more thing:
(*) I constructed a tiny source tree (in a new/empty directory):
echo '@setfilename bar.texi' >foo.texi
Shouldn't the above read "bar.info" instead of "bar.texi"?
echo 'info_TEXINFOS = foo.texi' >Makefile.am
cat >>configure.ac
AC_INIT([am-texi-fname], [1.0])
AM_INIT_AUTOMAKE
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
^D
aclocal
automake --foreign --add-missing
autoconf
configure
make # nothing happens
make info# nothing happens
make ./bar.info # nothing happens
\grep bar.info Makefile
INFO_DEPS = $(srcdir)/bar.info
$(srcdir)/bar.info: foo.texi
Nothing is made. I believe because Automake sees the @setfilename and
makes all the rules based on finding a bar.texi, which doesn't exist,
therefore make can't find anything to do. make -d reports:
Rejecting rule '%.info: %.texi' due to impossible prerequisite 'bar.texi'.
Interesting. And more complex than I thought.
--
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
bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
Karl Berry , Fri Apr 21 2023 23:57:12 GMT+0200
(Central European Summer Time)
Thanks for the report, Dan, and for looking into this, Bogdan.
#!User bins/perl
Apart from anything else, this cannot be solved. Shebang lines do not
support quoting.
Thus I think what we should do is have configure give a better error
message when the Perl path contains whitespace, that is, explicitly
stating it can't be supported. Instead of just failing "by the way" due
to the lack of quoting. Would you be up for making a patch for that?
Sure, seems easy. Too bad I don't see where configure is checking
for 'mkdir -p' and 'install -c', I could fix that as well.
But anyway, patch for the Perl path attached. I thought about using
'grep -q' and checking the exit code, but maybe this version is more
portable.
--
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
From 2c3d2040b39a5dfe7d6335fbf3619755900c5424 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sun, 23 Apr 2023 13:20:26 +0200
Subject: [PATCH] Show error if Perl path contains spaces
---
configure.ac | 6 ++
1 file changed, 6 insertions(+)
diff --git a/configure.ac b/configure.ac
index d095ccb1a..0c5dc5511 100644
--- a/configure.ac
+++ b/configure.ac
@@ -71,6 +71,12 @@ AC_PATH_PROG([PERL], [perl])
if test -z "$PERL"; then
AC_MSG_ERROR([perl not found])
fi
+if test x"`echo $PERL | grep ' '`" != "x"; then
+ AC_MSG_ERROR([The path to your Perl contains spaces.
+This would cause build failures later or unusable programs.
+Please use a path without spaces and try again.])
+fi
+
# Save details about the selected perl interpreter in config.log.
AM_RUN_LOG([$PERL --version])
$PERL -e 'require 5.006;' || {
--
2.35.1
bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
Hello.
Thank you for the bug report. The problem is a bit more complicated,
unfortunately. At least from my point of view.
I did a bit of an analysis. The problem can be replicated on current
master on a Linux - just do
ln -s /usr/bin 'User bins'
export PATH='User bins':$PATH
and reconfigure.
I can surround $PERL and $(PERL) with parentheses (patch attached), but:
1) this doesn't fix the "shebang" lines, like #!/bin/bash, leaving
e.g. bin/aclocal with
#!User bins/perl
and that not only will not work, it still stops the build with
help2man: can't get `--help' info from bin/aclocal
because of
$ bin/aclocal --help
bash: bin/aclocal: User: bad interpreter: No such file or directory
2) this won't work if the correct perl command has options, like when
we need to, for some reason, have e.g. PERL=perl -W
3) I noticed problem 2) because my fake "User bins" appears also in
$(INSTALL) and in $(MKDIR_P) in the generated Makefile. Those cannot
be quoted, because "/whatever/mkdir -p" is not a correct program name.
It's "/whatever/mkdir" and "-p" is a parameter.
Sorry to say this, but until someone provides a better solution, I
recommend installing Perl (and other GNU tools - MinGW, coreutils,
etc.) in paths without spaces, like c:\perl or
c:\users\your_username\perl (assuming "your_username" doesn't have
spaces, of course). This may also save you headaches with all those
scripts which have "#!/bin/bash" or just "bash".
--
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.orgFrom f354e9c74d4b8d6c3a51016fb6bffe698cc741c9 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Fri, 21 Apr 2023 19:34:57 +0200
Subject: [PATCH] Partial fix for spaces in Perl path
---
configure.ac | 4 ++--
doc/local.mk | 2 +-
lib/gendocs.sh | 2 +-
t/local.mk | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index d095ccb1a..e952c3d1a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -72,8 +72,8 @@ if test -z "$PERL"; then
AC_MSG_ERROR([perl not found])
fi
# Save details about the selected perl interpreter in config.log.
-AM_RUN_LOG([$PERL --version])
-$PERL -e 'require 5.006;' || {
+AM_RUN_LOG(["$PERL" --version])
+"$PERL" -e 'require 5.006;' || {
AC_MSG_ERROR(
[perl 5.6 or better is required; perl 5.10 or better
is recommended. If you have several perl versions
diff --git a/doc/local.mk b/doc/local.mk
index d72e8e6bb..8b7d98caa 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -37,7 +37,7 @@ EXTRA_DIST += %D%/help2man
update_mans = \
$(AM_V_GEN): \
&& $(MKDIR_P) %D% \
-&& AUTOMAKE_HELP2MAN=true ./pre-inst-env $(PERL) $(srcdir)/%D%/help2man --output=$@ --info-page=automake
+&& AUTOMAKE_HELP2MAN=true ./pre-inst-env "$(PERL)" $(srcdir)/%D%/help2man --output=$@ --info-page=automake
%D%/aclocal.1 %D%/automake.1:
$(AM_V_GEN): \
diff --git a/lib/gendocs.sh b/lib/gendocs.sh
index 9afe3100e..58ea6cee0 100755
--- a/lib/gendocs.sh
+++ b/lib/gendocs.sh
@@ -246,7 +246,7 @@ copy_images()
local odir
odir=$1
shift
- $PERL -n -e "
+ "$PERL" -n -e "
BEGIN {
\$me = '$prog';
\$odir = '$odir';
diff --git a/t/local.mk b/t/local.mk
index 4fa46a071..912de5311 100644
--- a/t/local.mk
+++ b/t/local.mk
@@ -256,7 +256,7 @@ installcheck-local: installcheck-testsuite
installcheck-testsuite:
$(AM_V_GEN)$(MAKE) $(AM_MAKEFLAGS) check \
LOG_COMPILER=$(AM_TEST_RUNNER_SHELL) \
- PL_LOG_COMPILER=$(PERL) \
+ PL_LOG_COMPILER="$(PERL)" \
am_running_installcheck=yes
# Ensure that the installed Automake perl modules are found when running 'installcheck' target
@@ -278,6 +278,6 @@ EXTRA_DIST += $(perf_TESTS)
clean-local: clean-local-check
.PHONY: clean-local-check
clean-local-check:
- $(AM_V_GEN)$(PERL) $(srcdir)/t/ax/deltree.pl t/*.dir t/*/*.dir */t/*.dir
+ $(AM_V_GEN)"$(PERL)" $(srcdir)/t/ax/deltree.pl t/*.dir t/*/*.dir */t/*.dir
# vim: ft=automake noet
--
2.35.1
Re: faster tests [was: rhel8 test failure confirmation?]
Karl Berry , Mon Apr 17 2023 22:16:38 GMT+0200 (Central European Summer Time) Hi Bogdan, Then, I analysed the files and added the trick from t/backcompat2.sh (if possible) and/or removed the extra calls to $ACLOCAL (if possible). Thanks much for looking into this. Short version: after a few hours of testing and modifications, I *may* have saved up to 1 minute and 12 seconds of testing... Well, at least you get kudos for doing all the research :). :) You may look at the attached patch as a result of the investigation and then ... you're free to completely ignore it :). It works for me, but I wonder if it won't cause more confusion than it's worth... I agree. Not worth the complications. t/backcompat-acout.sh: 35 -> 24s That seems to me like the only one that might be worth applying the patch for. Quite a bit more savings than anything else in the list. Yes. Aclocal is called in a loop here, always with the same set of (Automake) macros in configure.ac, so it probably always generates the same aclocal.m4 (no external macros called either). This duplication can be avoided. Strange that the trick doesn't work in all cases, but at least it works here. # A trick to make the test run muuuch faster, by avoiding repeated # runs of aclocal (one order of magnitude improvement in speed!). echo 'AC_INIT(x,0) AM_INIT_AUTOMAKE' > configure.ac Alternatively, I wonder how much this is really saving. Maybe the trick should not be used anywhere. 5 seconds is the gain, just checked. From about 17.5s to about 12.5s. On the whole test, of course. So, in this particular case, the saving was meaningful (cut 25-30% of time, even if this is just 5 wallclock seconds). On the other hand, I'm now calling aclocal 7 times instead of 1, so 6 skipped aclocal calls give about 5s of savings, or about 1s per aclocal call. In a loop with even tens of iterations the saving would be visible, but otherwise it's just single seconds, or even literally 1 second, like some of my results show. - having 1277 .sh files in 't/' means that even if each runs in 30 seconds, you have 10 hours of testing just from the number of tests, Indeed. The only practical way to run make check is in parallel. I discovered that early on :). It still takes painfully long for me (10-15min at best, on a new and fast machine). I have 4 vcores and I'm afraid the full set would literally take hours to complete on my machine. 10-15 minutes is a luxury! :) - it may be better to determine if there are duplicate tests Sounds awfully hard to do. I agree. Compare each test with each other. Sometimes within "a reasonable group" (like tests with the same name and just a number appended), sometimes with all other tests (like the ones named after a problem ID). A complexity of n^2 operations :). My impression is that the (vast?) majority of tests are the direct result of bug reports. I would not be inclined to tweak, remove, merge, or change them. Even if two tests are nearly identical, that "nearly" can make all the difference. Not sure about the "majority" (I didn't read each and every file), but I totally agree with the last part. Sometimes some simple change in one of the files causes some problem to appear and the test succeeds (or fails if needed) and e.g. not porting the change to a new "merged" test may cause that we lose the test for an actual problem without realizing it (in other words, we lose coverage for some part of the code). Furthermore, more "atomic" tests allow you to check single functionalities and give more "atomic" results - you narrow down which functionality is failing vs. having a file "t/test-everything.sh", browsing through the log on each failure, and restarting the (hours long) test after each fix. We don't want that. That's the "balance slider" here: more tests = more time (no guarantee that less tests would actually merge something and require less time), but also more tests = more comfort. - as you see above, t/pr401b.sh takes 1m42s to run. I wonder if e.g. running the 'distcheck' target in tests would be the main factor Sounds very likely to me. Distcheck is inherently a lengthy process. I can't imagine how it can be sped up. Although I agree that 1:42 seems rather long for a trivial package like those in the tests. It runs '$MAKE distcheck' 3 times and one '$MAKE check' + '$MAKE distclean' pair, so fortunately it's not one 'distcheck' that is taking so long. Having 25-30s per one 'distcheck' means there isn't a minute to chop off any longer, but - again - maybe just single seconds. 25-30s doesn't sound so bad compared to 1:42... Same case for t/pr401c.sh and t/pr401.sh, although shorter times. At a glance, I see required='cc libtoolize' in 401b, whereas 401c and 401 only ha
bug#23639: Half bug
Hi.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49901 for an
explanation. It's partially the macro itself that is buggy:
"
This sort of behaviour is the main reason why the aclocal documentation
suggests these files not contain anything other than macro definitions[1],
so that they are not sensitive to include order.
"
[1]
https://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
--
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
bug#31126: [PATCH][bug#31126] GNU Automake 1.16.1 fails 21 tests on Solaris 10 sparcv9
Hi.
About lex-clean-cxx.sh, lex-depend-cxx.sh, yacc-cxx.sh, yacc-d-cxx.sh
and yacc-mix-c-cxx.sh: fixed by the patch found in bugs# 34151, 42393,
44795, 49755, 45205 and 55073.
About fn99subdir.sh, subpkg.sh, subpkg2.sh, subpkg3.sh and
subpkg-yacc.sh: partial analysis provided in bugs# 45205 and 55073.
--
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
bug#30612: [PATCH][bug#30612] [automake-1.16] make check fails on Solaris 11.3 x86
Hi.
Problem fixed by the patch found in bugs# 34151, 42393, 44795, 49755,
45205 and 55073.
--
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
bug#15256: [PATCH][bug#15256] GNU Automake 1.14 : FAIL 6 on Solaris 10 Sparc v9
Hi.
About t/yacc-cxx, t/yacc-d-cxx and t/yacc-mix-c-cxx: fixed by the
patch found in bugs# 34151, 42393, 44795, 49755, 45205 and 55073.
--
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
[bug#62886] Unnecessary bug registered
The bugtracker erroneously thought my previous mail was a new bug
report...
To be closed/deleted, just like
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60419.
--
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
bug#45205: GNU Automake - testsuite failures on Solaris
Hi.
Failures in lex/yacc/C++ tests should be fixed now with the patch in
my previous mail.
I'm afraid the remaining test failures may indeed point to an actual
bug in Automake, not just in tests.
Regarding failures in tests:
- subpkg,
- subpkg2,
- subpkg-yacc,
as far as I've investigated, the problem is that $(distdir) =
$(top_distdir) in a subpackage while this apparently should never be
the case. This makes the file checks:
test ! -f $(distdir)/LDADD.c
test -f $(top_distdir)/LDADD.c
fail for the obvious reason - if the directory is the same, then
either the file exists, or it doesn't, so one of the tests will always
fail.
No idea why the directories are the same, though.
As for fn99subdir: make distcheck fails, because the 'cnfsubdir' dir
doesn't exist in the distribution directory/package while it
apparently should. No idea why the directory is not packaged, but at
lease I know it's not a problem of e.g. the length of the path (what I
suspected earlier).
As for subpkg3: the subpkg directory exists, but doesn't contain
'configure'. Also no idea why.
There must be something system-specific, obviously, that makes
Automake behave not the way it's supposed to. Sure, it can also be a
problem in the tests themselves, but I don't see why they would
succeed on a Linux and fail on a Solaris/SunOS.
--
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
[bug#62886] [PATCH][bug 34151, 42393, 44795, 49755, 45205, 55073] Fix lex/yacc C++ tests on Solaris/SunOS
Hi all.
The Solaris/SunOS lex generates C++ code with functions properly
wrapped into >extern "C"<, but only if:
- compiling as C++ (__cplusplus is #defined),
- the feature constant __EXTERN_C__ is #defined (probably meant just
for the SunOS compiler, not for all).
Other compilers, like GCC/G++, obviously miss the SunOS-specific
__EXTERN_C__ and thus miss >extern "C"<, declaring the yylex()
function as C++ (the default). This doesn't need to be a problem, but:
- the function should be declared as the user code expects it (as C
for C programs and as C++ for C++ programs),
- the Automake lex tests for C++ re-declare the function always as a C
function.
The re-declarations happens probably for good reason, like for lex
implementations which don't declare the function in advance combined
with C/C++ compilers which always require declarations. Unfortunately,
having the same function declared as C++ (default) first and then
later as C causes compiler errors.
The attached patch corrects the declarations in the following way:
- if we're in C++ mode and __EXTERN_C__ is declared (so, we're on a
SunOS with their compiler), declare the function as C in C++ mode
(i.e., use >extern "C"<), just like the SunOS lex does,
- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also
"__sun" is not declared (so, we're NOT on a SunOS), still assume C++
mode, but a different system and declare the function as C in C++ mode
(i.e., use >extern "C"<) to support other compilers,
- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also
"__sun" IS declared (so, we ARE on a SunOS, but not using their
compiler), declare the function as C++ in C++ mode, just like the
SunOS lex does,
- if we're NOT in C++ mode, declare the function as C. Not the case in
these tests, though.
This should match what the SunOS lex/compiler do and expect which
not braking other systems (re-checked on my Linux - works).
Verified that the defect exists on a Solaris 11.4 Build 15 (SunOS
5.11, GCC 7.3.0, amd64) and that the patch fixes it.
Furthermore, I checked how GCC manages the declarations of standard
C functions in C++. Seems so simple as saying:
using std::some_c_library_function_name;
which the SunOS library (or maybe just the old GCC library there) is
not doing.
So, it just takes this to fix the missing prototypes in C++ mode.
In short, the patch:
- fixes the remaining part of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34151,
- fixes the remaining part of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42393
(t/silent-many-languages.sh works for me),
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44795,
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49755,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45205,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55073.
Fortunately, these parts are just problems with the tests
themselves, not with Automake in general.
--
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.orgFrom b8813c99e220073b528511f47cc0c4cfd8ef1c20 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sun, 16 Apr 2023 17:39:26 +0200
Subject: [PATCH] Fix lex/yacc C++ tests on SunOS
---
t/lex-clean-cxx.sh | 10 --
t/lex-depend-cxx.sh | 5 -
t/yacc-cxx.sh | 3 +++
t/yacc-d-cxx.sh | 3 +++
t/yacc-mix-c-cxx.sh | 3 +++
5 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/t/lex-clean-cxx.sh b/t/lex-clean-cxx.sh
index 3632d5c87..afbacf392 100644
--- a/t/lex-clean-cxx.sh
+++ b/t/lex-clean-cxx.sh
@@ -54,7 +54,10 @@ END
cat > parsefoo.lxx << 'END'
%{
#define YY_DECL int yylex (void)
-extern "C" YY_DECL;
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C"
+#endif
+YY_DECL;
#define YY_NO_UNISTD_H 1
int isatty (int fd) { return 0; }
%}
@@ -71,7 +74,10 @@ cp parsefoo.lxx parsebar.ll
cat > mainfoo.cc << 'END'
// This file should contain valid C++ but invalid C.
-extern "C" int yylex (void);
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C"
+#endif
+int yylex (void);
using namespace std;
int main (int argc, char **argv)
{
diff --git a/t/lex-depend-cxx.sh b/t/lex-depend-cxx.sh
index 60615a54e..817450fc0 100644
--- a/t/lex-depend-cxx.sh
+++ b/t/lex-depend-cxx.sh
@@ -47,7 +47,10 @@ END
cat > joe.ll << 'END'
%{
#define YY_DECL int yylex (void)
-extern "C" YY_DECL;
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C"
+#endif
+YY_DECL
bug#55073: [PATCH][bug 34151, 42393, 44795, 49755, 45205, 55073] Fix lex/yacc C++ tests on Solaris/SunOS
Hi all.
The Solaris/SunOS lex generates C++ code with functions properly
wrapped into >extern "C"<, but only if:
- compiling as C++ (__cplusplus is #defined),
- the feature constant __EXTERN_C__ is #defined (probably meant just
for the SunOS compiler, not for all).
Other compilers, like GCC/G++, obviously miss the SunOS-specific
__EXTERN_C__ and thus miss >extern "C"<, declaring the yylex()
function as C++ (the default). This doesn't need to be a problem, but:
- the function should be declared as the user code expects it (as C
for C programs and as C++ for C++ programs),
- the Automake lex tests for C++ re-declare the function always as a C
function.
The re-declarations happens probably for good reason, like for lex
implementations which don't declare the function in advance combined
with C/C++ compilers which always require declarations. Unfortunately,
having the same function declared as C++ (default) first and then
later as C causes compiler errors.
The attached patch corrects the declarations in the following way:
- if we're in C++ mode and __EXTERN_C__ is declared (so, we're on a
SunOS with their compiler), declare the function as C in C++ mode
(i.e., use >extern "C"<), just like the SunOS lex does,
- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also
"__sun" is not declared (so, we're NOT on a SunOS), still assume C++
mode, but a different system and declare the function as C in C++ mode
(i.e., use >extern "C"<) to support other compilers,
- if we're in C++ mode and __EXTERN_C__ is NOT declared, but also
"__sun" IS declared (so, we ARE on a SunOS, but not using their
compiler), declare the function as C++ in C++ mode, just like the
SunOS lex does,
- if we're NOT in C++ mode, declare the function as C. Not the case in
these tests, though.
This should match what the SunOS lex/compiler do and expect which
not braking other systems (re-checked on my Linux - works).
Verified that the defect exists on a Solaris 11.4 Build 15 (SunOS
5.11, GCC 7.3.0, amd64) and that the patch fixes it.
Furthermore, I checked how GCC manages the declarations of standard
C functions in C++. Seems so simple as saying:
using std::some_c_library_function_name;
which the SunOS library (or maybe just the old GCC library there) is
not doing.
So, it just takes this to fix the missing prototypes in C++ mode.
In short, the patch:
- fixes the remaining part of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34151,
- fixes the remaining part of
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42393
(t/silent-many-languages.sh works for me),
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44795,
- fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49755,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45205,
- partially fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55073.
Fortunately, these parts are just problems with the tests
themselves, not with Automake in general.
--
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.orgFrom b8813c99e220073b528511f47cc0c4cfd8ef1c20 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sun, 16 Apr 2023 17:39:26 +0200
Subject: [PATCH] Fix lex/yacc C++ tests on SunOS
---
t/lex-clean-cxx.sh | 10 --
t/lex-depend-cxx.sh | 5 -
t/yacc-cxx.sh | 3 +++
t/yacc-d-cxx.sh | 3 +++
t/yacc-mix-c-cxx.sh | 3 +++
5 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/t/lex-clean-cxx.sh b/t/lex-clean-cxx.sh
index 3632d5c87..afbacf392 100644
--- a/t/lex-clean-cxx.sh
+++ b/t/lex-clean-cxx.sh
@@ -54,7 +54,10 @@ END
cat > parsefoo.lxx << 'END'
%{
#define YY_DECL int yylex (void)
-extern "C" YY_DECL;
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C"
+#endif
+YY_DECL;
#define YY_NO_UNISTD_H 1
int isatty (int fd) { return 0; }
%}
@@ -71,7 +74,10 @@ cp parsefoo.lxx parsebar.ll
cat > mainfoo.cc << 'END'
// This file should contain valid C++ but invalid C.
-extern "C" int yylex (void);
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C"
+#endif
+int yylex (void);
using namespace std;
int main (int argc, char **argv)
{
diff --git a/t/lex-depend-cxx.sh b/t/lex-depend-cxx.sh
index 60615a54e..817450fc0 100644
--- a/t/lex-depend-cxx.sh
+++ b/t/lex-depend-cxx.sh
@@ -47,7 +47,10 @@ END
cat > joe.ll << 'END'
%{
#define YY_DECL int yylex (void)
-extern "C" YY_DECL;
+#if (defined __cplusplus) && ((!defined __sun) || (defined __EXTERN_C__))
+extern "C"
+#endif
+YY_DECL
bug#20987: Replacing "15 Support for test suites" in the Automake manual
Hello.
Thank you for the great amount of work you put into the document.
You explain a lot of things in great detail on those 63 pages. Really
impressive.
I haven't read every single word in the document, I've just browsed
it, but I've found some issues which would need to be addressed:
1) Although you chose the open ODT format (respect for that!), the
Automake documentation is in the Texinfo format and the recommended
way of submitting changes is using a patch file (see the "HACKING"
file, e.g. https://git.savannah.gnu.org/cgit/automake.git/tree/HACKING).
2) The document you have provided contains symbols (like the Greek
letter Sigma), tables and diagrams which may be hard to put in the
Texinfo file so that they look good in both an 80-column terminal
window (the 'info' command) and in HTML (or other formats).
3) The document contains language issues which need to be fixed. Examples:
- repetitions like "the the",
- "back slash" (I believe it should be "backslash"),
4) Writing "${ AWK }" etc. is an error because of the whitespace. The
correct syntax is just "${AWK}". Just checked with GNU make.
5) Commands like "configure && make" or "configure && make && make
install" will not work for people who don't have the current directory
in their $PATH. It should say "./configure ..." (the dot-slash at the
beginning).
6) I believe "make dist-xz" would make a product-0.5.tar.xz file, not
a product-0.5.xz file.
7) The "tar xfa" command: BSD tar says "tar: Option -a is not
permitted in mode -x". GNU tar accepts it, but some other 'tar'
implementations (in some modes, perhaps) expect the filename to always
immediately follow the 'f' command, so e.g. "tar xfa foo.tar.gz"
doesn't work, because it looks for a file literally called "a" (the
one after the "f").
8) Other cosmetic issues like:
- "Perl" is the name of the language and "perl" is the name of the
interpreter for the language Perl,
- write "Perl interpreter" instead of "perl compiler".
Someone who is native in English, and preferably also technical,
should do an even deeper review of the file. My knowledge about
testing is also limited.
--
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: faster tests [was: rhel8 test failure confirmation?]
Bogdan , Tue Apr 04 2023 21:51:52 GMT+0200 (Central European Summer Time) Karl Berry , Mon Apr 03 2023 02:08:22 GMT+0200 (Central European Summer Time) # A trick to make the test run muuuch faster, by avoiding repeated # runs of aclocal (one order of magnitude improvement in speed!). echo 'AC_INIT(x,0) AM_INIT_AUTOMAKE' > configure.ac Hadn't noticed this before. Maybe you could see what tests are currently taking the longest to run, and see if the above helps speed them up? Sure, when I eventually find the time to run 'time' :). I was hoping to have some results by now, hence the delay. Is there a way to time individual tests, or do I have to run 'time make check TESTS=...'? It seems a somewhat weird thing to do, but if it saves enough time, I guess it would be worth it. --thanks, karl. Yes, it is a bit weird and I don't know if this can negatively impact the tests themselves in functionalities which may rely on aclocal.m4 to be correct. Certainly the tests that add or remove macro calls to or from configure.ac need to have aclocal.m4 up-to-date and so they need to run aclocal after each modification, as I see it. Coming back to the subject: I chose tests which: - run 'aclocal' in a loop (assuming it is indented): egrep '^[ \t]+\$ACLOCAL' t/*sh - run 'aclocal' without arguments more than once: grep -c '\$ACLOCAL[ \t]*$' t/*.sh | /bin/grep -v ':[01]$' Then, I analysed the files and added the trick from t/backcompat2.sh (if possible) and/or removed the extra calls to $ACLOCAL (if possible). Results of the analysis or gain in time: t/aclocal-path-install-serial.sh: cannot change here, aclocal is under test t/backcompat-acout.sh: 35 -> 24s t/deprecated-acinit.sh: cannot change here, aclocal is under test t/dist-auxdir-many-subdirs.sh: 1:23 -> 1:18 t/dist-auxfile.sh: 16 -> 15s t/dist-no-built-sources.sh: 8s, cannot change here (uses current configure.ac) t/suffix.sh: 8s, cannot change here (uses current configure.ac) t/test-driver-is-distributed.sh: 16 -> 15s t/am-prog-cc-c-o.sh: 17 -> 15s, cannot change here (uses current configure.ac) t/ar-lib3.sh: cannot change here (uses current configure.ac) t/ar-lib4.sh: cannot change here (uses current configure.ac) t/asm2.sh: 14 -> 12s t/asm3.sh: 14 -> 12s t/asm.sh: 12 -> 10s t/backcompat3.sh: 12 -> 10s t/conffile-leading-dot.sh: 10 -> 9s t/confh.sh: 9 -> 8s t/copy.sh: cannot change here (uses current configure.ac) t/dir-named-obj-is-bad.sh: cannot change here (uses current configure.ac) t/distcheck-configure-flags-subpkg.sh: 10 -> 9s t/distcheck-hook2.sh: 9.8 -> 9.2s t/dist-shar.sh: 8 -> 7-8s t/dist-tarZ.sh: skipped t/fn99subdir.sh: 12 -> 11s t/fort2.sh: 8-9 -> 7.5s t/libobj16a.sh: 29-34 -> 28s t/libobj16b.sh: 29 -> 28s t/libobj19.sh: 22 -> 21s t/libobj-basic.sh: 20 -> 20s t/lisp2.sh: 9 -> 7s t/nodef2.sh: 6 -> 5s t/nodef.sh: 5 -> 4s t/objc-basic.sh: cannot change here (changes configure.ac afterwards) t/objcxx-basic.sh: cannot change here (changes configure.ac afterwards) t/pr401b.sh: 1:42-43 -> 1:38 t/pr401c.sh: 50 -> 48s t/pr401.sh: 41 -> 38s t/serial-tests.sh: 6 -> 5s t/silent-configsite.sh: cannot change here (changes configure.ac afterwards) t/strictness-precedence.sh: 12 -> 9s t/subobj6.sh: 10-13 -> 10s t/subpkg2.sh: cannot change here, aclocal is under test t/subpkg3.sh: cannot change here, aclocal may be under test t/subpkg4.sh: cannot change here, aclocal may be under test t/subpkg.sh: cannot change here, aclocal is under test t/subpkg-yacc.sh: cannot change here, aclocal may be under test t/vala-configure.sh: 22 -> 21s t/vala-non-recursive-setup.sh: skipped t/warning-groups-win-over-strictness.sh: 7 -> 5s t/warnings-precedence.sh: 11-12 -> 9s t/warnings-strictness-interactions.sh: 4-5 -> 4s t/warnopts.sh: 5 -> 4s Short version: after a few hours of testing and modifications, I *may* have saved up to 1 minute and 12 seconds of testing... You may look at the attached patch as a result of the investigation and then ... you're free to completely ignore it :). It works for me, but I wonder if it won't cause more confusion than it's worth... Funny thing - removing $ACLOCAL from t/backcompat.sh actually makes it run much SLOWER - from 30s to 55s. No idea why. Other conclusions: - having 1277 .sh files in 't/' means that even if each runs in 30 seconds, you have 10 hours of testing just from the number of tests, - it may be better to determine if there are duplicate tests (but with different names, circumstances, etc.) and eliminate those or merge tests which are "close enough" each other (like one being just another test case for the other) - this may be a significant gain, - as you see above, t/pr401b.sh takes 1m42s to run. I wonder if e.g. running the 'distcheck' target in tests would be the main fac
Re: rhel8 test failure confirmation?
Jacob Bachmeyer , Mon Apr 03 2023 06:16:53
GMT+0200 (Central European Summer Time)
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or
not
(i.e., has the patch installed)? And then use the longer sleep in
automake testing if needed.
If you can locate Autom4te::FileUtils, grepping it for "Time::HiRes"
will tell you if autom4te supports sub-second timestamps, but then you
need more checks to validate that the filesystem actually has
sub-second timestamps.
A simple check:
if $PERL -I${autom4te_perllibdir:-/usr/share/autoconf}
-I/usr/local/share/autoconf \
-MAutom4te::FileUtils -e 'exit defined $INC{q[Time/HiRes.pm]}
? 0 : 1'; then
# autom4te uses Time::HiRes
else
# autom4te does not use Time::HiRes
fi
This method also has the advantage of implicitly also checking that
$PERL has Time::HiRes installed by determining if loading
Autom4te::FileUtils causes Time::HiRes to be loaded. (In other words,
this will give the correct answer on Perl 5.6 if Time::HiRes was
installed from CPAN or on later Perls if a distribution packager has
unbundled Time::HiRes and the user has not installed its package.)
Nice. The 0 and 1 may not be portable to each OS in the Universe
(see EXIT_SUCCESS and EXIT_FAILURE in exit(3)), but should be
good/portable enough for our goals. Or maybe some other simple solution.
As I understand, this could even be used to actually call the sub
which checks the timestamps, so we'd have a read-to-use test. Only a
matter of where to put it... Is there some code that runs *before* all
tests that could set some environment variable passed to the tests,
create a file, or whatever?
[...]
It seems to me that using autoconf -f or similar is papering over the
problem, so that the tests are no longer testing the normal behavior.
Which does not sound desirable.
The Automake testsuite is supposed to test Automake, not Autoconf, so
working around Autoconf issues is appropriate.
I agree with this one, too. Don't do workarounds in tests to fix
Automake issues, just fix the issue in Automake :). But workarounds,
conditional code, skipping tests, etc. are allowed when using other
tools in Automake tests.
In this case, if
always using "autoconf -f" allows us to eliminate the sleeps entirely
(and does not expand the running time of Autoconf too much), we should
do that, at least in my view.
Yes, that could be the simplest. I (or someone) just need to find
out how to time individual tests (or maybe I'll just run 'time make
check TESTS=...') and do the actual measurements :).
I was hoping to have more time for this, but unfortunately, I got
busy with other things and this may have to wait a bit. Maybe this
week, maybe the next...
--
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: rhel8 test failure confirmation?
Karl Berry , Mon Apr 03 2023 02:08:23 GMT+0200
(Central European Summer Time)
I modified my autom4te using the attached patch,
Thank you very very much for finding this, Bogdan.
:) Hope it saved some headaches :)
I'm glad that Paul has already installed it in Autoconf.
I can't easily confirm it for myself right now, but I'm hopeful.
(Maybe Frederic or others can try with the development autoconf.)
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or not
(i.e., has the patch installed)? And then use the longer sleep in
automake testing if needed.
Perhaps. If not possible to call the autom4te's routine/module
directly, it could be possible to make a loop similar to the one
already in place (the filesystem timestamp resolution). But this loop
would require calling autom4te the number of times needed to establish
the result, which could make just this testing longer than the gain...
In fact, I wonder about autom4te providing an explicit way to test
whether it's been patched, because I suspect that a functionality test
(run autom4te a bunch of times on a bunch of newly-created files) would
be highly susceptible to wrong results. Checking the autom4te
--version number might be the easiest and best thing to do.
Until autoconf/autom4te has a '--has=some-feature-name' option,
checking the version number would probably be the best, as you say.
Best, not easy :). Compare '2.71' to '2.72-beta1-snapshot-12345678' or
vice versa with the suffixes :). Some nice Perl one-liner should do
the trick.
I think it's pretty crucial that the automake (or autoconf) tests not
spuriously fail due to filesystem timing, even for people that have the
"old" (unpatched) autom4te. People will certainly keep using current and
older releases of autoconf for years to come.
I agree, so it would be best to have a workaround or a plan "B" for
those unpatched, for some reasonable time, at least. What would the
plan be is the question. Force '-f'? Run an initial pre-test for
autom4te and generate the $AUTOCONF variable? Run an initial pre-test
for autom4te and force the timeout in the tests (like set an
environment variable, check for that in the sanity test and assume 1
second sleep if present)?
But, fortunately, these are still "just tests".
It seems to me that using autoconf -f or similar is papering over the
problem, so that the tests are no longer testing the normal behavior.
Which does not sound desirable.
Wdyt? --thanks again, karl.
On one hand - yes, you're right. On the other - we're working around
an issue with SOME OTHER TOOL. Just like #ifdef/#endif with C
compilers, Perl's 'eval' at runtime, or whatever.
I think we're allowed to do whatever workaround we find suitable to
make Automake work or make its tests pass. Obviously, it would be best
if autoconf/autom4te we patched (preferably from the beginning), but
if we can't have everything else perfect, we do our best, including
the old 'sleep 1' in the sanity test (and probably other things).
Bogdan
P.S. Sorry for not replying earlier. I wanted to come back with some
results, but apparently, it will take a bit more time.
--
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: faster tests [was: rhel8 test failure confirmation?]
Karl Berry , Mon Apr 03 2023 02:08:22 GMT+0200
(Central European Summer Time)
# A trick to make the test run muuuch faster, by avoiding repeated
# runs of aclocal (one order of magnitude improvement in speed!).
echo 'AC_INIT(x,0) AM_INIT_AUTOMAKE' > configure.ac
Hadn't noticed this before. Maybe you could see what tests are currently
taking the longest to run, and see if the above helps speed them up?
Sure, when I eventually find the time to run 'time' :). I was hoping
to have some results by now, hence the delay.
Is there a way to time individual tests, or do I have to run 'time
make check TESTS=...'?
It seems a somewhat weird thing to do, but if it saves enough time, I
guess it would be worth it. --thanks, karl.
Yes, it is a bit weird and I don't know if this can negatively
impact the tests themselves in functionalities which may rely on
aclocal.m4 to be correct. Certainly the tests that add or remove macro
calls to or from configure.ac need to have aclocal.m4 up-to-date and
so they need to run aclocal after each modification, as I see it.
--
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: rhel8 test failure confirmation? [PATCH for problem affecting Automake testsuite]
Jacob Bachmeyer , Sat Apr 01 2023 04:54:22
GMT+0200 (Central European Summer Time)
A quick introduction to the situation for the Autoconf list:
The Automake maintainers have encountered a bizarre issue with
sporadic random test failures, seemingly due to "disk writes not
taking effect" (as Karl Berry mentioned when starting the thread).
Bogdan appears to have traced the issue to autom4te caching and
offered a patch. I have attached a copy of Bogdan's patch.
Bogdan's patch is a subtle change: the cache is now considered stale
unless it is /newer/ than the source files, rather than being
considered stale only if the source files are newer. In short, this
patch causes the cache to be considered stale if its timestamp
/matches/ the source file, while it is currently considered valid if
the timestamps match. I am forwarding the patch to the Autoconf list
now because I concur with the change, noting that Time:HiRes is also
limited by the underlying filesystem and therefore is not a "magic
bullet" solution. Assuming the cache files are stale unless proven
otherwise is therefore correct.
Thank you :)
Note again that this is _Bogdan's_ patch I am forwarding unchanged. I
did not write it (but I agree with it).
[further comments inline below]
Bogdan wrote:
Bogdan , Sun Mar 05 2023 22:31:55 GMT+0100
(Central European Standard Time)
Karl Berry , Sat Mar 04 2023 00:00:56
GMT+0100 (Central European Standard Time)
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.
[...]
Another tip, maybe: cache again. When I compare which files are
newer than the only trace file I get in the failing 'backcompat2'
test ('autom4te.cache/traces.0'), I see that 'configure.ac' is
older than this file in the succeeding run, but it's newer in the
failing run. This could explain why 'configure' doesn't get updated
to put new values in config.h (in my case) - 'autom4te' thinks it's
up-to-date.
The root cause may be in 'autom4te', sub 'up_to_date':
# The youngest of the cache files must be older than the oldest of
# the dependencies.
# FIXME: These timestamps have only 1-second resolution.
# Time::HiRes fixes this, but assumes Perl 5.8 or later.
(lines 913-916 in my version).
This comment Bogdan cites is not correct: Time::HiRes could be
installed from CPAN on Perls older than 5.8, and might be missing from
a 5.8 or later installation if the distribution packager separated it
into another package. Nor is Time::HiRes guaranteed to fix the issue;
the infamous example is the FAT filesystem, where timestamps only have
2-second resolution. Either way, Time::HiRes is now used if
available, so this "FIXME" is fixed now. :-)
Good to hear :).
I didn't comment on the comment itself ;). Time::HiRes could have
been installed on Perl < 5.8, but since then it was in the core
modules, right? So, it *should* work for users by default then, and
Autoconf wouldn't require additional installations. That was the core
message of the comment, I think.
Perhaps 'configure.ac' in the case that fails is created "not
late enough" (still within 1 second) when compared to the cache,
and the cached values are taken, generating the old version of
'configure' which, in turn, generates old versions of the output
files.
Still a guess, but maybe a bit more probable now.
Does it work when you add '-f' to '$AUTOCONF'? It does for me -
again, about 20 sequential runs of the same set of tests and about
5 parallel with 4 threads. Zero failures.
I'd probably get the same result if I did a 'rm -fr
autom4te.cache' before each '$AUTOCONF' invocation.
[...]
More input (or noise):
1) The t/backcompat2.sh test (the only test which fails for me) is a
test which modifies configure.ac and calls $AUTOCONF several times.
2) Autom4te (part of Autoconf) has a 1-second resolution in checking
if the input files are newer than the cache.
Maybe. That comment could be wrong; the actual "sub mtime" is in
Autom4te::FileUtils. Does your version of that module use
Time::HiRes? Git indicates that use of Time::HiRes was added to
Autoconf at commit 3a9802d60156809c139e9b4620bf04917e143ee2 which is
between the 2.72a and 2.72c snapshot tags.
I'm using Autoconf provided by my system and it's version 2.71
(official package, I assume). Autom4te::FileUtils is using the
built-in stat() function.
3) Thus, a sequence: 'autoconf' + quickly modify configure.ac +
quickly run 'autoconf' may cause autom4te to use the old values from
Re: rhel8 test failure confirmation?
Bogdan , Sun Mar 05 2023 22:31:55 GMT+0100 (Central
European Standard Time)
Karl Berry , Sat Mar 04 2023 00:00:56 GMT+0100
(Central European Standard Time)
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.
[...]
Another tip, maybe: cache again. When I compare which files are
newer than the only trace file I get in the failing 'backcompat2' test
('autom4te.cache/traces.0'), I see that 'configure.ac' is older than
this file in the succeeding run, but it's newer in the failing run.
This could explain why 'configure' doesn't get updated to put new
values in config.h (in my case) - 'autom4te' thinks it's up-to-date.
The root cause may be in 'autom4te', sub 'up_to_date':
# The youngest of the cache files must be older than the oldest of
# the dependencies.
# FIXME: These timestamps have only 1-second resolution.
# Time::HiRes fixes this, but assumes Perl 5.8 or later.
(lines 913-916 in my version).
Perhaps 'configure.ac' in the case that fails is created "not late
enough" (still within 1 second) when compared to the cache, and the
cached values are taken, generating the old version of 'configure'
which, in turn, generates old versions of the output files.
Still a guess, but maybe a bit more probable now.
Does it work when you add '-f' to '$AUTOCONF'? It does for me -
again, about 20 sequential runs of the same set of tests and about 5
parallel with 4 threads. Zero failures.
I'd probably get the same result if I did a 'rm -fr autom4te.cache'
before each '$AUTOCONF' invocation.
If it does work for you, then maybe it would be better to add '-f'
to the 'AUTOCONF' variable where it's defined? Tests with a single
'$AUTOCONF' invocation won't notice (they will create their cache
anyway), while tests with multiple calls can maybe get fixed all at once.
[...]
More input (or noise):
1) The t/backcompat2.sh test (the only test which fails for me) is a
test which modifies configure.ac and calls $AUTOCONF several times.
2) Autom4te (part of Autoconf) has a 1-second resolution in checking
if the input files are newer than the cache.
3) Thus, a sequence: 'autoconf' + quickly modify configure.ac +
quickly run 'autoconf' may cause autom4te to use the old values from
the cache instead of processing the new configure.ac. "Quickly" means
within the same second.
4) I ran the provided list of tests (t/backcompat2.sh,
t/backcompat3.sh, t/get-sysconf.sh, t/lex-depend.sh, t/nodef.sh,
t/remake-aclocal-version-mismatch.sh, t/subdir-add2-pr46.sh,
t/testsuite-summary-reference-log.sh) in batches of 20 or more runs.
5) With the tools as they are on my system, I got a failure in the
t/backcompat2.sh test in the first batch (18th round, IIRC).
6) I modified my autom4te using the attached patch, which essentially
makes the mentioned sub 'up_to_date' work as if the cache is out of
date if its modtime (up to 1-second precision) is not only earlier,
but also equal to the modtime of any dependencies (including
configure.ac).
7) After modifying autom4te, I ran 120 rounds of the same set of tests
in single-threaded mode, and additional 120 rounds in parallel mode
(-j4). Total of 240 runs of all those 8 mentioned tests each. ZERO
FAILURES.
8) I brought autom4te to its original state and started running the
tests again. I got the first failure quite early (32nd run, IIRC).
I believe that shortening the sleep in Automake in the suspected
commit (720a1153134b833de9298927a432b4ea266216fb "m4: speed up
filesystem modification checks") is not an error in Automake. It
simply causes this issue in autom4te (not enough precision) to show up.
I'm not 100% sure about my results and conclusions, because
t/backcompat2.sh doesn't seem to be that quick in modifying
configure.ac to cause a false cache hit in autom4te. But these results
seem to confirm my previous results where using -f to bypass the cache
helped.
Another thing is that we have a bit of a special case here - quick
modifications and reconfigurations. So, even though autom4te has a
"FIXME" there, probably over 99% of users are not impacted. People
usually modify configure.ac manually, then run autoconf manually
(after 1 second) and then just ./configure.
What can we do about this?
- have autom4te patched and wait for the fix to reach a release (and
get installed on every possible end-user system?), and revert the
sleep until this is done,
- revert the commit and increase the test time again,
- fix the randomly-failing tests by add
bug#30556: [PATCH] Python tests should run with multiple python versions
Karl Berry , Mon Mar 27 2023 00:47:18 GMT+0200
(Central European Summer Time)
Subject: bug#30556: [PATCH] Python tests should run with multiple python
versions
Thanks Bogdan (for this and other recent patches).
Glad to help. :)
I guess this got fixed in the repository
Yes, Mike (Frysinger) has installed several Python-related patches since
the last release. And I think others are still pending.
Yes, I saw a few commits in the history. I didn't dig deeper into
them, but I saw that some at least touched one of the areas pointed to
by this bug, so I simply assumed the commits fixed this bug "by the way".
Python support looks more complicated than I thought (install
source, complied objects, compiled-optimized objects, one time in
"lib", the other - in "lib64", ...), but this at least was something I
more-or-less understand and could help with.
I've kind of
lost track of the current situation.
(Myself, I remain blocked due to the random test failure
problem. Someday I'll get back to Automake, I hope, but not this week. :()
Since the defects I understand and maybe can fix are becoming fewer
and fewer, I'm looking at that myself as well. Right now, I still
insist the problem is in autom4te, but I'll need to do more analysis
and testing.
--
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
bug#30556: [PATCH] Python tests should run with multiple python versions
Hi.
I have both Python v2 and v3 installed on my system. The tests shown
in the provided error log pass for me, in all cases:
- no version - defaults to 3.9.8
make check TESTS='t/nobase-python.sh t/py-compile-basic.sh
t/py-compile-basedir.sh t/py-compile-destdir.sh
t/py-compile-option-terminate.sh t/python3.sh t/python10.sh
t/python12.sh '
- explicit v2 (2.7.18):
PYTHON=python2 make check TESTS='t/nobase-python.sh
t/py-compile-basic.sh t/py-compile-basedir.sh t/py-compile-destdir.sh
t/py-compile-option-terminate.sh t/python3.sh t/python10.sh
t/python12.sh '
- explicit v3:
PYTHON=python3 make check TESTS='t/nobase-python.sh
t/py-compile-basic.sh t/py-compile-basedir.sh t/py-compile-destdir.sh
t/py-compile-option-terminate.sh t/python3.sh t/python10.sh
t/python12.sh '
I guess this got fixed in the repository since the defect was
reported. Some of the tests touch the "uninstall" target and that
certainly was changed.
My Automake version:
- branch: master
- last commit ID: 0901ccdd0cb21bfa3911a2668615e388fef94426
- last commit date: Wed Mar 1 15:03:30 2023 -0800
Actually, I could fix t/python-prefix.sh to work with Python v2 and
t/python-virtualenv.sh to work at all (didn't work by default for me).
Patch attached. Now all tests with "py" in the name pass on my system
(both with v2 and v3). I assume that Automake, 'make install' and
'make uninstall' do their job correctly (and that's most probably
true) and it's just the tests that were doing wrong.
--
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.orgFrom 96da24fbbaf40cb793ac0decd4c398cdb683b4e2 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sun, 26 Mar 2023 13:15:40 +0200
Subject: [PATCH] Fix Python tests - multiple versions
---
t/python-prefix.sh | 6 +-
t/python-virtualenv.sh | 10 ++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/t/python-prefix.sh b/t/python-prefix.sh
index df15e4300..dab2e9fd5 100644
--- a/t/python-prefix.sh
+++ b/t/python-prefix.sh
@@ -43,7 +43,11 @@ echo-python-exec-prefix:
@echo $(PYTHON_EXEC_PREFIX)
END
-py_version=$(python -c 'import sys; print("%u.%u" % sys.version_info[:2])')
+py_exec=$PYTHON
+if test "x$py_exec" = "x"; then
+ py_exec=python
+fi
+py_version=$($py_exec -c 'import sys; print("%u.%u" % sys.version_info[:2])')
py_inst_site=inst/lib/python$py_version/site-packages
py_instexec_site=instexec/lib/python$py_version/site-packages
diff --git a/t/python-virtualenv.sh b/t/python-virtualenv.sh
index ae5d96ad6..b06964b90 100644
--- a/t/python-virtualenv.sh
+++ b/t/python-virtualenv.sh
@@ -100,6 +100,8 @@ test-run:
python -c 'from am_foo import foo_func; assert (foo_func () == 12345)'
python -c 'from am_virtenv import old_am; assert (old_am () == "AutoMake")'
all-local: debug
+get-pyexecdir:
+ @echo $(pyexecdir)
END
cat > am_foo.py << 'END'
@@ -127,8 +129,8 @@ check_install ()
py_installed "$py_site"/am_foo.pyc
py_installed "$py_site"/am_virtenv/__init__.py
py_installed "$py_site"/am_virtenv/__init__.pyc
- test -f "$py_site"/libquux.a
- test -f "$py_site"/am_virtenv/libzardoz.a
+ test -f "$($MAKE get-pyexecdir ${1+"$@"})"/libquux.a
+ test -f "$($MAKE get-pyexecdir ${1+"$@"})"/am_virtenv/libzardoz.a
}
check_uninstall ()
@@ -139,8 +141,8 @@ check_uninstall ()
py_installed --not "$py_site"/am_foo.pyc
test ! -e "$py_site"/am_virtenv/__init__.py
py_installed --not "$py_site"/am_virtenv/__init__.pyc
- test ! -e "$py_site"/libquux.a
- test ! -e "$py_site"/am_virtenv/libzardoz.a
+ test ! -e "$($MAKE get-pyexecdir ${1+"$@"})"/libquux.a
+ test ! -e "$($MAKE get-pyexecdir ${1+"$@"})"/am_virtenv/libzardoz.a
}
$ACLOCAL
--
2.35.1
bug#9587: [PATCH] Automake claims $(*F), $(
Hello again.
The attached patch allows the following symbols not to cause
Automake errors about non-POSIX variables (and updates the test):
$(@F) $(%F) $(?F) $($(?) $(<) $(*) $% $? $< $*
I don't have the POSIX standard and didn't find any references to
POSIX variables in GNU make's manual, so I assume the quotation in the
defect report is correct.
The patch doesn't do anything to check if the variables are
supported by the end-user's 'make', because it's not the end-user's
'make' which decides what is portable or not. The message is not
changed either.
I don't know if "$(<:.foo=.bar)" should be allowed, but that seems
to be taken care of in
lib/Automake/Variable.pm:scan_variable_expansions anyway (resulting in
just "<" in this example).
Fixes bug#9587.
--
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.orgFrom f759c741296d505a5a5ca8c7ed9fc201a7ac4a0c Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 23 Mar 2023 20:39:05 +0100
Subject: [PATCH] Add POSIX-allowed variables
---
lib/Automake/Variable.pm | 3 ++-
t/vars3.sh | 21 -
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index cc6b12fe0..ba6cf9e8f 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -132,7 +132,8 @@ non-object).
=cut
my $_VARIABLE_CHARACTERS = '[.A-Za-z0-9_@]+';
-my $_VARIABLE_PATTERN = '^' . $_VARIABLE_CHARACTERS . "\$";
+my $_VARIABLE_PATTERN_EXTRA_POSIX = '[*?<%][DF]?';
+my $_VARIABLE_PATTERN = '^(' . $_VARIABLE_CHARACTERS . '|' . $_VARIABLE_PATTERN_EXTRA_POSIX . ")\$";
my $_VARIABLE_RECURSIVE_PATTERN =
'^([.A-Za-z0-9_@]|\$[({]' . $_VARIABLE_CHARACTERS . '[})]?)+' . "\$";
diff --git a/t/vars3.sh b/t/vars3.sh
index ae89a6869..cbba47e68 100644
--- a/t/vars3.sh
+++ b/t/vars3.sh
@@ -15,7 +15,8 @@
# along with this program. If not, see <https://www.gnu.org/licenses/>.
# Check that Automake warns about variables containing spaces
-# and other non-POSIX characters.
+# and other non-POSIX characters, but not about real POSIX
+# variables (see bug#9587).
. test-init.sh
@@ -32,6 +33,10 @@ L08$(o u c h): $(wildcard *.c)
echo $${ok-this is}
L11: $(thisis) $(ok)
${here}
+just_a_test:
+ echo "$(@F) $(%F) $(?F) $( $@
+ echo "$(%) $(?) $(<) $(*)" > $@
+ echo "$% $? $< $*" > $@
EOF
$ACLOCAL
@@ -59,6 +64,20 @@ grep ':8:.*wildcard' stderr
grep ':9:.*another Error' stderr
$EGREP 'ok|thisis|here' stderr && exit 1
+grep '@F' stderr && exit 1
+grep '%F' stderr && exit 1
+grep '?F' stderr && exit 1
+grep '
bug#24507: [PATCH] noinst_PYTHON breaks uninstall of Python files
Hi, Automakers.
The attached patch fixes bug#24507.
I don't fully understand the cause, but I guess that the "if
%?INSTALL%" block gets ignored when "noinst" is present, including the
"?FIRST?" it contains, which defines the missing "am__pep3147_tweak".
Anyway, moving the "?FIRST?" block with the declaration of
"am__pep3147_tweak" outside the "if %?INSTALL%" block fixes the issue.
All tests with "py" in the name pass.
This isn't the first time either. The test I've updated was for a
similar case - bug#10995 ("am__py_compile doesn't get correctly
defined when there a 'noinst_PYTHON' declaration precedes a
'foo_PYTHON' declaration"), that's probably why "am__py_compile" is in
its own "?FIRST?" block at the top now.
No other language XX.am files seem to have "?FIRST?" inside an "if"
block.
--
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.orgFrom bf0a60a61c1413185a982890b30046f46cf9cd1d Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Wed, 22 Mar 2023 17:10:58 +0100
Subject: [PATCH] Fix Python tweak missing when noinst is present
---
lib/am/python.am| 4 ++--
t/python-pr10995.sh | 6 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/am/python.am b/lib/am/python.am
index 98f95af1b..19f268efc 100644
--- a/lib/am/python.am
+++ b/lib/am/python.am
@@ -94,11 +94,11 @@ endif %?INSTALL%
## Uninstalling. ##
## -- ##
-if %?INSTALL%
-
?FIRST?am__pep3147_tweak = \
?FIRST? sed -e 's|\.py$$||' -e 's|[^/]*$$|__pycache__/&.*.pyc __pycache__/&.*.pyo|'
+if %?INSTALL%
+
.PHONY uninstall-am: uninstall-%DIR%PYTHON
uninstall-%DIR%PYTHON:
@$(NORMAL_UNINSTALL)
diff --git a/t/python-pr10995.sh b/t/python-pr10995.sh
index 324be916e..abeb8a124 100644
--- a/t/python-pr10995.sh
+++ b/t/python-pr10995.sh
@@ -17,6 +17,9 @@
# Test automake bug#10995: am__py_compile doesn't get correctly defined
# when there a 'noinst_PYTHON' declaration precedes a 'foo_PYTHON'
# declaration.
+# Test also automake bug#24507: am__pep3147_tweak doesn't get correctly
+# defined when there a 'noinst_PYTHON' declaration precedes a 'foo_PYTHON'
+# declaration and 'make uninstall' fails functionally (just shows errors).
required=python
. test-init.sh
@@ -53,4 +56,7 @@ py_installed --not inst/py/no.pyc
$MAKE disttest
+LC_ALL=C run_make -M uninstall
+grep 'command substitution' output && exit 1
+
:
--
2.35.1
bug#8362: make install prefix inserted in source code with generated python files
Hi all.
A small contribution to the discussion.
First of all, it's not an Automake defect that the user is allowed
to override variables using the command line. This may be used e.g.
for changing compile flags at 'make' time:
make CFLAGS=-Wall
Second, in the provided example, the 'install' target indeed depends
on prog_PYTHON, while 'all' doesn't. Somebody made a decision to
compile Python files at install time and not at compile time. Maybe
because it is not known at compile time where the files will end up,
or they have conflicting names, or for some other good reason.
Third, and most important (I think) is that we need to note that
"prog/x.py" is GENERATED, but is NOT marked so. Adding
BUILT_SOURCES = prog/x.py
to Makefile.am fixes the issue immediately. So, sorry to say this, but
it looks like this defect is invalid. The file prog/x.py is meant to
be built/generated at build time and must be marked as being built.
Another point is that one needs to 'touch' x.src each time to test,
which also is signalling that something may be wrong. But, this may be
just a side effect of the minimalistic example.
By the way, if the real code also needs to substitute just
"$(libexecdir)", which is known at configure time, it should actually
be 'configure' which generates prog/x.py. This would probably stop
this issue from appearing in the first place...
If you really, really want to fix something in Automake, you can use
the attached patch, it seems to fix the issue. But, this is something
I don't recommend, because next we'll be adding each and every
language/script group to the 'all' target and that's probably not the
point. That's why I'm not formatting the patch as I should be.
--
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.orgdiff --git a/bin/automake.in b/bin/automake.in
index f249064d5..73865a67c 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -4610,6 +4610,8 @@ sub handle_all
my @local_headers = ();
push @local_headers, '$(BUILT_SOURCES)'
if var ('BUILT_SOURCES');
+push @local_headers, '$(prog_PYTHON)'
+ if var ('prog_PYTHON');
foreach my $spec (@config_headers)
{
my ($out, @ins) = split_config_file_spec ($spec);
bug#29188: [PATCH] texi2dvi usage doesn't work with
Gavin Smith , Sun Mar 19 2023 19:52:15
GMT+0100 (Central European Standard Time)
On Sun, Mar 19, 2023 at 05:57:19PM +0100, Bogdan wrote:
Anyway, I just provide code the way I'd do it. It's up to "someone higher
up", like you, to make the decision if the patch is to be merged, modified
first, or to be simply left out for some reason. There surely are things I
don't know about so my patches can be wrong or unacceptable for variety of
reasons.
Note that it's not up to me at all; I'm just an interested bystander when
it comes to Automake development.
Okay, for me as a beginner, anyone subscribed to automake-patches is
someone who analyses the fixes people send, so someone "higher up" :).
If there is still a bug in texi2dvi could you please write to
bug-texi...@gnu.org with the details? Many thanks for your time spent
on this issue.
You're welcome, glad to help.
The bug (or at least a surprising inconsistency) is still present in
my texinfo-6.7, that's why I made the patch the way I made it. I'll
check the newest version (7.0.2 as of this writing) or the repository
a bit later. If still there, maybe I'll even send a 3-line patch for
it :).
--
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
bug#29188: [PATCH] texi2dvi usage doesn't work with
Karl Berry , Mon Mar 20 2023 15:36:11 GMT+0100
(Central European Standard Time)
Gavin, thanks for your comments. Always appreciated.
Bogdan, thanks for the patch. I (or the mythical Someone Else) will look
into it. My gut reaction is that it's good to make things work with old
versions in principle, although admittedly Apple's no-GPLv3 policy is
not something we care about supporting, particularly.
Neither do I care for it so much. But if someone reports an actual
problem that something doesn't work on another system and I can make
it work, I can do the fix if it's important or not such a great amount
of work. Not only here, also in my programs.
It increases the potential user range, not only to systems taking
software with licenses they like and patching them indefinitely to
move them forward (OpenBSD? macOS?), but simply also to older Linux
systems.
Regarding Solaris, proprietary operating systems have always been a
secondary target for GNU programs, which is why I have not felt bad
about ignoring the various Solaris bugs. However, it's fine to install
fixes for them. (I doubt the fixes are hard, either.) For what rms has
to say about platform support, see the end of
https://www.gnu.org/prep/maintain/html_node/Platforms.html.
Got it. Do it if you can, because it widens the potential set of
users. Don't do it if it creates a serious mess in the code.
Regarding verbose commentary, although it's true that in general they
can make understanding/modifying unnecessarily difficult, in the
particular case of Automake, they've proven to be very helpful. In
Automake, it's common for a given piece of code to be written in a
specific way for a specific reason (usually due to some old shell X,
some strange platform Y, etc.), and writing it in another way (usually
more "natural") doesn't work. So it's good to describe what's going on.
Certainly it would have been much harder for me to contribute anything
to automake without all the careful comments by Ralf, Stefano, Tom, and
all the other past maintainers. So I have no hesitation for giving a +1
for your detailed comments here, and in general. --thanks, karl.
Thanks :)
--
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
bug#29188: [PATCH] texi2dvi usage doesn't work with
Gavin Smith , Sun Mar 19 2023 11:17:31
GMT+0100 (Central European Standard Time)
On Sat, Mar 18, 2023 at 10:10:05PM +0100, Bogdan wrote:
The problem was with "--build-dir=": the old texi2dvi (which is a shell
script) splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets
the "--build-dir" switch as "--batch" (checks just the first letter, great)
and the "xxx" stays on the command line and is being treated as another
input file, causing the error.
Fortunately, since texinfo-4.9, one can set the build directory with an
environment variable "TEXI2DVI_BUILD_DIRECTORY". Unfortunately, texinfo has
a bug there, too. When setting "--build-dir=" on the command line, the build
mode is set to "tidy" (which cleans some log files, etc.). Fine. The problem
is that if you set the build directory using an environment variable, the
mode is NOT set to "tidy", leaving the logs files and failing tests.
Luckily, you can also set the build mode from an environment variable,
"TEXI2DVI_BUILD_MODE".
It may fix the bug for <= texinfo 4.8 but can I suggest that having
lengthy comments in code explaining why it is done one way and not
another is pretty distracting for anybody trying to understand or
modify the code in the future.
I was thinking about that, but even with versioning I still believe
it's worth to leave explanatory comments or even commented-out code
just to show "don't do this".
I kind of mimicked the existing behavior with my comments. There
already are 4 lines explaining why we must set MAKEINFO and further 9
lines explaining why we need /dev/null, -q (%TEXIQUIET%) and
'--build-dir'.
You can always merge with the comment and remove them immediately
after, just to have them in the history.
Also note that texinfo 4.8 was released
in 2004, nearly 20 years ago, so I question whether it is worth fixing
this in a complicated way
Yes, I noticed that too and was thinking about ignoring the bug.
But, since I could make a fix that would work for both pre-4.9 (well,
maybe not all the way to the very first version) and post-4.9, I gave
it a try.
for the benefit of the proprietary macOS
operating system (I believe they use old versions of GNU programs to
avoid using GPLv3-licensed code).
This I didn't realize up till now. I read the bug, maybe just except
the original subject... Anyway, always more compatibility, and that's
something good, I guess.
Should I skip fixing reported Automake problems on Solaris
(proprietary) or OpenSolaris (discontinued/forked) for the same
reason? Not that I have access to one, but maybe some VMs one day...
Anyway, I just provide code the way I'd do it. It's up to "someone
higher up", like you, to make the decision if the patch is to be
merged, modified first, or to be simply left out for some reason.
There surely are things I don't know about so my patches can be wrong
or unacceptable for variety of reasons.
[Snip patch]
--
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
bug#29188: [PATCH] texi2dvi usage doesn't work with
Hello.
The attached patch fixes bug#29188.
The problem was with "--build-dir=": the old texi2dvi (which is a
shell script) splits "--build-dir=xxx" into "--build-dir" and "xxx",
interprets the "--build-dir" switch as "--batch" (checks just the
first letter, great) and the "xxx" stays on the command line and is
being treated as another input file, causing the error.
Fortunately, since texinfo-4.9, one can set the build directory with
an environment variable "TEXI2DVI_BUILD_DIRECTORY". Unfortunately,
texinfo has a bug there, too. When setting "--build-dir=" on the
command line, the build mode is set to "tidy" (which cleans some log
files, etc.). Fine. The problem is that if you set the build directory
using an environment variable, the mode is NOT set to "tidy", leaving
the logs files and failing tests. Luckily, you can also set the build
mode from an environment variable, "TEXI2DVI_BUILD_MODE".
That's why the new invocation of $(TEXI2DVI) and $(TEXI2PDF) has 2
additional environment variables prepended.
Testing:
- verified - the failing test doesn't work with old texinfo
- verified - the failing test works after the fix with old texinfo
- verified - the failing test works after the fix with new texinfo
- verified - all 84 texi+txi+info tests work after the fix with new
texinfo (make check TESTS="`ls t/*texi*.sh t/*txi*.sh t/*info*.sh`")
- verified - all 84 texi+txi+info tests work after the fix with old
texinfo
Yes, I downloaded texinfo 4.8 just for this purpose.
So, the old texinfo, which doesn't support "--build-dir=" or the
environment variables, should work without change, and the new texinfo
got switched from command-line switches to environment variables and
should work as well, the same way it used to be.
--
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.orgFrom 05cb873bec12638b0218afcb0a42076f571c7836 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sat, 18 Mar 2023 21:46:36 +0100
Subject: [PATCH] Support for texinfo<4.9
---
lib/am/texibuild.am | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/lib/am/texibuild.am b/lib/am/texibuild.am
index 6f6099c8d..b83dbfa44 100644
--- a/lib/am/texibuild.am
+++ b/lib/am/texibuild.am
@@ -76,7 +76,17 @@ INFO_DEPS += %DEST_INFO_PREFIX%%DEST_SUFFIX%
## avoid hitting a Texinfo bug that could cause low-probability racy
## failure when doing parallel builds; see:
## https://lists.gnu.org/archive/html/automake-patches/2012-06/msg00073.html
- $(TEXI2DVI) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% --build-dir=$(@:.dvi=.t2d) -o $@ %TEXIDEVNULL% \
+## See bug#29188 for why we are not using "--build-dir=": the old texi2dvi
+## splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets the
+## "--build-dir" as "--batch" (checks just 1 letter, great!) and the "xxx"
+## stays on the command line as another input file, causing the error.
+ TEXI2DVI_BUILD_DIRECTORY=$(@:.dvi=.t2d) \
+## We need TEXI2DVI_BUILD_MODE=tidy due to another bug in texi2dvi:
+## when "--build-dir" is passed on the command line, the build mode is
+## automatically set to 'tidy' by default, but when the build directory
+## is set using an environment variable, the build mode stays default.
+ TEXI2DVI_BUILD_MODE=tidy \
+ $(TEXI2DVI) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% -o $@ %TEXIDEVNULL% \
?GENERIC? %SOURCE%
?!GENERIC? `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
@@ -97,7 +107,17 @@ INFO_DEPS += %DEST_INFO_PREFIX%%DEST_SUFFIX%
## avoid hitting a Texinfo bug that could cause low-probability racy
## failure when doing parallel builds; see:
## https://lists.gnu.org/archive/html/automake-patches/2012-06/msg00073.html
- $(TEXI2PDF) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% --build-dir=$(@:.pdf=.t2p) -o $@ %TEXIDEVNULL% \
+## See bug#29188 for why we are not using "--build-dir=": the old texi2dvi
+## splits "--build-dir=xxx" into "--build-dir" and "xxx", interprets the
+## "--build-dir" as "--batch" (checks just 1 letter, great!) and the "xxx"
+## stays on the command line as another input file, causing the error.
+ TEXI2DVI_BUILD_DIRECTORY=$(@:.pdf=.t2p) \
+## We need TEXI2DVI_BUILD_MODE=tidy due to another bug in texi2dvi:
+## when "--build-dir" is passed on the command line, the build mode is
+## automatically set to 'tidy' by default, but when the build directory
+## is set using an environment variable, the build mode stays default.
+ TEXI2DVI_BUILD_MODE=tidy \
+ $(TEXI2PDF) $(AM_TEXI2FLAGS) %MAKEINFOFLAGS% %TEXIQUIET% -o $@ %TEXIDEVNULL% \
?GENERIC? %SOURCE%
?!GENERIC? `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE%
--
2.35.1
bug#19615: [PATCH] make dist tarball contains owner/group information from the build system
Hi.
Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60419 for a
possible solution.
--
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
bug#54020: Allow user-defined libtool options
Hi, Automakers!
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added documentation and a test case including the '-no-suppress'
option. All tests with 'lt' or 'libtool' in the name pass.
Feel free to rename the variables, I just came up with the names
LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
where the variables are put and the mode they're used in.
--
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.orgFrom 907c8b7913d1c577b722a24b24cdf9cd8e97755e Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Wed, 15 Mar 2023 17:21:52 +0100
Subject: [PATCH] Add support for compile-mode extra libtool options
---
bin/automake.in| 6 +++--
doc/automake.texi | 8 +++
t/list-of-tests.mk | 1 +
t/lt_extraopts.sh | 55 ++
4 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 t/lt_extraopts.sh
diff --git a/bin/automake.in b/bin/automake.in
index f249064d5..c9e235938 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1474,7 +1474,7 @@ sub handle_languages ()
my $ltverbose = define_verbose_libtool ();
my $obj_ltcompile =
"\$(LIBTOOL) $ltverbose $libtool_tag\$($ptltflags) \$(LIBTOOLFLAGS) "
- . "--mode=compile $obj_compile";
+ . "--mode=compile \$(LTCOMPILE_PREFLAGS) $obj_compile \$(LTCOMPILE_POSTFLAGS)";
# We _need_ '-o' for per object rules.
my $output_flag = $lang->output_flag || '-o';
@@ -6331,7 +6331,9 @@ sub define_compiler_variable
my $verbose = define_verbose_libtool ();
define_variable ("LT$var",
"\$(LIBTOOL) $verbose $libtool_tag\$(AM_LIBTOOLFLAGS)"
- . " \$(LIBTOOLFLAGS) --mode=compile $value",
+ . " \$(LIBTOOLFLAGS) --mode=compile "
+ . "\$(LTCOMPILE_PREFLAGS) $value "
+ . '$(LTCOMPILE_POSTFLAGS)',
INTERNAL);
}
define_verbose_tagvar ($lang->ccer || 'GEN');
diff --git a/doc/automake.texi b/doc/automake.texi
index ec14c5c4c..7138758dd 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5607,6 +5607,14 @@ LIBTOOLFLAGS=--silent}, for instance. Note that the verbosity of
@command{libtool} can also be influenced by the Automake support
for silent rules (@pxref{Automake Silent Rules}).
+The @samp{LTCOMPILE_PREFLAGS} variable is the place to list
+additional libtool compile flags to be put right after
+@option{--mode=compile} on the command line (only when compiling).
+
+Similarly, the @samp{LTCOMPILE_POSTFLAGS} variable is the place to list
+additional libtool compile flags to be put at the end of the command line
+(only when compiling).
+
@node LTLIBOBJS, Libtool Issues, Libtool Flags, A Shared Library
@subsection @code{LTLIBOBJS} and @code{LTALLOCA}
@cindex @code{LTLIBOBJS}, special handling
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 6f25f0494..2bff2771c 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -685,6 +685,7 @@ t/ltinstloc.sh \
t/ltlibobjs.sh \
t/ltlibsrc.sh \
t/ltorder.sh \
+t/lt_extraopts.sh \
t/m4-inclusion.sh \
t/maintclean.sh \
t/maintclean-vpath.sh \
diff --git a/t/lt_extraopts.sh b/t/lt_extraopts.sh
new file mode 100644
index 0..d26f4e689
--- /dev/null
+++ b/t/lt_extraopts.sh
@@ -0,0 +1,55 @@
+#! /bin/sh
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+# Test the support for LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS.
+# Also, a good place to test other similar options, if such come in the future.
+
+required='cc libtoolize'
+. test-init.sh
+
+cat >> configure.ac << 'END'
+AC_PROG_CC
+AM_PROG_AR
+AC_CONFIG_MACRO_DIRS([m4])
+LT_INIT
+AC_OUTPUT
+END
+
+cat > Makefile.am << 'END'
+lib_LTLIBRARIES = libblah.la
+libblah_la_SOURCES = blah.c
+libblah_la_LDFLAGS = -version-info 1:0:0
+END
+
+cat > blah.c << 'END'
+int main (void)
+{
+ return 0;
+}
+EN
Re: rhel8 test failure confirmation?
Karl Berry , Sat Mar 04 2023 00:00:56 GMT+0100
(Central European Standard Time)
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.
[...]
Another tip, maybe: cache again. When I compare which files are
newer than the only trace file I get in the failing 'backcompat2' test
('autom4te.cache/traces.0'), I see that 'configure.ac' is older than
this file in the succeeding run, but it's newer in the failing run.
This could explain why 'configure' doesn't get updated to put new
values in config.h (in my case) - 'autom4te' thinks it's up-to-date.
The root cause may be in 'autom4te', sub 'up_to_date':
# The youngest of the cache files must be older than the oldest of
# the dependencies.
# FIXME: These timestamps have only 1-second resolution.
# Time::HiRes fixes this, but assumes Perl 5.8 or later.
(lines 913-916 in my version).
Perhaps 'configure.ac' in the case that fails is created "not late
enough" (still within 1 second) when compared to the cache, and the
cached values are taken, generating the old version of 'configure'
which, in turn, generates old versions of the output files.
Still a guess, but maybe a bit more probable now.
Does it work when you add '-f' to '$AUTOCONF'? It does for me -
again, about 20 sequential runs of the same set of tests and about 5
parallel with 4 threads. Zero failures.
I'd probably get the same result if I did a 'rm -fr autom4te.cache'
before each '$AUTOCONF' invocation.
If it does work for you, then maybe it would be better to add '-f'
to the 'AUTOCONF' variable where it's defined? Tests with a single
'$AUTOCONF' invocation won't notice (they will create their cache
anyway), while tests with multiple calls can maybe get fixed all at once.
And I take back that the problem doesn't arise when I call the
single test. I just wasn't "lucky enough". Got a failure now (without
the fix), in the 7th attempt, while 40 or 60 (I did batches of 20)
earlier succeeded (with the fix, of course).
So, maybe it's not a problem of a NEW system by itself, just a
FASTER system + 1-second resolution in 'autom4te'.
--
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: 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: 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: 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
ljh via Discussion list for automake , Wed Mar 01
2023 19:50:56 GMT+0100 (Central European Standard Time)
Hi community,
I want to build debug or release with
```
$ make # NDEBUG=1
$ make NDEBUG=1
```
Can I have automake.am to define and convey something like this to the output
Makefile:
```
ifdef NDEBUG # if vs. ifdef
CPPFLAGS += -DNDEBUG
CFLAGS += -O3 # .cpp
else
CFLAGS += -g # .cpp
LDFLAGS += -fsanitize=address
endif
```
But it seems I can only write `if` but not `ifdef` in Makefile.am.
So I had to enable ndebug option in configure.ac. That's a lot more work.
Thanks
Hi.
Just adding my 2 cents...
I hope I won't be saying something silly or obvious here, but maybe
you can pass the actual flags on the command line as a new variable
and include it *unconditionally* in the Makefile.am (expanding to
empty if not defined).
Sure, that's more troublesome, but at least you can have this
working even now, I guess.
# Makefile.am:
AM_CPPFLAGS = ... $(MY_CPPFLAGS) ...
AM_CFLAGS = ... $(MY_CFLAGS) ...
AM_LDFLAGS = ... $(MY_LDFLAGS) ...
A single 'autoreconf'/'automake' invocation later and you can do:
# release build:
make MY_CFLAGS=-g MY_LDFLAGS=-fsanitize=address
# debug build:
make MY_CFLAGS=-O3 MY_CPPFLAGS=-DNDEBUG
Probably Nick's suggestion (a new option to ./configure or the
AC_HEADER_ASSERT macro) would be the most future-proof, but it
requires running ./configure each time you wish to change the build
type (which maybe is not a bad idea, it depends).
--
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
bug#20077: Allow more V= values for verbose output
Hello, Automakers!
My last patch for now, this time for
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20077:
- if $(V) is empty, use default verbosity,
- if $(V) = 0, be silent,
- if $(V) is neither empty nor 0, be verbose (not only with V=1, but
e.g. V=99).
Yes, requires some shell, but just like other stuff.
Note that this just switches verbosity off and on, doesn't pay any
attention if the user would want e.g. more verbosity with V=99 than
with V=1.
Regards,
Bogdan Drozdowski
--
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.orgFrom 6dd37c02408364350c4bb4b63705e1975d035eef Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Sat, 31 Dec 2022 20:17:35 +0100
Subject: [PATCH] Allow other V values for verbosity
---
m4/silent.m4| 2 +-
t/silent-gen.sh | 24
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/m4/silent.m4 b/m4/silent.m4
index d19c56e8a..a27ccc44b 100644
--- a/m4/silent.m4
+++ b/m4/silent.m4
@@ -53,7 +53,7 @@ case $enable_silent_rules in @%:@ (((
esac
if test $am_cv_make_support_nested_variables = yes; then
dnl Using '$V' instead of '$(V)' breaks IRIX make.
- AM_V='$(V)'
+ AM_V='$(shell if ( test "x$(V)" = "x0" ); then echo 0; elif ( test "x$(V)" = "x" ); then echo $(AM_DEFAULT_VERBOSITY); else echo 1; fi)'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
else
AM_V=$AM_DEFAULT_VERBOSITY
diff --git a/t/silent-gen.sh b/t/silent-gen.sh
index 1e2c588c7..e14d4b138 100644
--- a/t/silent-gen.sh
+++ b/t/silent-gen.sh
@@ -53,6 +53,18 @@ grep 'GEN ' stdout && exit 1
grep 'cp ' stdout
grep 'echo ' stdout
+$MAKE clean
+run_make -O V=99
+grep 'GEN ' stdout && exit 1
+grep 'cp ' stdout
+grep 'echo ' stdout
+
+$MAKE clean
+run_make -O V=vvv
+grep 'GEN ' stdout && exit 1
+grep 'cp ' stdout
+grep 'echo ' stdout
+
$MAKE clean
run_make -O V=0
grep 'GEN .*foo' stdout
@@ -79,4 +91,16 @@ grep 'GEN ' stdout && exit 1
grep 'cp ' stdout
grep 'echo ' stdout
+$MAKE clean
+run_make -O V=99
+grep 'GEN ' stdout && exit 1
+grep 'cp ' stdout
+grep 'echo ' stdout
+
+$MAKE clean
+run_make -O V=v
+grep 'GEN ' stdout && exit 1
+grep 'cp ' stdout
+grep 'echo ' stdout
+
:
--
2.35.1
bug#33573: Patch to replace symlinks with files
Karl Berry , Sat Dec 31 2022 03:30:42 GMT+0100
(Central European Standard Time)
Hi Bogdan,
Someone reported a bug for this, so I simply gave it a try.
Thank you! I didn't realize you were working on some of the old bugs.
That is great!
:)
To bring this one in particular to fruition: can you check what happens
when -c -a would need to overwrite a symlink? I think it should just
give a warning. Then the user can decide what to do.
It simply doesn't do or say anything, because the object already
exists (the subroutine simply leaves).
$ rm -f doc/texinfo.tex
$ automake --add-missing
doc/Makefile.am:1: installing 'doc/texinfo.tex'
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:48 doc/texinfo.tex ->
/usr/share/automake-1.16/texinfo.tex
$ automake --add-missing --copy
$
And, can you check that automake -a -f -c does in fact overwrite a
symlink with a copy? And, I guess, that -a -f, without the -c,
overwrites files with symlinks? (Or, if it gives an error now, that's ok
too.)
The combination '-a -f -c' does what's expected (replaces a symlink
with a regular file):
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:48 doc/texinfo.tex ->
/usr/share/automake-1.16/texinfo.tex
$ automake --add-missing --copy
$ automake --add-missing --copy --force-missing
$ ll doc/texinfo.tex
-rw--- 1 bogdan bogdan 374230 gru 31 19:49 doc/texinfo.tex
$
That's where my idea about updating the documentation comes from - may
not be clear enough.
Just '-a -f' does indeed replace regular files with symlinks:
$ ll doc/texinfo.tex
-rw--- 1 bogdan bogdan 374230 gru 31 19:49 doc/texinfo.tex
$ automake --add-missing --force-missing
$ ll doc/texinfo.tex
lrwxrwxrwx 1 bogdan bogdan 36 gru 31 19:51 doc/texinfo.tex ->
/usr/share/automake-1.16/texinfo.tex
$
$ automake --version
automake (GNU automake) 1.16.5
And that the test checks this stuff?
The change I'm implementing is tested by the test I've added. It
simply checks if after --copy the file is not a link:
$AUTOMAKE --add-missing --copy
test ! -h texinfo.tex || exit 1
(unneeded parts removed)
Sorry, but these are the kinds of nitty-gritty things that every
automake change needs to think about.
Yes, testing and portability is important, I know.
Just maybe make something clearer in the documentation and/or the help
message in such case, like:
Yes, agreed. No problem there.
I'm not subscribed
If you intend to keep working for a while on automake (I hope so), you
should subscribe to the mailing lists, especially bug-automake and
automake-patches. Unfortunately the debbugs software does not send mail
to everyone who has been on a given bug (not even the bug originator),
but only to the associated mailing list, as I understand it.
I see. We'll see what my future work on Automake will look like. Maybe
I could contribute something useful. Right now, I'm planning just one
more patch ("the last this year" - yes, it's still 2022 here :) ) and
later we'll see what time allows. I also have my own projects to look
after once in a while :).
Some guide like "to implement this and this, you need to change/add
subroutine that and that" would be nice for beginners.
I wish there would be some kind of roadmap or a list of interesting
ideas to-do in Automake. The "PLANS" doesn't have much, not for me, at
least... Otherwise, I don't know if e.g. Automake 2.0 is implemented
in 99% already or is it maybe just 1% and a full re-write is planned.
For the same reason, it is good to explicitly cc a bug's originator and
anyone else who has contributed to the bug, if you happen to have them.
I didn't want to send any notifications to the bugs in case my patches
get rejected for some reason (like they don't work on *BSD/some
antique Unix, don't match the programming style, etc., or are
completely against the idea).
Furthermore, Automake doesn't get so many releases, as I see, so even
implementing a fix doesn't mean that it will go to a release any time
soon.
and I didn't see them in the mailing list's archive :).
I see all your messages there now, I believe:
https://lists.gnu.org/archive/html/bug-automake/2022-12/threads.html
As I recall, there is a delay of up to an hour or maybe more before the
archives are updated. Unfortunately it does not happen when a message is
received; there's a separate polling cron job :(.
Right. They're there. Unfortunately, the Automake website points to
https://lists.gnu.org/archive/html/automake-patches/ instead :).
That's also where I send my mails to, not knowing they end up in
"bug-automake". Minor issue, but may be confusing, as you can see :).
Thanks.
--
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
[bug#60419] Allow user-defined 'tar' options
This is not a new bug.
My fix touches https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19615 and
allows the users to fix the defect by providing their own options to
'tar', like user/group IDs. This probably cannot be fixed portably and
securely in Automake, so at least the users have an option to fix the
issue themselves.
This "bug report" can be merged with 19615 or simply deleted.
--
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
bug#19614: Split packaging invocation to catch errors
Hello again.
This time a patch that splits 'tar ... | gzip/bzip2/whatever' into 2
commands.
Yes, this introduces a requirement for a "temporary" .tar file (and
i-node allocation, and filesystem free space/performance, and ...),
but gives gains (I hope they're gains):
1) when 'tar' exits with an error, 'make' handles it and stops the
packaging instead of letting the second packer in the chain possibly
create an incomplete package,
2) when 'tar' fails but does NOT exit with an error, I check the
standard error output for any messages. If present, I assume an error
and let 'make' handle it like in case 1).
GNU tar behaves nicely: when a problem is encountered, it stops with
an error exit code. The unfortunate default on my system, BSD tar,
doesn't. In case of a problem, just a warning is emitted, the exit
code is success even though files are missing from the resulting .tar
file. And there is no way to turn those warnings into errors. No idea
who thought of that. Hence manual checking stderr.
Feel free to modify the test if needed. I assumed all dist types are
available, but that may not always be the case - maybe some
conditionals are needed.
Regards,
Bogdan Drozdowski
--
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.orgFrom c3ee1c91693bf09c2815644933e6abd0afaccdd6 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Tue, 27 Dec 2022 22:39:58 +0100
Subject: [PATCH] Split packaging so tar error fails the build
---
lib/am/distdir.am | 42 ++-
t/list-of-tests.mk | 1 +
t/tar-split-cmd.sh | 62 ++
3 files changed, 99 insertions(+), 6 deletions(-)
create mode 100644 t/tar-split-cmd.sh
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index aa2be5238..5ccae5397 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -334,31 +334,56 @@ if %?TOPDIR_P%
GZIP_ENV = --best
.PHONY: dist-gzip
dist-gzip: distdir
- tardir=$(distdir) && $(am__tar) | eval GZIP= gzip $(GZIP_ENV) -c >$(distdir).tar.gz
+ tardir=$(distdir) && $(am__tar) > $(distdir).tar 2>$(distdir).err
+ test ! -s $(distdir).err || (cat $(distdir).err && \
+ rm -rf $(DIST_ARCHIVES) $(distdir).tar $(distdir).err && \
+ $(am__post_remove_distdir) && \
+ exit 1)
+ eval GZIP= gzip $(GZIP_ENV) $(distdir).tar -c >$(distdir).tar.gz
$(am__post_remove_distdir)
?BZIP2?DIST_ARCHIVES += $(distdir).tar.bz2
.PHONY: dist-bzip2
dist-bzip2: distdir
- tardir=$(distdir) && $(am__tar) | BZIP2=$${BZIP2--9} bzip2 -c >$(distdir).tar.bz2
+ tardir=$(distdir) && $(am__tar) > $(distdir).tar 2>$(distdir).err
+ test ! -s $(distdir).err || (cat $(distdir).err && \
+ rm -rf $(DIST_ARCHIVES) $(distdir).tar $(distdir).err && \
+ $(am__post_remove_distdir) && \
+ exit 1)
+ BZIP2=$${BZIP2--9} bzip2 -c $(distdir).tar >$(distdir).tar.bz2
$(am__post_remove_distdir)
?LZIP?DIST_ARCHIVES += $(distdir).tar.lz
.PHONY: dist-lzip
dist-lzip: distdir
- tardir=$(distdir) && $(am__tar) | lzip -c $${LZIP_OPT--9} >$(distdir).tar.lz
+ tardir=$(distdir) && $(am__tar) > $(distdir).tar 2>$(distdir).err
+ test ! -s $(distdir).err || (cat $(distdir).err && \
+ rm -rf $(DIST_ARCHIVES) $(distdir).tar $(distdir).err && \
+ $(am__post_remove_distdir) && \
+ exit 1)
+ lzip -c $${LZIP_OPT--9} $(distdir).tar >$(distdir).tar.lz
$(am__post_remove_distdir)
?XZ?DIST_ARCHIVES += $(distdir).tar.xz
.PHONY: dist-xz
dist-xz: distdir
- tardir=$(distdir) && $(am__tar) | XZ_OPT=$${XZ_OPT--e} xz -c >$(distdir).tar.xz
+ tardir=$(distdir) && $(am__tar) > $(distdir).tar 2>$(distdir).err
+ test ! -s $(distdir).err || (cat $(distdir).err && \
+ rm -rf $(DIST_ARCHIVES) $(distdir).tar $(distdir).err && \
+ $(am__post_remove_distdir) && \
+ exit 1)
+ XZ_OPT=$${XZ_OPT--e} xz -c $(distdir).tar >$(distdir).tar.xz
$(am__post_remove_distdir)
?ZSTD?DIST_ARCHIVES += $(distdir).tar.zst
.PHONY: dist-zstd
dist-zstd: distdir
- tardir=$(distdir) && $(am__tar) | zstd -c $${ZSTD_CLEVEL-$${ZSTD_OPT--19}} >$(distdir).tar.zst
+ tardir=$(distdir) && $(am__tar) > $(distdir).tar 2>$(distdir).err
+ test ! -s $(distdir).err || (cat $(distdir).err && \
+ rm -rf $(DIST_ARCHIVES) $(distdir).tar $(distdir).err && \
+ $(am__post_remove_distdir) && \
+ exit 1)
+ zstd -c $${ZSTD_CLEVEL-$${ZSTD_OPT--19}} $(distdir).tar >$(distdir).tar.zst
$(am__post_remove_distdir)
?COMPRESS?DIST_ARCHIVES += $(distdir).tar.Z
@@ -367,7 +392,12 @@ dist-tarZ: distdir
@echo WARNING: "Support for distribution archives compr
bug#33573: Patch to replace symlinks with files
Karl Berry , Fri Dec 30 2022 00:33:03 GMT+0100
(Central European Standard Time)
Another simple patch from my side: when '--copy' given to
'--add-missing', copy the standard files even if symlinks already exist.
I am not sure about changing the behavior here. Although the behavior
you propose is plausible, I fear that people might depend or expect on
failure if symlinks exist. It doesn't seem bad to me to require the user
to clean up their own symlinks, instead of assuming the overwriting
should be done. There's no way to know what the situation really is.
What I suggest is making the new behavior of deleting existing symlinks
iff -f is *also* given. If the user says "force" and "copy" then ok, we
can figure they're asking for what they're getting.
Wdyt? --thanks, karl.
Hi.
Sure, no problem from my side. This is actually already the current
behavior, from what I see (but I didn't check in detail). Someone
reported a bug for this, so I simply gave it a try.
The user has a point: --copy was given, but the files were not copied.
This may be a bit confusing. But this depends on the point of view, I
guess, and both behaviors have a point and can be correct, depending
on who you're asking. We can as well leave the current behavior, as
you say: make the user be clear about what they want and maybe allow
Automake one day behave differently (like exit with an error if a
symlink exists and -c given, but no -f, etc.).
Just maybe make something clearer in the documentation and/or the help
message in such case, like:
--help:
[...]
-c, --copy with -a, copy missing files if they or their
symlinks don't already exist (default is symlink)
-f, --force-missingforce update of standard files (with -c copies
the files even if symlinks exist)
Automake docs:
‘-c’
‘--copy’
When used with ‘--add-missing’, causes installed files to be
copied if files or symlinks don't already exist. The default is
to make a symbolic link.
P.S. I hope to reply to your other patch in the next day or two.
No problem - thanks for confirmation that they actually arrived. I
thought the mails got lost in some black hole, because I'm not
subscribed and I didn't see them in the mailing list's archive :).
--
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
[bug#60419] Allow user-defined 'tar' options
Hello again.
This time a patch that allows Automake users to provide their own
command-line options that will be passed to the 'tar' utility when
creating distribution packages.
This indirectly addresses bug#19615. The defect probably can't be
fixed in a portable and secure way, so Automake can at least allow the
user to specify the right options for him/her.
Feel free to rename the options as needed (like prefix/suffix with
"AM" or something).
Regards,
Bogdan Drozdowski
--
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.orgFrom 81c1e187fd98b3a4cec9a15fd3c4d1fd0471ad49 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Thu, 29 Dec 2022 19:46:41 +0100
Subject: [PATCH] Allow user-defined options for tar
---
doc/automake.texi| 6 +-
m4/tar.m4| 20 +-
t/list-of-tests.mk | 1 +
t/tar-opts-envvar.sh | 48
4 files changed, 64 insertions(+), 11 deletions(-)
create mode 100644 t/tar-opts-envvar.sh
diff --git a/doc/automake.texi b/doc/automake.texi
index 48744e24f..d53caef07 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8622,7 +8622,11 @@ More precisely, the gzipped @code{tar} file is named
@c See automake #9822.
@vindex TAR
You can set the environment variable @code{TAR} to override the tar
-program used; it defaults to @code{tar}. @xref{The Types of
+program used; it defaults to @code{tar}.
+You can set the environment variable @code{TAR_OPTIONS} to specify
+additional options to pass to the tar program when creating packages
+and @code{UNTAR_OPTIONS} for additional options to pass when unpacking.
+@xref{The Types of
Distributions}, for how to generate other kinds of archives.
For the most part, the files to distribute are automatically found by
diff --git a/m4/tar.m4 b/m4/tar.m4
index 8f4d2f213..ca00555eb 100644
--- a/m4/tar.m4
+++ b/m4/tar.m4
@@ -29,7 +29,7 @@ AC_SUBST([AMTAR], ['$${TAR-tar}'])
_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
m4_if([$1], [v7],
- [am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'],
+ [am__tar='$${TAR-tar} c $${TAR_OPTIONS} -hof - "$$tardir"' am__untar='$${TAR-tar} x $${UNTAR_OPTIONS} -f -'],
[m4_case([$1],
[ustar],
@@ -81,17 +81,17 @@ m4_if([$1], [v7],
for _am_tar in tar gnutar gtar; do
AM_RUN_LOG([$_am_tar --version]) && break
done
- am__tar="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$$tardir"'
- am__tar_="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$tardir"'
- am__untar="$_am_tar -xf -"
+ am__tar="$_am_tar $${TAR_OPTIONS} --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$$tardir"'
+ am__tar_="$_am_tar $${TAR_OPTIONS} --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$tardir"'
+ am__untar="$_am_tar -x $${UNTAR_OPTIONS} -f -"
;;
plaintar)
# Must skip GNU tar: if it does not support --format= it doesn't create
# ustar tarball either.
(tar --version) >/dev/null 2>&1 && continue
- am__tar='tar chf - "$$tardir"'
- am__tar_='tar chf - "$tardir"'
- am__untar='tar xf -'
+ am__tar='tar c $${TAR_OPTIONS} -hf - "$$tardir"'
+ am__tar_='tar c $${TAR_OPTIONS} -hf - "$tardir"'
+ am__untar='tar x $${UNTAR_OPTIONS} -f -'
;;
pax)
am__tar='pax -L -x $1 -w "$$tardir"'
@@ -99,9 +99,9 @@ m4_if([$1], [v7],
am__untar='pax -r'
;;
cpio)
- am__tar='find "$$tardir" -print | cpio -o -H $1 -L'
- am__tar_='find "$tardir" -print | cpio -o -H $1 -L'
- am__untar='cpio -i -H $1 -d'
+ am__tar='find "$$tardir" -print | cpio $${CPIO_OPTIONS} -o -H $1 -L'
+ am__tar_='find "$tardir" -print | cpio $${CPIO_OPTIONS} -o -H $1 -L'
+ am__untar='cpio $${UNCPIO_OPTIONS} -i -H $1 -d'
;;
none)
am__tar=false
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d82cf9c4d..1b2d91cfe 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1207,6 +1207,7 @@ t/tags-lisp-space.sh \
t/tags-pr12372.sh \
t/tar-ustar.sh \
t/tar-pax.sh \
+t/tar-opts-envvar.sh \
t/tar-opts-errors.sh \
t/tar-ustar-id-too-high.sh \
t/tar-override.sh \
diff --git a/t/tar-opts-envvar.sh b/t/tar-opts-envvar.sh
new file mode 100644
index 0..73836edbc
--- /dev/null
+++ b/t/tar-opts-envvar.sh
@@ -0,0 +1,48 @@
+#! /bin/sh
+# Copyright (C) 2004-2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or
bug#33573: Patch to replace symlinks with files
Hello, Automake gurus.
Another simple patch from my side: when '--copy' given to
'--add-missing', copy the standard files even if symlinks already exist.
Basically, the patch adds "if --copy given and a link exists, do NOT
exit" (+ a double-check of the object type if that would be needed on
some systems).
This may simplify the things for some users, although you may as well
update the documentation to say that giving "--force-missing" would
produce the same result.
Regards,
Bogdan Drozdowski
--
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.orgFrom d67b858d0254e3252f0a63270d2621317c512127 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Mon, 26 Dec 2022 18:26:28 +0100
Subject: [PATCH] Copy missing files if --copy given but a link exists (bug
33573)
---
bin/automake.in | 4 ++--
t/list-of-tests.mk| 1 +
t/missing-link-to-file.sh | 42 +++
3 files changed, 45 insertions(+), 2 deletions(-)
create mode 100644 t/missing-link-to-file.sh
diff --git a/bin/automake.in b/bin/automake.in
index c094234bc..dc4717f0f 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -7647,7 +7647,7 @@ sub required_file_check_or_copy
# '--force-missing' only has an effect if '--add-missing' is
# specified.
return
-if $found_it && (! $add_missing || ! $force_missing);
+if $found_it && (! $add_missing || (! $force_missing && ! ($copy_missing && -l $fullfile)));
# If we've already looked for it, we're done. You might wonder why we
# don't do this before searching for the file. If we do that, then
@@ -7693,7 +7693,7 @@ sub required_file_check_or_copy
# Windows Perl will hang if we try to delete a
# file that doesn't exist.
- unlink ($fullfile) if -f $fullfile;
+ unlink ($fullfile) if (-f $fullfile or -l $fullfile);
if ($symlink_exists && ! $copy_missing)
{
if (! symlink ("$libdir/$file", $fullfile)
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d82cf9c4d..395c8689a 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -712,6 +712,7 @@ t/mdate3.sh \
t/mdate4.sh \
t/mdate5.sh \
t/mdate6.sh \
+t/missing-link-to-file.sh \
t/missing-version-mismatch.sh \
t/missing3.sh \
t/am-missing-prog.sh \
diff --git a/t/missing-link-to-file.sh b/t/missing-link-to-file.sh
new file mode 100644
index 0..23d6d2cde
--- /dev/null
+++ b/t/missing-link-to-file.sh
@@ -0,0 +1,42 @@
+#! /bin/sh
+# Copyright (C) 2002-2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+# Make sure Automake will install real files when --copy is given even
+# if symlinks already exist.
+
+. test-init.sh
+
+cat >> configure.ac < Makefile.am << 'END'
+info_TEXINFOS = foo.texi
+END
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+#ls -l
+
+$AUTOMAKE --add-missing --copy
+
+#ls -l
+
+test ! -h texinfo.tex || exit 1
+
+:
--
2.35.1
bug#54063: - special case] Try .texi.in when .texi missing
Hello, Automake gurus.
I have a special case for bug#54063. In my case, the .texi file is
missing during 'automake' time, because it is being created by
'configure' from a matching .texi.in file. That file exists during
'automake' time, so it can be scanned for the output filename - no
need to use /dev/null in such simple case.
The attached patch (with a test) should fix this issue. Hope I've done
everything the right way.
--
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.orgFrom 80d896457f1ad251f6e6e3bb2310c19127296798 Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Mon, 26 Dec 2022 18:22:52 +0100
Subject: [PATCH] Fix error when texi missing and texi.in present (a case of
bug 54063)
---
bin/automake.in | 16 ++--
t/list-of-tests.mk | 1 +
t/txinfo-no-texi-but-texi-in.sh | 43 +
3 files changed, 58 insertions(+), 2 deletions(-)
create mode 100644 t/txinfo-no-texi-but-texi-in.sh
diff --git a/bin/automake.in b/bin/automake.in
index c094234bc..b4a4e69a7 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3063,8 +3063,20 @@ sub scan_texinfo_file
my ($filename) = @_;
# If the source file doesn't exist, we'll fall back below.
- my $source = -e $filename ? $filename : "/dev/null";
- my $texi = new Automake::XFile "< $source";
+ if (! -e $filename)
+{
+ if (-e ($filename . '.in'))
+{
+ # $filename.texi.in exists: assume $filename.texi is generated
+ # and parse $filename.texi.in as the real input
+ $filename .= '.in';
+}
+ else
+{
+ $filename = '/dev/null';
+}
+}
+ my $texi = new Automake::XFile "< $filename";
verb "reading $filename";
my ($outfile, $vfile);
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d82cf9c4d..5f1c903eb 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1232,6 +1232,7 @@ t/txinfo-no-installinfo.sh \
t/txinfo-no-repeated-targets.sh \
t/txinfo-no-setfilename.sh \
t/txinfo-no-setfilename-no-inputs.sh \
+t/txinfo-no-texi-but-texi-in.sh \
t/txinfo-other-suffixes.sh \
t/txinfo-override-infodeps.sh \
t/txinfo-override-texinfo-tex.sh \
diff --git a/t/txinfo-no-texi-but-texi-in.sh b/t/txinfo-no-texi-but-texi-in.sh
new file mode 100644
index 0..112a4b34b
--- /dev/null
+++ b/t/txinfo-no-texi-but-texi-in.sh
@@ -0,0 +1,43 @@
+#! /bin/sh
+# Copyright (C) 2022 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <https://www.gnu.org/licenses/>.
+
+# Check if Automake doesn't exit with an error for Texinfo output files
+# without a direct input file, but with a matching input file processed
+# by 'configure' (file.texi.IN).
+
+. test-init.sh
+
+echo AC_OUTPUT >> configure.ac
+
+cat > Makefile.am << 'END'
+info_TEXINFOS = main.texi
+END
+
+cat > main.texi.in << 'END'
+\input texinfo
+@setfilename testmain.info
+@settitle main
+@node Top
+Hello world.
+@bye
+END
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+
+grep 'testmain.info:' Makefile.in
+
+:
--
2.35.1
