On Tue, Jan 21, 2025, at 4:53 PM, Dima Pasechnik wrote:
> pytest, a popular Python testing tool/framework, uses files named
> conftest.py for its configuration. OTOH many autoconf macros run
> "rm -f conftest*", clobbering conftest.py in the directory where
> ./configure
Hello,
pytest, a popular Python testing tool/framework, uses files named
conftest.py for its configuration. OTOH many autoconf macros run
"rm -f conftest*", clobbering conftest.py in the directory where
./configure lives. In our case at least, it's the topmost directory.
I tri
ry arguments is defective).
But what really impresses me is how someone stuck this diagnostic in at
some point, but didn't go fix this instance as part of the deal:
$ printf 'a\tb' | LC_ALL=en_US.UTF-8 tr '[:cntrl:]' '[ *]'
Bad string
That's some rock star p
is your problem it suggests that part of your script is messing
with the locale, when it shouldn't be.
I installed the attached doc patch into Autoconf master to document more
of the tr issues.From b40645caa91dad69ba8a14ef53dc0013e12497fc Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon
Hi Paul,
At 2024-12-02T11:45:30-0800, Paul Eggert wrote:
> On 2024-12-01 19:03, G. Branden Robinson wrote:
> > The problem is that the test exercising `$cmd` succeeds on Solaris
> > 10 when it should not.
>
> Why shouldn't the test succeed? Solaris 10 /usr/bin/tr supports
> character classes like
On 2024-12-01 19:03, G. Branden Robinson wrote:
The problem is that the test exercising `$cmd` succeeds on Solaris 10
when it should not.
Why shouldn't the test succeed? Solaris 10 /usr/bin/tr supports
character classes like [:cntrl:].
On Sun, Dec 1, 2024, at 10:03 PM, G. Branden Robinson wrote:
[...]
> So the "good tr" branch is being taken in the configure script, but
> not in vivo at a shell prompt. I can't explain this.
I have no immediate explanation either. On the Solaris 10 machine
from the GCC compile farm, I'm seeing
On 12/2/24 00:47, G. Branden Robinson wrote:
Hi Jacob,
Thanks for the quick response.
I happen to be up late here.
At 2024-12-01T23:48:09-0600, Jacob Bachmeyer wrote:
On 12/1/24 21:03, G. Branden Robinson wrote:
[...]
[...]
Okay, I did. The mystery would appear to deepen.
The same grep g
pt. I can't explain this.
>
> First question: what shell is configure actually running under?
>
> Autoconf makes an effort to find a plausible POSIX shell, and /bin/sh
> on Solaris 10 is not it. The copy of bash-3.2 you used for
> interactive testing was probably not it
On 12/1/24 21:03, G. Branden Robinson wrote:
[...]
So the "good tr" branch is being taken in the configure script, but not
in vivo at a shell prompt. I can't explain this.
First question: what shell is configure actually running under?
Autoconf makes an effort to find a
[please reply to the groff@ as well; I am not subscribed to autoconf@]
Apparently I am having a moment of dumb.
In preparation for a 1.24 release, I am trying to get groff building on
Solaris 10, which has yet again received a stay of execution from
Oracle.[1]
https://blogs.oracle.com/solaris
Hi List,
In September, I sent the following patch to autoconf-patches, and it hasn't
been responded to. Should I be emailing them somewhere else?
https://lists.gnu.org/archive/html/autoconf-patches/2024-09/msg0.html
(Please CC me in replies; I am not subscribed)
Thanks,
-- Jack
On 5/2/24 04:01, Florian Weimer wrote:
* Alan Coopersmith:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042
This change:
#ifndef __cplusplus
+#if __STDC_VERSION__ >= 199901L
+#include
+#else
typedef enum
{
false = 0,
* Alan Coopersmith:
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042
This change:
#ifndef __cplusplus
+#if __STDC_VERSION__ >= 199901L
+#include
+#else
typedef enum
{
false = 0,
true
} bool;
+#endif
# define RT_C_DECLS
features.
This approach works because GCC treats a later -std= option as
overriding an earlier one. Does the same thing happen with other compilers?
If not, there should be a way for the builder to say "Don't try to mess
with the C standard version; just leave $CC alone". With cur
On 2024-04-30 21:59, Jacob Bachmeyer wrote:
> Paul Eggert wrote:
>> While we're adding to our wishlist that should also be a
>> configure-time option, not merely something in configure.ac. That
>> way, one could test a tarball's portability without having to modify
>> the source code.
This is alre
Paul Eggert wrote:
On 2024-04-30 12:03, Zack Weinberg wrote:
Another reason to want this type of control is if you are
deliberately trying
to ensure that your code continues to compile with old compilers.
While we're adding to our wishlist that should also be a
configure-time option, not mer
I wasn't there when the magic was written, but I would have expected
AC_PROG_CC_C89, AC_PROG_CC_C99 and possibly new AC_PROG_CC_Cx macros
to select a version of the C standard. Apparently that wasn't their
job and now they've been deprecated in 2.70.
r standard even if we patch the configure.ac script and run autoreconf
with a newer autoconf release.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
On 2024-04-30 12:03, Zack Weinberg wrote:
Another reason to want this type of control is if you are deliberately trying
to ensure that your code continues to compile with old compilers.
While we're adding to our wishlist that should also be a configure-time
option, not merely something in conf
On Tue, Apr 30, 2024, at 2:53 PM, Paul Eggert wrote:
> On 2024-04-30 11:49, Zack Weinberg wrote:
>> I think we ought to prioritize giving
>> package authors a way to control which edition of the C standard AC_PROG_CC
>> will select, rather than just always using the most recent one we know about.
>
On 2024-04-30 11:49, Zack Weinberg wrote:
I think we ought to prioritize giving
package authors a way to control which edition of the C standard AC_PROG_CC
will select, rather than just always using the most recent one we know about.
Yes, we could add a new macro to do that, or a new argument t
On Tue, Apr 30, 2024, at 2:43 PM, Paul Eggert wrote:
> On 2024-04-30 11:24, Alan Coopersmith wrote:
>> the biggest source of problems was not function prototypes,
>> but the change of "true" and "false" to no longer be acceptable lvalues,
>> and of "bool" to be a builtin type.
>
> Thanks for mentio
into that problem. I
installed the attached.From 76ac2c1d735a3cc1646b452d38633ec1c6a3ce0d Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 30 Apr 2024 11:41:36 -0700
Subject: [PATCH] Mention C keywords in NEWS
Thanks to Alan Coopersmith for mentioning this in:
https://lists.gnu.org/r/autoc
On 4/30/24 10:51, Paul Eggert wrote:
I installed the attached patch into Savannah master to get the ball rolling on
Autoconf supporting C23.
Most C23 compatibility gizmos are now done in Gnulib. However, Autoconf's
AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC. Although thi
I installed the attached patch into Savannah master to get the ball
rolling on Autoconf supporting C23.
Most C23 compatibility gizmos are now done in Gnulib. However,
Autoconf's AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC.
Although this may cause a few backward compatib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We are pleased to announce stable release 2.72 of GNU Autoconf.
2.72 consists largely of bug fixes. The most significant changes are
support for the upcoming 2024 edition of the C standard (aka âC23â)
and a mechanism for enabling 64-bit time_t
On Thu, Dec 21, 2023, at 10:07 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> On Thu, Dec 21, 2023, at 3:27 AM, Frederic Berat wrote:
>>> 11: autoconf: forbidden tokens, basic FAILED (tools.at:481)
>>> So far I got it on aarch64 and s390x. Timing iss
Zack Weinberg wrote:
On Thu, Dec 21, 2023, at 3:27 AM, Frederic Berat wrote:
On Wed, Dec 20, 2023 at 10:22 PM Zack Weinberg wrote:
I also get this one that fails once in a while (3 failures out of 12
executions):
11: autoconf: forbidden tokens, basic FAILED (tools.at:481
On Wed, Dec 20, 2023, at 7:41 PM, Alan Coopersmith wrote:
> On 12/20/23 08:16, Zack Weinberg wrote:
>> autoconf-2.72e is now available. This is a *release candidate*
>> for autoconf 2.72 final. Please test it as thoroughly as possible.
>> Testing in Windows- and Darwin-bas
On Thu, Dec 21, 2023, at 3:27 AM, Frederic Berat wrote:
> On Wed, Dec 20, 2023 at 10:22 PM Zack Weinberg wrote:
> I also get this one that fails once in a while (3 failures out of 12
> executions):
>
> 11: autoconf: forbidden tokens, basic FAILED (tools.at:481)
>
On 12/20/23 08:16, Zack Weinberg wrote:
autoconf-2.72e is now available. This is a *release candidate*
for autoconf 2.72 final. Please test it as thoroughly as possible.
Testing in Windows- and Darwin-based environments would be
particularly helpful. Testing your own project’s configure.ac
On Wed, Dec 20, 2023 at 10:22 PM Zack Weinberg wrote:
> On Wed, Dec 20, 2023, at 2:03 PM, Frederic Berat wrote:
> > I admit I usually don't build the package for i386 since autoconf isn't
> > arch dependent, but I did it this time and there are few test failures:
>
On Wed, Dec 20, 2023, at 2:03 PM, Frederic Berat wrote:
> I admit I usually don't build the package for i386 since autoconf isn't
> arch dependent, but I did it this time and there are few test failures:
>
> 420: AC_SYS_LARGEFILEFAILED (s
On Wed, Dec 20, 2023 at 5:17 PM Zack Weinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> autoconf-2.72e is now available. This is a *release candidate*
> for autoconf 2.72 final. Please test it as thoroughly as possible.
> Testing in Windows- and Darwin-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
autoconf-2.72e is now available. This is a *release candidate*
for autoconf 2.72 final. Please test it as thoroughly as possible.
Testing in Windows- and Darwin-based environments would be
particularly helpful. Testing your own projectâs
On Wed, Dec 13, 2023, at 9:29 AM, Florian Weimer wrote:
> configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
> <https://github.com/samtools/htslib/pull/1711>
Trunk autoconf produces a configure script for that library which reports
"checking for getpagesize...yes&q
Florian Weimer writes:
> * Zack Weinberg:
>
>> Paul Eggert made some changes back in May that attempt to address this:
>> commits 028526149ee804617a302ccef22cc6adbda681b0 and
>> 33c26d2700f927432c756ccf7a4fc89403d35b95. Do you have a minimized
>> test case for the problem (both the original pr
On 2023-12-12 01:32, Arsen Arsenović wrote:
Paul Eggert writes:
Although it'll be helpful for Autoconf to work by default with those two
options, it's not essential because it's bad advice for builders to *configure*
with all the options suggested in "Compiler Options H
conf (_SC_PAGESIZE)
> +# elif defined _SC_PAGE_SIZE
> +# define getpagesize() sysconf (_SC_PAGE_SIZE)
> +# elif HAVE_GETPAGESIZE
> +int getpagesize ();
> +# else
>
> This should indeed isolate this test from the outcome of the getpagesize
> check because it now prefers s
lse
This should indeed isolate this test from the outcome of the getpagesize
check because it now prefers sysconf.
I can't test this with htslib unfortunately because I'm not able to
build autoconf from sources for some reason.
Thanks,
Florian
On Wed, Dec 13, 2023, at 4:27 AM, Florian Weimer wrote:
> I'm not aware of any generic issues in current-ish autoconf. Some
> macros needed fixing, but not the basic ones modified by those two
> commits. Even autoconf 2.69 is mostly fine—you have to go back much
> farther to f
* Michael Orlitzky:
> On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
>> All:
>>
>> Will the latest version of autoconf work by default when the compiler has
>> these options enabled?:
>> -Werror=implicit-int
>> -Werror=implicit-function-de
Hi Paul,
Paul Eggert writes:
> On 12/11/23 07:55, David A. Wheeler wrote:
>> Will the latest version of autoconf work by default when the compiler has
>> these options enabled?:
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>
> Although it&#
7;gcc -std=c17 -Wold-style-definition' does warn.
As far as I know, the next Autoconf release should work with
-Wold-style-definition, regardless of whether you're using C2x or an
earlier C, so long as the earlier C is not so old that the compiler
lacks -Wold-style-definition or equi
On 12/11/23 07:55, David A. Wheeler wrote:
Will the latest version of autoconf work by default when the compiler has these
options enabled?:
-Werror=implicit-int
-Werror=implicit-function-declaration
Although it'll be helpful for Autoconf to work by default with those two
options, it&
On Mon, Dec 11, 2023, at 11:24 AM, Michael Orlitzky wrote:
> On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
>> Will the latest version of autoconf work by default when the compiler
>> has these options enabled?:
>>-Werror=implicit-int
>>-Werror=im
On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
> All:
>
> Will the latest version of autoconf work by default when the compiler has
> these options enabled?:
> -Werror=implicit-int
> -Werror=implicit-function-declaration
>
I think the two fixes we're waiti
All:
Will the latest version of autoconf work by default when the compiler has these
options enabled?:
-Werror=implicit-int
-Werror=implicit-function-declaration
If not, can that be fixed at least in the most common cases (e.g., by declaring
exit() so it's no longer an implicit functio
On Mon, Dec 4, 2023 at 12:29 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Thu, 2023-11-30 at 16:51 -0500, Zack Weinberg wrote:
> > We are pleased to announce beta release 2.72d of Autoconf. (Versions
> > 2.72a, 2.72b, and 2.72c were development sn
On Mon, Dec 4, 2023, at 6:28 AM, Richard Purdie wrote:
> On Thu, 2023-11-30 at 16:51 -0500, Zack Weinberg wrote:
>> We are pleased to announce beta release 2.72d of Autoconf. (Versions
>> 2.72a, 2.72b, and 2.72c were development snapshots, not official alpha
>> or beta releas
On Thu, 2023-11-30 at 16:51 -0500, Zack Weinberg wrote:
> We are pleased to announce beta release 2.72d of Autoconf. (Versions
> 2.72a, 2.72b, and 2.72c were development snapshots, not official alpha
> or beta releases.)
>
> 2.72 will be a minor bug-fix release. The most sign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We are pleased to announce beta release 2.72d of Autoconf. (Versions
2.72a, 2.72b, and 2.72c were development snapshots, not official alpha
or beta releases.)
2.72 will be a minor bug-fix release. The most significant changes
are support for the
Maybe it should also accept bare numbers?
My preference would be to not do that (or, alternatively, have 4-digit
years as the *only* format).
> Because Autoconf *used* to support this many years ago, if someone
> puts the word "traditional" in the list,
Not sure it's w
recognized as a synonym for "c89". Maybe it should also accept bare
numbers?
Support for C17 and C24 is abstractly desirable as well, but since
Autoconf doesn't currently know how to probe for those editions, it
can wait until we do add the probes.
> Default behavior is uncha
efiles
* Some '-std=xxx' flag is added *after* user CFLAGS in configure / Makefiles
The first case is an intentional break of autoconf design.
The second option is very badly designed configuration, not supported at
all.
The last one is incorrect as well and intentional prevention of
u
On Wed, Oct 11, 2023, at 9:34 AM, Evgeny Grin wrote:
> On 11.10.2023 16:29, Bob Friesenhahn wrote:
>> The problem is that Autoconf is defeating the recipient's freedom to
>> select the compilation settings used.
>>
>> The person who is compiling the software
On 11.10.2023 16:29, Bob Friesenhahn wrote:
The problem is that Autoconf is defeating the recipient's freedom to
select the compilation settings used.
The person who is compiling the software should be able to specify the
parameters to use used.
It works, actually.
./configure C
some other problem.
The problem is that Autoconf is defeating the recipient's freedom to
select the compilation settings used.
The person who is compiling the software should be able to specify the
parameters to use used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.t
I'd be happy to sign FSF copyright assignment forms, if required.
Regards,
/Niels
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 77ff1af8..adb718f3 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1561,6 +1561,26 @@ m4_define([_AC_C_C11_OPTIONS]
gt; diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
> index 77ff1af8..adb718f3 100644
> --- a/lib/autoconf/c.m4
> +++ b/lib/autoconf/c.m4
> @@ -1561,6 +1561,26 @@ m4_define([_AC_C_C11_OPTIONS], [
> -std=gnu11
> ])
>
> +# _AC_C_CHECK_STANDARD_VERSION
> +# --
On 2023-10-08, Niels Möller wrote:
> I would have expected that every input that is valid c89 also is valid
> c99, so that support for c99 strictly implies support for c89. But there
> may be some corner case I'm not aware of.
It is not true in general that a valid C89 program is also valid
C99,
way, however I have vague memories of a
compiler that dropped support for K&R function definitions many years
ago, long before GCC did. Since Autoconf seeks portability, including
to non-free systems, preferring C89 but accepting C99 is reasonable to
express. There may be non-free compilers ou
e same list style for both.
Hmm, I'm not sure it's a good idea to have AC_C_STANDARD_VERSION use
that convention, i.e., AC_C_STANDARD_VERSION([c99, c89]). Do any other
user-visible autoconf macros use that convention?
Instead, I'm trying to stick with whitespace separation
t have c99 either.
Free compilers may behave that way, however I have vague memories of a
compiler that dropped support for K&R function definitions many years
ago, long before GCC did. Since Autoconf seeks portability, including
to non-free systems, preferring C89 but accepting C99 is re
gt; ./configure CC='gcc -std=c89'
>
>This used to catch accidental use of more recent C language features,
>like declarations not at the start of a block.
>
>However, I just realized that with recent autoconf (I'm now using
>autoconf-2.71), AC_PROG_CC has become mo
On 2023-10-07 02:03, Niels Möller wrote:
there's some impedance mismatch between the whitespace separated list to
AC_C_STANDARD_VERSION, and the comma-separated list required by m4_map
Yes, let's use the same list style for both.
to me; list in order of preference, and whitespace
separation. That's consistent with AC_PROG_CC. But that means that
AC_C_STANDARD_VERSION([c89 c99])
is a bit meaningless; if compiler has c89, that's what will be used, and
if it doesn't have c89, it won't have c99 either. (Alternativ
Thanks for looking into this.
Some comments.
This doesn't let you say "I want either c89 or c99, but not c11".
+ m4_ifdef([_AC_C_STANDARD_VERSION_LIST],
+[m4_fatal([AC_PROG_C_STANDARD_VERSION should only be used once], 1)])
Why have this check?
How about something simpler, like replaci
Niels Möller writes:
> "Zack Weinberg" writes:
>
>> This is currently not possible, but you are not the only person who has
>> asked for it to be made possible, and it's on our near-future list.
>> However, none of the core Autoconf developers currently ha
On Fri, 6 Oct 2023, Zack Weinberg wrote:
This is currently not possible, but you are not the only person who has
asked for it to be made possible, and it's on our near-future list.
However, none of the core Autoconf developers currently have time to work
on it. Might you be willing to put
"Zack Weinberg" writes:
> This is currently not possible, but you are not the only person who has
> asked for it to be made possible, and it's on our near-future list.
> However, none of the core Autoconf developers currently have time to work
> on it. Might you be wi
is supported.
...
> Is there some way of telling autoconf to be less helpful, and attempt to
> add options only when needed to enable some particular version (in my
> case c89, less conservative projects might want to target c99 in the
> same way), but not add anything to enable even later lan
lized that with recent autoconf (I'm now using
autoconf-2.71), AC_PROG_CC has become more helpful, and in this
configuration it automatically changes CC to 'gcc -std=c89 -std=gnu11'.
It's documented at
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2
wrote:
| | > I think that the autoconf and m4 manuals could have improved
| | > cross-references to the regular expression syntax actually supported
| | > in autoconf via GNU m4:
| |
| | Perhaps specific patches?
| |
| | Cross-manual links are a bit of a pain to
> > On 24/9/23 11:03, Nick Bowler wrote:
> >> The word AC_CHECK_DEFINE is not found anywhere in the Autoconf
> >> source code or documentation.
> >
> > My guess would be that the 3rd party is the autoconf archive because
> > they provide both AX_CHE
Thanks Nick and Peter for your analysis.
Yes, the "AC_" prefix fooled me, that AC_CHECK_DEFINE belongs to autoconf.
> On 2023-09-23, Nick Bowler wrote:
> > On 2023-09-23, Detlef Riekenberg wrote:
> >> AC_CHECK_DEFINE(__unix, CFLAGS="-DFOUND__unix $CFLAG
On 24/09/2023, Peter Johansson wrote:
> Hi Detlef and Nick,
>
> On 24/9/23 11:03, Nick Bowler wrote:
>> The word AC_CHECK_DEFINE is not found anywhere in the Autoconf
>> source code or documentation.
>
> My guess would be that the 3rd party is the autoconf archive
Hi Detlef and Nick,
On 24/9/23 11:03, Nick Bowler wrote:
The word AC_CHECK_DEFINE is not found anywhere in the Autoconf
source code or documentation.
My guess would be that the 3rd party is the autoconf archive because
they provide both AX_CHECK_DEFINE and AC_CHECK_DEFINE
http
ux__ $CFLAGS")
[...]
> So it sounds like there must be some third party code involved which
> is defining this macro (and this code is defining macros in the AC_*
> namespace to make it look like it came from Autoconf when in fact it
> did not).
Just to add, you don't need any t
Hi,
On 2023-09-23, Detlef Riekenberg wrote:
> During testing of tcc 0.9.28rc,
> I found a strange bug in autoconf 2.71 with `AC_CHECK_DEFINE` for
> `__unix__`.
The word AC_CHECK_DEFINE is not found anywhere in the Autoconf
source code or documentation.
So I am afraid it is a bit dif
Hi autoconf team.
During testing of tcc 0.9.28rc,
I found a strange bug in autoconf 2.71 with `AC_CHECK_DEFINE` for `__unix__`.
For comparsion, i added checks for "__unix" and "__linux__":
Overview:
* [__unix__] always found, but the log text is crippled
* __unix__ never fo
y and hence
>>> used the value of $debug set by Autom4te::General::getopt.
>>>
>>> I'm not sure if load_configuration somehow needs the temporary directory or
>>> if parse_args could be moved to precede all of the main program. I'll try
>>> that
gt;>
>> I'm not sure if load_configuration somehow needs the temporary directory or
>> if parse_args could be moved to precede all of the main program. I'll try
>> that next but wanted to keep you informed of my ongoing investigation.
>>
>> Kind regard
ng 1, i.e. !$debug while previously Autom4te::General had a custom END
>> block that deleted the temporary files conditionally and hence used the
>> value of $debug set by Autom4te::General::getopt.
>>
>> I'm not sure if load_configuration somehow needs the tem
s conditionally and hence used the value
> of $debug set by Autom4te::General::getopt.
>
> I'm not sure if load_configuration somehow needs the temporary directory or
> if parse_args could be moved to precede all of the main program. I'll try
> that next but wanted
temporary directory or if
parse_args could be moved to precede all of the main program. I'll try that
next but wanted to keep you informed of my ongoing investigation.
Kind regards, Thomas
> On Sep 4, 2023, at 13:15 , Thomas Jahns wrote:
>
> Dear autoconf maintainers,
>
Dear autoconf maintainers,
when trying to port another piece of software to use autoconf 2.71 I noticed a
problem I wanted to debug with the autoreconf --debug option. But it seems
autoconf now deletes the temporary files in all paths.
While the 2.69 version I'm currently using preserves
On 23-05-26 19:25, Paul Eggert wrote:
| On 2023-05-25 03:25, Luke Mewburn wrote:
| > I think that the autoconf and m4 manuals could have improved
| > cross-references to the regular expression syntax actually supported
| > in autoconf via GNU m4:
|
| Perhaps specifi
On 2023-05-25 03:25, Luke Mewburn wrote:
I think that the autoconf and m4 manuals could have improved
cross-references to the regular expression syntax actually supported
in autoconf via GNU m4:
Perhaps specific patches?
Cross-manual links are a bit of a pain to maintain, but if it&#
On 2023-05-24 12:14, Luke Mewburn wrote:
11: autoconf: forbidden tokens, basic FAILED (tools.at:485)
41: autom4te preselections FAILED (tools.at:1545)
Are these known issues on RHEL 8 / CentOS / Fedora style systems?
Is it worth sending more details
Hi,
(This may be relevant to the m4 list as well, which I'm not currently
subscribed to.)
tl;dr:
==
I think that the autoconf and m4 manuals could have improved
cross-references to the regular expression syntax actually supported
in autoconf via GNU m4:
autoconf:
- m4_bpat
Hi,
While preparing some bug fixes for autoconf, I ran the testsuite
from a clean git clone (branch master as at commit 8e7281d7)
on CentOS Stream 8, and there were two failures:
## GNU Autoconf 2.72c.24-8e728 test suite
Paul Eggert wrote:
> I installed the attached patch to address the problem you mentioned.
Thank you.
Good wording is important here; the new wording is better than what I had
proposed.
Bruno
00:00 2001
From: Paul Eggert
Date: Sat, 13 May 2023 09:56:33 -0700
Subject: [PATCH] Improve AC_SYS_YEAR2038_RECOMMENDED diagnostic
* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_RECOMMENDED):
Do not recommend gcc -m64, as that likely will not work.
Problem reported by Bruno Haible in:
https://lists.gn
2] https://lists.gnu.org/archive/html/autoconf/2023-04/msg00030.html
Bruno Haible wrote:
[...]
* In the other cases
- 32-bit OS, or
Perhaps this has already been addressed, but what prevents a 32-bit OS
from nonetheless having a 64-bit time_t?
Do the tests accommodate the possibility of time_t being long long?
They should: there is no reason to ex
> If we could come up with a reliable way to distinguish between the two,
> I suppose we could use the abovementioned message on bi-arch platforms
> and some other message (e.g., "Wouldn't it be better to build for a
> platform that won't stop working in 2038?&qu
On 5/6/23 06:09, Bruno Haible wrote:
3) The hint
Did you mean to build a 64-bit binary? (E.g.,
'CC="gcc -m64"'.)
should not occur on a 32-bit OS. It should only occur on bi-arch systems
(64-bit OS, 32-bit $CC).
If we could come up with a reliable way to distinguish between the two,
adiction. These are simply different test cases.
I was testing without gnulib first, because
- if there are issues without gnulib, it is easier to investigate
than with gnulib,
- if there are issues with gnulib but not without gnulib, the
investigation should focus on gnulib/m4/largefil
1 - 100 of 3855 matches
Mail list logo
