On 5/28/24 11:27, Jason Merrill wrote:
AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
relies on features from a particular standard.
It's called "_AC_PROG_CXX_STDCXX_EDITION_TRY" with a leading underscore,
which means it's private to Autoconf and apps shouldn't (and I
d.From 056518b94ecd487bcbefdb69046b3f52c4168222 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 28 May 2024 09:31:11 -0700
Subject: [PATCH] AC_PROG_CXX no longer adjusts C++ language version
* lib/autoconf/c.m4 (_AC_CXX_CXX98_TEST_GLOBALS)
(_AC_CXX_CXX98_TEST_MAIN, _AC_CXX_CXX11_TEST_GLOBALS)
(_AC_CXX_CXX11_TES
On 2024-05-28 01:20, Jonathan Wakely wrote:
I am not aware of any distro ever changing the default -std setting for g++
or clang++. Are you attempting to solve a non-problem, but introducing new
ones?
If it's a non-problem for C++, why does Autoconf upgrade to C++11 when
the default is C++98?
On 2024-05-27 12:18, Jakub Jelinek wrote:
Maybe respect the carefully chosen compiler default (unless explicitly
overridden in configure.ac)?
Autoconf gave up on that idea long ago, as we had bad experiences with
compiler defaults being chosen for the convenience of distro maintainers
rather
can discourage C++23 by putting ': ${ac_cv_prog_cxx_cxx23=no}'
early in configure.ac.
As I mentioned earlier, I volunteered to document this sort of thing if
Zack doesn't come up with something nicer soon.From b2f28ce66ea1618b50e14085059ce512d7245300 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date:
me. The idea
would be to test for features that programs actually need, not to test
for every little minor detail. Obviously there are judgment calls.From e6c9cb69c8c0a4ef9ce0538d7b4106dad3d7ad47 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 26 May 2024 07:04:19 -0700
Subject: [PATCH 1/2] P
On 2024-05-01 05:33, Nick Bowler wrote:
Just configure with CFLAGS=-std=c99 or whatever.
I was thinking along the same line. We should keep things simple. Using
CFLAGS is a documented way to specify the compiler flags, and ideally
there would be no need for a new feature in this area.
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
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
Thanks for the suggestion; I installed the attached. Part of the idea is
for the first line to be a complete summary.From 02f232c67156da2d353c986fd77d408db5084f79 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 30 Apr 2024 11:48:31 -0700
Subject: [PATCH] Improve VLA wording in NEWS
Thanks
nto 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/autoconf/2
hassles with
ancient packages that still use K C functions, C23 means these
packages need to be changed to use function prototypes anyway.
Comments welcome.From 653956f44683e1daed9827de429590bdd2e317e7 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 30 Apr 2024 10:26:50 -0700
Subject
patch, which is less ambitious but should
address the original problem report. The attached patch doesn't preclude
your suggestion, which can be done later as needed.From e9fee73dba5d2156abc48734b5a9faff89dcdc11 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 25 Apr 2024 14:47:20 -0700
Update of sr #111054 (group autoconf):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks for
On 2024-04-27 15:39, dmitrii.pasech...@cs.ox.ac.uk wrote:
It's for nauty, a well-known program to deal with graph isomorphisms
etc. I've made a Gentoo patch herehttps://bugs.gentoo.org/921138
and I wanted to upstream it.
Oh my, that is indeed in an undocumented/hacky part of autoconf, one
On 2024-04-27 14:06, dmitrii.pasech...@cs.ox.ac.uk wrote:
Thus I got questions whether a patch for a build system I submitted for
a project is OK, as it uses an undocumented variable (thus, perhaps,
unstable).
Although it's poorly designed and not documented and not stable, the
patch may be
Update of sr #110983 (group autoconf):
Status: Confirmed => Done
___
Follow-up Comment #6:
I installed
On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
Is bootstrap intended to be reliable from within a tarball? I thought
the bootstrap script was not included in tarballs because it wasn't
designed to be ran that way, and the way it is designed may not give
expected results.
verquoted macro". Since the diagnostic can be caused by misspelled
macro names, which do occur, I thought it wise to retain a mention of
that in the diagnostic. I installed the attached patch.From 7a6347d1d785ee26f205154fdadf7f6f81797f92 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 6 Apr
Follow-up Comment #3, sr #111044 (group autoconf):
[comment #2 comment #2:]
> neither `diff` nor `awk` (and arguably not even `sed`) should be an implicit
dependency.
Not sure I'd go that far. The
[https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html GNU
Coding Standards for
, as their
values may be corrupted in the cache. This is my usual style elsewhere
and perhaps Autoconf should adopt it. Of course if we'd done that we
would likely never have spotted this harmless error in Emacs
configure.acFrom e34ebc0ccc6c27e7e1217baad9ca74dd7bea4c37 Mon Sep 17 00:00:00 2001
From: Paul
On 2024-02-06 20:37, Nick Bowler wrote:
The right place to fix this problem is in Emacs.
I don't see this problem in current (bleeding-edge Savannah) Emacs. Sam,
which Emacs are you talking about?
(and they
proliferate), the manual could be better about what *is* portable and I
installed the attached.
From 163dade069be64df7cce5c6d48fdcb56188a6f60 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 3 Feb 2024 21:37:49 -0800
Subject: [PATCH] =?UTF-8?q?Document=20=E2=80=98cp=E2=80=99=20limitations
On 2/2/24 12:20, Russ Allbery wrote:
I thought ln || ln -s was the standard
recipe here
Yes, "cp -l" isn't required by POSIX and is not portable in general. For
example, on AIX 7.1:
$ cp -l a b
cp: Not a recognized flag: l
Usage: cp [-fhipHILPU][-d|-e] [-r|-R]
On 1/31/24 03:23, Simon Josefsson via Bug reports for autoconf wrote:
https://buildd.debian.org/status/fetch.php?pkg=libidn2=loong64=2.3.7-1=1706360630=0
Here's the crucial part of that log:
configure:15961: checking for size_t
configure:15961: gcc -c -g -O2 -ffile-prefix-map=/<>=.
On 2024-01-28 22:36, Mike Frysinger wrote:
On 04 Mar 2020 13:43, Bob Friesenhahn wrote:
...
Autoconf itself has not been released since 2012. This feels like a
long time to me, although not quite a decade.
eh ? autoconf-2.69 was released in 2012, but that isn't the latest.
autoconf-2.72 was
Check out m4_text_wrap.
3a813b3b2f9f3a8ec0df95e444b6fb54267775a9 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 16 Jan 2024 21:19:31 -0800
Subject: [PATCH] Fix typo in previous patch
---
lib/autoconf/types.m4 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/autoconf/types.m4 b/lib/autoconf
Thanks for reporting that bug. I installed the attached on Savannah;
please give it a try.From e5fae45ae39f471cba5415c21d93e5bc407eb8c7 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 16 Jan 2024 20:20:06 -0800
Subject: [PATCH] =?UTF-8?q?Fix=20=E2=80=98long=20long=E2=80=99=20checks=20
On 1/10/24 14:03, Bruno Haible wrote:
When visiting https://www.gnu.org/software/autoconf/manual/ the first
hyperlink (_HTML (2220K bytes)_) works, but the second hyperlink
(_HTML_) lands in a 404 error page.
Thanks, it should be working now. I don't know why it wasn't working
earlier. The
On 2024-01-02 10:40, Alan Coopersmith wrote:
On 12/21/23 13:46, Alan Coopersmith wrote:
On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.
In that shell, when I run:
printf "test" /dev/full
it prints nothing and
On 2023-12-21 19:56, Nick Bowler wrote:
On 2023-12-21 19:34, Paul Eggert wrote:
ulimit -f 0
trap "" XFSZ
printf "test" >test || echo failed with status $?
which issues the following diagnostics on Solaris 10 /bin/sh:
printf: write error: File too large
On 2023-12-21 13:46, Alan Coopersmith wrote:
On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.
In that shell, when I run:
printf "test" /dev/full
it prints nothing and $? is set to 0.
This appears to be a
On 2023-12-21 13:19, Zack Weinberg wrote:
Sorry, I'm with GNU here: failure to report errors on writing to stdout
is a bug. No excuses will be accepted.
Agreed. printf commands that silently succeed when they can't do the
requested action are simply broken.
Even if one is not convinced by
I'm seeing the same bug with Autoconf 2.69 on RHEL 7. Tarball attached
with the configure.ac that I used, and the output of "autoheader" and
"autoconf". "autoconf" complains:
configure.ac:5: warning: The macro `AC_FOREACH' is obsolete.
configure.ac:5: You should run autoupdate.
On 2023-12-11 13:48, Paul Eggert wrote:
On 12/11/23 10:19, Zack Weinberg wrote:
we lowered it to 5.6.0
again in 05e295b60cfdf378b7ed8c1f8563a5644d5d4689
A minor point: in that commit message I mentioned that Solaris 10 (which
has only Perl 5.8.4) was supported through January 2024
Follow-up Comment #2, sr#110983 (group autoconf):
Do you have an idea for a patch? We could put the patch into Gnulib's copy of
AC_SYS_LARGEFILE now, and it'll see more real-worldish testing that way.
___
Reply to this item at:
Thanks for the diagnosis. Proposed patch attached. I haven't installed
it on Savannah, as Autoconf is currently in a prerelease freeze and Zack
wants a look-see at all patches before they go in.From 0845c59400378f3441686cbcde48b49fce638f97 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri
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 Hardening Guide
On 12/12/23 06:36, Sergey Kosukhin wrote:
1. Some of my macros are written from scratch (they use the Autoconf
macros, of
course, including the internal ones like _AC_COMPILER_EXEEXT_CROSS). This
case
looks like the easiest one to me and I guess, I can add my own license
(preferably, BSD-3c) and
On 12/11/23 08:24, Michael Orlitzky wrote:
I think the two fixes we're waiting for in the next release are,
*https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016
*https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a7595
The first commit is about
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's not
On 12/11/23 10:19, Zack Weinberg wrote:
we lowered it to 5.6.0
again in 05e295b60cfdf378b7ed8c1f8563a5644d5d4689
A minor point: in that commit message I mentioned that Solaris 10 (which
has only Perl 5.8.4) was supported through January 2024. On that same
day (!) Oracle announced[1] that
Follow-up Comment #3, sr#110612 (group autoconf):
[comment #1 comment #1:]
> If you or anyone else has ideas for how to tell "configure" from "sh
configure", I am all ears.
If it's Bash, "$_" (at the start of the script) should tell you. This is true
for other shells (e.g., it works with
Follow-up Comment #0, sr#110971 (group autoconf):
[comment #4 comment #4:]
> It seems to me it will be more robust to filter out the troublesome error
message
Not really, as BusyBox plausibly might change that diagnostic's wording and
then the filtering will stop working. Conversely, if the
Follow-up Comment #3, sr #110971 (project autoconf):
Wouldn't this patch be simpler?
diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4
index d06d18c4..8226a7c7 100644
--- a/lib/autoconf/programs.m4
+++ b/lib/autoconf/programs.m4
@@ -700,7 +700,7 @@ if test -z "$MKDIR_P"; then
.
However, I don't know whether that will address the problem you observed.From 49ab3a4c5756d7ef40b03111f4c8a351d6bca7b8 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 1 Dec 2023 09:58:37 -0800
Subject: [PATCH] Be more conservative about cache timestamps
MIME-Version: 1.0
Content-Type: text/plain
Update of sr #110961 (project autoconf):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks for the
On 10/17/23 11:16, Zack Weinberg wrote:
On Sun, Oct 15, 2023, at 3:43 AM, KO Myung-Hun wrote:
How about this ?
1. create and close a temporary file
2. chmod() on it
3. re-open it with O_TRUNC ?
The trouble is, on a multi-user system, any time you do any operation
by name on a file whose full
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.
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.
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
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
On 2023-09-20 05:52, Evgeny Grin wrote:
If you need have a function with "file offset" argument then use either
'uint64_t'
Although your other advice is good, this one is suspect. I'm glad I
didn't follow similar advice to use 'int32_t' or 'long' for file offsets
back in the day.
Also, to
On 2023-09-19 01:52, Sébastien Hinderer wrote:
Are you saying that there should normally not be any
undef in the config headers for macros whose name starts with a _ sign?
No, it's normal when Autoconf is used as intended. What's not normal is
that your package is including after including
On 2023-09-18 02:55, Sébastien Hinderer wrote:
the project currently has the convention of including
system headers before its ocnfiguraiotn headers
Ouch. The Autoconf manual explicitly says "The package should ‘#include’
the configuration header file before any other header files"
On 9/11/23 13:23, Russ Allbery wrote:
I suspect that the aswer to the original question is "don't worry about
it, just use AC_SYS_LARGEFILE, because no system you will build on will
need the CC modification anyway."
Yes, that's the advice I'd give.
One other caveat is that if you want to port
On 8/19/23 04:55, Gavin Smith wrote:
I was concerned with the case of a person trying to read INSTALL in a
non-UTF-8 terminal. This is possible with e.g. "LC_ALL=C xterm" or in
some MS-Windows terminal windows.
It's also possible with people running on a console that doesn't even
support
ncy in naming across different packages, i.e.
is "bootstrap" the most widely used name?
Hard to say. I prefer 'bootstrap' but there's definitely an 'autogen.sh'
and perhaps 'autopull.sh' camp. Which is why Gnulib supports both.
From cb6fbab55de1e9660e110857ae248a70a8b48c5b Mon Sep 17 00:00:
On 8/17/23 09:41, Zack Weinberg wrote:
What are the most common things people need to do in a "bootstrap"
script that *aren't* covered by `autoreconf -i`?
Some need to call autoreconf -i with other arguments, or run it multiple
times. For example, Emacs runs 'autoreconf -fi -I m4' at the top
rap’. The attached patch tries to clarify this point.
The ./bootstrap approach is increasingly popular, which is why we
recently updated the Autoconf manual to cover it.From b2b69331d6257a64ee520a2a219e49c62c70d4e1 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Tue, 15 Aug 2023 17:21:03
On 2023-08-14 14:14, Bob Friesenhahn wrote:
To me, an arbitrary bootstrap script is both a privacy and security
hazard without the user carefully studying the design of the script.
The same is true for ‘configure’, which is 2,182,586 bytes in my copy of
coreutils. Or for Makefiles (even
Thanks, I installed that.
00:00:00 2001
From: Paul Eggert
Date: Sat, 24 Jun 2023 15:00:37 -0700
Subject: [PATCH] =?UTF-8?q?*=20build-aux/gitlog-to-changelog:=20don?=
=?UTF-8?q?=E2=80=99t=20quote=20`like=20this'?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
build-aux
as well so those grave accents are
gone. While I was at it I ended up rewriting the other stuff.From d8ca8b323873e5cd9d969a062f70b31db450ba53 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 24 Jun 2023 14:39:34 -0700
Subject: [PATCH] Shorten and improve INSTALL
MIME-Version: 1.0
Content-Type
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's
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
On 2023-05-22 02:35, Po Lu wrote:
printf is not portable; it is missing, both as a built-in to
ksh and a command, on Ultrix 4.5, as well as (AFAIK) Solaris 2.6, the
first of which is important for historical purposes, and the second of
which is still found in the wild in some fields.
In
On 2023-05-17 12:25, Florian Weimer wrote:
But then HAVE_GETPAGESIZE probably should not succeed spuriously because
of an implicit function declaration.
I hope that the only platforms that should use that old getpagesize
code, are platforms so old that implicit function declarations work,
:00:00 2001
From: Paul Eggert
Date: Wed, 17 May 2023 11:50:27 -0700
Subject: [PATCH] Improve AC_FUNC_MMAP comments
* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Add comment.
---
lib/autoconf/functions.m4 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf
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.gnu.org
On 5/11/23 07:08, Zack Weinberg wrote:
Unless someone
knows of a bug in some old kernel where the first*disk block* of an oversized
mmap would be properly zeroed and then the rest of it would be memory garbage
Yes, that was the reason I went back to configuring a getpagesize
substitute: I
should go back to invoking getpagesize despite the hassle of
configuring it. I installed the attached further patch; please give it a
try.From 33c26d2700f927432c756ccf7a4fc89403d35b95 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 10 May 2023 22:57:27 -0700
Subject: [PATCH] Fix port
the test so
that it doesn't use getpagesize. This is a conservative-enough approach
that it should be OK to squeeze it in before the next Autoconf release.From 028526149ee804617a302ccef22cc6adbda681b0 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 10 May 2023 17:20:49 -0700
Subject: [PATCH
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,
On 2023-04-20 09:02, Bruno Haible wrote:
I see two issues:
1) For AC_SYS_YEAR2038 and AC_SYS_YEAR2038_RECOMMENDED, when run on a 32-bit
platform (x86) with glibc < 2.34, there is no
checking for <$CC> option for timestamps after 2038...
line in the output. It _looks_like_ the macro was not
On 4/25/23 17:09, Jeffrey Walton wrote:
$ uname -p
unknown
I don't see how that's an Autoconf issue, as Autoconf uses 'uname -p'
only on platforms where it's likely to produce useful info, and
GNU/Linux is not one of those platforms. For more, see:
On 2023-04-16 08:18, Bruno Haible wrote:
Yes. Here are adjusted patches.
Thanks, I installed those.
ECOMMENDED as it's one less thing to test before a
release and nobody appears to need that new macro.From d9178438c5ae39936c9dbb789f2ffb3344c860c1 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 19 Apr 2023 13:17:00 -0700
Subject: [AUTOCONF PATCH] Tone down year-2038 changes
Thanks, I installed that 2023-03-03 doc patch into Autoconf master.
Thanks for looking into this.
+[AC_REQUIRE([AC_CANONICAL_HOST])
Is there some way we can do this without requiring AC_CANONICAL_HOST?
We're close to a release for Autoconf, and requiring this at the last
minute for AC_SYS_LARGEFILE is a bit of a stretch.
That is, instead of
On 4/14/23 09:02, Bruno Haible wrote:
On the other hand, when I create a gnulib testdir with an
AC_SYS_YEAR2038_REQUIRED invocation:
./gnulib-tool --create-testdir --dir=... --single-configure
year2038-required stat
it fails during the configure stage on MSVC (both 64-bit and 32-bit):
It
Thanks, I installed those into Gnulib and into Autoconf.
_AC_SYS_LARGEFILE_TEST_CODE doesn't use
AC_DEFUN, so I'll cc this to Zack (who wrote that code) to see whether
we can change to AC_DEFUN and AU_DEFUN here.From 938f2d844515a7cbc8ba3d40d0e57bfce9971969 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 3 Apr 2023 09:12:40 -0700
Subject: [PATCH
Thanks, I took a quick look at all the patches and see no issues.
On 2023-04-02 18:30, Zack Weinberg wrote:
how about I revise this patch to remove the case for
freebsd* | darwin*, and make no other changes?
Yes, sounds good, thanks.
On 2023-04-02 12:42, Zack Weinberg wrote:
Cross-referencing gnulib’s getgroups.m4 I see that there *are*
current-generation Unixes with bugs in getgroups that are worth
worrying about (notably, FreeBSD mishandles an error case even in
CURRENT).
That error case is not very important, as
That macro dates back to /usr/include header files that would play
tricks like this
#define _IO(n, x) (('n'<<8)+x)
#define TIOCFOO _IO(T, 1)
and would expect TIOCFOO to be equivalent to (('T'<<8)+1). This sort of
trick worked with K C compilers but does not work with C89+. To
that the build fails when running the
Autoconf 2.71 that comes with Ubuntu, so I suppose that's progress. I
installed the attached.
From 794182506c3c5814d48b2fc4d832770f608ce0ef Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 1 Apr 2023 20:25:13 -0700
Subject: [PATCH] Support underquoted callers better
e.From 713d9822bbfb2923115065efaefed34a0113f8a1 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 1 Apr 2023 16:44:03 -0700
Subject: [PATCH] Fix timing bug on high-speed builds
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Problem reported by Bogdan via Jacob Bachmeyer in:
On 2023-03-28 13:57, Richard Purdie wrote:
From a regression/failure point of view, the worrying issue is the
gpgme/mpg123 issue on x32 which also appears for musl 32 and 64 bit x86
targets.
https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/6881/steps/11/logs/stdio
On 2023-03-28 09:12, Frederic Berat wrote:
Regarding EGREP, although I agree in principle this can be solved by using
AS_CASE, I'd argue that the component actually required AC_PROG_EGREP.
Just following up on this since I see that I didn't reply to everybody
in this thread. Today I
Autoconf 2.71. I installed the attached, which is close to what I
proposed earlier except it leaves help-extract.pl alone (i.e.,
help-extract.pl continues to use Perl 5.10 features) and it adjusts some
commentary.From 05e295b60cfdf378b7ed8c1f8563a5644d5d4689 Mon Sep 17 00:00:00 2001
From: Paul Eggert
GREP. Any objections to that
change?
Not from me. I gave that a shot by installing the attached little patch.
I hope this is the sort of thing you had in mind; if not, please feel
free to improve it.From 232cab527897bcdf4d55492d41af73d31905bda5 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Dat
On 2023-03-30 12:40, Jacob Bachmeyer wrote:
The closest I have seen so far was the
use of the regex \K escape in build-aux/help-extract.pl, except that the
tool in question only needs to be run by Autoconf maintainers because
its outputs are included in release tarballs
Oh, in that case
On 2023-03-30 06:06, Zack Weinberg wrote:
Are you, Jacob Bachmeyer, volunteering to maintain the Perl scripts in
autoconf and automake, for at least the next several years, and in
particular to test compatibility with these very old versions of Perl?
Although testing Jacob's little patch with
candidate
on Solaris 10, which ships with Perl 5.8.4. Although Solaris 10 is
obsolescent Oracle says they will support it through January 2024.From 6067ea81d1b879871c76320025349f068bf3743b Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 29 Mar 2023 13:41:50 -0700
Subject: [PATCH] Go back
On 2023-03-29 13:12, Danny McClanahan wrote:
- I've been perusing clones of the autoconf and automake codebases and
I've been unable to locate the logic that actually executes each test in
sequence.
That's because sequencing is implicit. Autoconf generates 'configure',
which is a shell
Thanks for the explanation. I installed those two patches into Automake.
On 2023-03-28 08:21, Warren Young wrote:
Surely Solaris 10 (shipped in 2005) is relegated to the role of porting target,
getting nothing but a “dist” tarball?
Good point. I'll cc this to Dagobert Michelsen, who maintains the
Autoconf port for Solaris 10. Dagobert, are people still running
1 - 100 of 2014 matches
Mail list logo
