Re: AC_FUNC_MMAP test fails on AIX for MAP_FIXED: who's at fault?

[Zack Weinberg]

On Wed, Jul 31, 2024, at 5:39 PM, Howard Chu wrote:
> Zack Weinberg wrote:
>> Finally, I got two failures I wasn't expecting to see at all:
>>
>> test: writes visible via shared map... FAIL: data mismatch
>> test: shared map alterations visible via read... FAIL: data mismatch
>>   amd64-unknown-openbsd7.5
>>   mips64-unknown-openbsd7.5
>
> As I said in an earlier email, OpenBSD is known to not have a unified
> buffer cache, so this type of failure is expected there.

Regrettably, I didn't understand that that was what you meant when you
said OpenBSD doesn't have a unified buffer cache.  Thanks for the
clarification.

It is not clear to me from
https://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
https://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html
whether POSIX declares OpenBSD to be out of spec in this regard.
There is clear language in the specification of write() requiring
write() operations to be visible to all subsequent read() operations
("After a write() to a regular file has successfully returned, any
successful read() from each byte position in the file that was modified
by that write shall return the data specified by the write() for that
position until such byte positions are again modified") but the closest
thing I can find to any such requirement for mmap() is "If MAP_SHARED is
specified, write references shall change the underlying object".
If there's relevant text anywhere else in POSIX I haven't found it.

For Autoconf's purposes, what we really need to know is: on OpenBSD,
what does an application need to do after it modifies a MAP_SHARED
mapping using memory writes to make those writes visible to read()?
And conversely, what does it need to do after it modifies a file
using write() to make those writes visible to existing MAP_SHARED
mappings?  The answers to those questions will get written into our
"Portable C Programming" manual section for mmap, and will also
clarify whether we ought to provide a macro that checks for this,
er, let's call it a behavioral variation for now.

zw

Re: First draft of application to Sovereign Tech Fund

[Zack Weinberg]

On Wed, Jul 31, 2024, at 9:56 AM, Detlef Riekenberg wrote:
> For all contributions, they have to be checked, commented and later
> committed by the few busy people with commit rights.

Because of this ...

> We need a list of "todo projects", similar to what is available for
> projects, who apply for Google Summer of Code.

... and because neither Automake nor Autoconf currently has a list of
"good first bugs/projects to work on", and also because both are
abnormally difficult to write good patches for, I'd suggest that the
most useful way for a new contributor to help at this time is to analyze
the backlog of bug reports.  Classify them as recent regressions,
longstanding bugs, or desirable new features.  Estimate the importance
and urgency of fixing each.  Identify affected projects and/or systems.
Construct minimized test cases.  Identify root causes.  Try to estimate
how difficult it would be to write a patch for each ... but don't actually
write the patches, not at first, not until you've spent a couple months
on understanding the bugs.

zw

Re: AC_FUNC_MMAP test fails on AIX for MAP_FIXED: who's at fault?

[Zack Weinberg]

On Wed, Jul 31, 2024, at 7:56 AM, Yury V. Zaytsev wrote:
> So it appears to be not as trivial as “mmap on AIX has been broken for
> ages”, but rather it seems that up to some version of AIX (4-5?), it
> used to require unmapping the address first. After that IBM still kept
> it as the default behavior, but added spec-compliant behavior to the
> set of behavioral changes invoked by the XPG_SUS_ENV variable, most
> likely out of backwards compatibility concerns…

Thanks for digging into this, Yury.  I have access to AIX machines via
the GCC compile farm but I would not have been able to find this.

> So, the bottom line, I guess, is still that the autoconf test is
> correct in terms of checking for spec compliant behavior. It’s of no
> help to developers who want mmap on AIX, but at least it prevents
> the worst.
>
> Probably breaking the macro down as Zack has suggested would be
> helpful so that MAP_FIXED behavior could be examined separately if
> needed, but still, for my use case, it’s better to just get rid of
> mmap altogether.

Independently, I have written a new test program that probes for a
superset of the things that the existing AC_FUNC_MMAP test probes for.
My goal for this program is to determine which problems are still
present on current-generation operating systems, and how far back in
time we have to go to encounter the problems that no longer show up
today. It's attached to this email, and also posted for convenient
download at
<https://paste.sr.ht/~zackw/69f6fe801335583216de012b2d2f86c7d43afd76>.

I ran this program on all the operating systems conveniently
available to me, all of which are reasonably up to date.  A fully
correct implementation of mmap (as far as the test goes) will print
something like

note: using 4096 bytes as page size.
note: define MMAP_PROBE_PAGESIZE if this is incorrect.
test: zero-fill after EOF (shared mapping)... ok
test: zero-fill after EOF (private mapping)... ok
test: writes visible via shared map... ok
test: shared map alterations visible via read... ok
test: shared map alterations visible via second map... ok
test: private read-write map of file opened read-only... ok
test: alter private map of file opened read-only... ok
test: alter private map of file opened read-write... ok
test: replace existing mapping... ok

I get this result on:
  x86_64-pc-linux-gnu
  x86_64-unknown-freebsd13.3
  aarch64c-unknown-freebsd14.0
  x86_64-unknown-netbsd10.0
  sparc-sun-solaris2.10
  sparc-sun-solaris2.11
  powerpc-ibm-aix7.1.5.0 (with XPG_SUS_ENV=ON)
  powerpc-ibm-aix7.3.1.0 (with XPG_SUS_ENV=ON)

I get the previously discussed MAP_FIXED failure on both powerpc-ibm-aix7
machines if I don't set XPG_SUS_ENV=ON.

Finally, I got two failures I wasn't expecting to see at all:

test: writes visible via shared map... FAIL: data mismatch
test: shared map alterations visible via read... FAIL: data mismatch
  amd64-unknown-openbsd7.5
  mips64-unknown-openbsd7.5

AC_FUNC_MMAP currently doesn't test MAP_SHARED at all, but maybe it
*should*...

For right now, I'd like to ask everyone who reads this message to run
the test program on operating systems not listed above, and on older
versions of operating systems that *are* listed above.  The most
interesting reports will be of current OSes that fail one or more
tests, and of version thresholds where the set of failing tests
*changes* for some OS.  No-longer-developed OSes whose final version
fails some tests are also interesting.  Testing contemporary OSes on
CPUs I didn't try is probably *not* going to turn up anything
interesting since the VM layer should be mostly machine-independent
these days, but you never know.

Please also pass the program and the request along to anyone you know
who might have weird old Unixes to try.

zw/* Test for correct functionality of several corner cases of mmap().

  Copyright 2000-2017, 2020-2024 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 3 of the License, or
  (at your option) any later version.  See <https://www.gnu.org/licenses>
  for precise terms and conditions.

  Originally part of Autoconf, original design of this test by Mike
  Haertel and Jim Avera, expanded substantially by Zack Weinberg.  */

/* This program tests for a variety of bugs which were known
   to exist in real implementations of mmap, mostly in the 1990s:

- If a file is mapped with MAP_SHARED, modifications to the mapped
  memory area should be visible to read(), and modifications to
  the file via write() should be visible in the mapped area.
  Current versions of OpenBSD fail this test.
  Old versions of FreeBSD and NetBSD may also fail this test,
  according to notes in the guts of autoconf's code.

- If a file is mapped twice, both times with MAP_SHARED,

Re: AC_FUNC_MMAP test fails on AIX for MAP_FIXED: who's at fault?

[Zack Weinberg]

On Mon, Jul 29, 2024, at 9:17 AM, Bob Friesenhahn wrote:

>> I suppose that an app that needs mmap but not MAP_FIXED (which is 
>> allowed by POSIX sans XSI) could write its own special-purpose 
>> Autoconf macro for that. That being said, if you're planning to use 
>> mmap on AIX good luck; you may need it[5].

> The complaints seem to primarily be about archaic systems. 
> GraphicsMagick optionally uses mmap() for some use cases, where there is 
> substantial benefit.  There have not been any complaints about it, 
> including under IBM's AIX.  At one time (long ago) I noticed that Linux 
> was the worst performer out of the then current OSs when using mmap() 
> for file I/O. Behavior is subject to change.
>
> Regardless, using mmap() for file I/O is no magic bullet.  It transfers 
> all control to the OS, and the hardware.  The program may be 
> de-scheduled (waiting for page-in, or even page-out) when it could 
> otherwise be doing something useful.

It's not really any of autoconf's business what a program wants to use
mmap() for, _except_ insofar as it affects how autoconf probes for mmap.
I'd guess that modern software uses mmap _without_ MAP_FIXED much more
often than it uses it _with_ MAP_FIXED, which makes autoconf's insistence
on checking for XSI semantics of MAP_FIXED in its only "check for mmap"
macro a little silly.

I don't want to change what AC_FUNC_MMAP does because it seems like that
could break under-maintained old programs that _do_ expect AC_FUNC_MMAP
to check for MAP_FIXED.  However, perhaps we could have a new family of
AC_FUNC_MMAP_* macros that check for specific subsets of mmap functionality
that are generally useful, off the top of my head

- check for the basic functionality of mapping files at kernel-selected
  locations (this can probably just invoke AC_CHECK_HEADERS_ONCE([sys/mman.h])
  and AC_CHECK_FUNCS_ONCE([mmap]))

- figure out the right way to call it to request anonymous memory at a
  kernel-selected location (MAP_ANON vs MAP_ANONYMOUS vs /dev/zero)

- detect whether MAP_FIXED will replace an existing mapping, and/or
  whether MAP_FIXED_NOREPLACE exists

We should probably also document the AIX issues in the "writing portable
C programs" section of the manual if we don't already.

Can any of you think of other subsets of mmap functionality that are
worth supplying a test for in autoconf?  Do any of you have time to
work on patches for any or all of this?

zw

Re: autoconf's AC_PROG_GNU_M4 macro (from m4.m4) and the --gnu flag to gm4

[Zack Weinberg]

On Sun, Jul 21, 2024, at 12:40 AM, Eric Gallager wrote:
> Hi, I'm writing because I will occasionally see messages like the
> following from CI systems (specifically GitHub Actions' macOS runners)
> when they attempt to run autoconf:
>
> /Applications/Xcode_15.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gm4:
> unrecognized option `--gnu'
> Try 
> `/Applications/Xcode_15.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gm4
> --help' for more information.
> autom4te: error: gm4 failed with exit status: 1
>
> My first attempt at fixing this was hacking in support for the `--gnu`
> flag for Apple's copy of gm4, but since the apple-oss-distributions
> organization has pull requests turned off, there isn't much I can
> really do there to get Apple to upstream it:
> https://github.com/apple-oss-distributions/gm4/compare/main...cooljeanius:apple-gm4:gnu_flag

Yeah, don't bother.  Their copy of GNU M4 is too old for us _anyway_.
They ought to either get over their GPLv3 phobia or stop shipping GNU
utilities at all.

> I think what is happening here is that
> [g]m4's support for the `--gnu` flag gets detected at autoconf's
> configure time, but then when the user overrides the M4 variable to
> point to a different [g]m4, the M4_GNU variable stays set to whatever
> it was first detected as, which might not match up with what the new
> [g]m4 supports. I'm wondering if there's some way that autoconf could
> shift around the timing of these checks so that it doesn't try passing
> `--gnu` to an installation of [g]m4 that doesn't support it?

It probably _would_ make more sense to do that check at runtime, in
autom4te.  I'll think about how to make that happen.

zw

[RFC PATCH] m4sugar: clean up iteration impls and test them more thoroughly

[Zack Weinberg]

This rather lengthy patch has almost no user visible effects; it's all
about testing the m4sugar layer more thoroughly.  I would appreciate
a second pair of eyes on it, but I think it's pretty low risk despite
the amount of code being moved around, and I will probably merge it in
about a week if no one comments.

All of the m4sugar macros that iterate over a macro argument list
have two implementations.  One is in m4sugar.m4 and operates by
recursion, processing some of the leading elements of $@ and then
re-invoking itself on the remainder, using `m4_shift`.  This is the
most straightforward way to iterate over an argument list in M4, but
it is quadratically expensive in GNU M4 1.4.x.

Thus, we have a second implementation of each such macro in
m4sugar/foreach.m4.  Those work by generating a temporary helper macro
that references each argument by number, no matter how many there are,
so that $@ only needs to be expanded once.  This is linear in the size
of the argument list, but less portable (as it uses $10 and up) and
much harder to understand.  According to the comments in foreach.m4,
GNU M4 1.6.x is going to be cleverer about recursive macro expansion,
and the straightforward implementations will be *faster* than the
non-recursive ones.  So we’ve kept the straightforward implementations
around, and m4_init replaces them with the foreach.m4 implementations
if it detects M4 1.4.x is in use.

I say “according to” and “is going to be” because those comments were
written in 2008 and, as of 2024, the latest released version of GNU M4
is still from the 1.4.x series.  Development branches for versions
1.6.x and 2.x exist (see )
but have not seen any activity in the past fourteen and eight years,
respectively.

This is a *problem* for us because:

 - If you forget to call m4_init, you get the recursive implementations,
   which might mean whatever weird one-off test you’re doing hangs.
 - Some of the recursive implementations have fallen out of sync with
   the foreach implementations, as seen in the previous two patches.
   (I noticed this because I forgot to call m4_init in some weird
   one-off tests.)

This patch therefore makes the following changes:

 - All the recursive implementations are moved from m4sugar.m4 to a
   new file m4sugar/recursive.m4.

 - m4sugar.m4 loads m4sugar/foreach.m4 at freeze time, so if you
   forget to call m4_init, you get the foreach implementations.
   This should also make Autoconf an eensy bit faster in the normal
   case. m4_init loads m4sugar/recursive.m4 if it detects M4 1.6.x or later.

 - Since we now require M4 1.4.8 or later, some compatibility glue for
   M4 1.4.[67] is removed from m4_init.

 - AT_CHECK_M4SUGAR and AT_CHECK_M4SUGAR_TEXT now, by default, run
   their test twice, once with the recursive implementations forced and
   once with the foreach implementations forced, and fails the overall
   test if the results are not identical.  I was expecting this to
   expose more mismatches between the two implementations but it did not.

   Currently I don’t think it’s necessary to do this for any of the
   other tests, but I could have missed something.

   Only two subtests need to alter the new default: both are specifically
   testing for linear performance with large argument lists.  Each of
   these is split from its parent test and divided into two new tests,
   one which compares the foreach implementation to the *default*
   implementation and runs unconditionally, and a second which tests
   only the recursive implementation and is skipped with M4 1.4.x.
   Both pairs of tests have constant expected output, so we still get
   a cross-check between recursive and foreach when M4 1.6.x is used.

 - To make it easy for AT_CHECK_M4SUGAR to force one implementation or
   the other, there is now an internal override macro that can be
   defined before invoking m4_init.  It only affects the choice of
   recursive.m4 versus foreach.m4, not any of the other things m4_init
   does if it detects M4 1.6.x.

 - autom4te encapsulates use of the override macro using --language:
   --language m4sugar-recursive-iteration will always use the recursive
   implementations and --language m4sugar-foreach-iteration will always
   use the foreach implementations.  (There are no equivalents of these
   for any of the other languages built on top of m4sugar.)

 - To make *that* possible, autom4te grows support for -D and -U on
   its own command line, which are directly mapped to -D and -U on
   m4’s command line.  This should be the only user visible change in
   the patch.

I did not test this patch with M4 1.6.x or 2.x, but I *did* locally
comment out the AT_SKIP_IFs on the tests that are expected to be slow
with M4 1.4.x.  They pass (providing more evidence that both
implementations are now in sync) but they take several minutes each to
run on my 2018-era workstation (verifying that foreach.m4 is still
necessary).

* 

[COMMITTED 0/4] four small unrelated bug fixes

[Zack Weinberg]

While working on the AC_LOG_CMD/AC_LOG_FILE project
(see https://lists.gnu.org/archive/html/autoconf/2024-06/msg9.html)
I found two bugs in the m4sugar layer, plus a missing testsuite
feature and a way to avoid emitting some AS_ECHO-related backward
compatibility logic unless it's actually needed.  They are all
logically independent of the main project and don't need a lot of
testing so I have gone ahead and pushed them to trunk.

Zack Weinberg (4):
  Emit compat shims less often for old AS_ECHO implementation details.
  Add a FLAGS argument to AT_CHECK_M4SUGAR_TEXT.
  Quote separators in foreach.m4 version of m4_joinall.
  Adjust set size correctly in all cases of m4_set_add_all.

 lib/autoconf/general.m4 |  44 +-
 lib/m4sugar/foreach.m4  |  17 +++---
 lib/m4sugar/m4sh.m4 | 106 +-
 lib/m4sugar/m4sugar.m4  |  60 ++-
 tests/m4sh.at   |  73 ---
 tests/m4sugar.at| 124 ++--
 6 files changed, 292 insertions(+), 132 deletions(-)

-- 
2.44.2

[COMMITTED 3/4] Quote separators in foreach.m4 version of m4_joinall.

[Zack Weinberg]

The entire output of m4_joinall is supposed to be quoted, including
separators, but the foreach.m4 implementation (used with M4 1.4.x)
was missing some quotes, and we didn’t notice because the test suite
wasn’t thorough enough.  Fix.

* lib/m4sugar/foreach.m4 (m4_joinall): Quote each separator as it’s
  emitted.
* tests/m4sugar.at (m4_join test): Expand tests of both m4_join and
  m4_joinall.
---
 lib/m4sugar/foreach.m4 |  2 +-
 tests/m4sugar.at   | 65 --
 2 files changed, 51 insertions(+), 16 deletions(-)

diff --git a/lib/m4sugar/foreach.m4 b/lib/m4sugar/foreach.m4
index c5f26d13..ab558ac5 100644
--- a/lib/m4sugar/foreach.m4
+++ b/lib/m4sugar/foreach.m4
@@ -292,7 +292,7 @@ m4_define([_m4_join],
 # A bit easier than m4_join.  _m4_foreach to the rescue.
 m4_define([m4_joinall],
 [[$2]m4_if(m4_eval([$# <= 2]), [1], [],
-  [_m4_foreach([$1], [], m4_shift($@))])])
+  [_m4_foreach([[$1]], [], m4_shift($@))])])
 
 # m4_list_cmp(A, B)
 # -
diff --git a/tests/m4sugar.at b/tests/m4sugar.at
index 7ea786b7..0b36e626 100644
--- a/tests/m4sugar.at
+++ b/tests/m4sugar.at
@@ -1160,43 +1160,78 @@ AT_SETUP([m4@@_join])
 AT_KEYWORDS([m4@@_joinall])
 
 AT_CHECK_M4SUGAR_TEXT(
-[[m4_define([active], [ACTIVE])
+[[m4_define([active], [ACTIVE])dnl
 m4_join
 m4_join([|])
+m4_join([|], [one])
+m4_join([|], [one], [two])
+m4_join([|], [one], [], [two])
+m4_join([], [one], [two])
+m4_join([], [one], [], [two])
 m4_join([, ], [one], [two])
 m4_dquote(m4_join([, ], [one], [two]))
 m4_join([|], [active], [active])
+m4_join([|], [active], [], [active])
+m4_join([ active ], [one], , [two])
 m4_join([|], ,,,[one])
 m4_join([|], [one],,,)
 m4_join([], ,,,[two])
 m4_join([], [two],,,)
-m4_join([ active ], [one], , [two])
-m4_join([], [one], [two])
-m4_joinall([-], [one], [], [two])
-m4_joinall([-], [], [], [three], [], [])
-m4_joinall([], [one], [], [two])
+m4_join([|], [], [], [three], [], [])
+
 m4_joinall
 m4_joinall([-])
 m4_joinall([-], [one])
+m4_joinall([-], [one], [two])
+m4_joinall([-], [one], [], [two])
+m4_joinall([], [one], [two])
+m4_joinall([], [one], [], [two])
+m4_joinall([, ], [one], [two])
+m4_dquote(m4_joinall([, ], [one], [two]))
+m4_joinall([-], [active], [active])
+m4_joinall([-], [active], [], [active])
+m4_joinall([ active ], [one], , [two])
+m4_joinall([-], ,,,[one])
+m4_joinall([-], [one],,,)
+m4_joinall([], ,,,[two])
+m4_joinall([], [two],,,)
+m4_joinall([-], [], [], [three], [], [])
 ]],
 [[
 
-
+one
+one|two
+one|two
+onetwo
+onetwo
 one, two
 [one, two]
 active|active
-one
-one
-two
-two
+active|active
 one active two
-onetwo
-one--two
---three--
-onetwo
+one
+one
+two
+two
+three
+
 
 
 one
+one-two
+one--two
+onetwo
+onetwo
+one, two
+[one, two]
+active-active
+active--active
+one active  active two
+---one
+one---
+two
+two
+--three--
 ]])
 
 AT_CLEANUP
-- 
2.44.2

[COMMITTED 1/4] Emit compat shims less often for old AS_ECHO implementation details.

[Zack Weinberg]

The shell variables $as_echo and $as_echo_n and the substitution
variables @ECHO_C@, @ECHO_N@, and @ECHO_T@ are implementation
details of the old implementation of AS_ECHO and AS_ECHO_N
(2.69-era; before the switch to use ‘printf’).  We continue
to provide them for compatibility with various third-party macros and
Makefiles that used them, even though, as far as I can tell, they were
never documented.  (Someone made ECHO_C etc. substitution variables on
purpose, though.)

For $as_echo and $as_echo_n, we can tell precisely when they are
needed, because all uses are exposed to M4 macro expansion.
Therefore, emit the necessary support code on first use and not
from AS_INIT.  As a side effect this means the -Wobsolete warning
only appears on the first use of each, which IMHO is polite.

For @ECHO_C@, @ECHO_N@, and @ECHO_T@, we have no way of knowing
whether a substitution variable is used, but we *do* know that
substitution variables are exclusively a configure.ac thing, so their
support code can be moved to general.m4 and emitted from AC_INIT
rather than from AS_INIT.

(It’s faintly possible that someone decided to use $ECHO_C in an
Autotest script but considering how rare it is for people to use
Autotest at all, or any other non-Autoconf application of M4sh,
I think we can worry about that when we hear about it.)

* lib/m4sugar/m4sh.m4 (_AS_ECHO_N_PREPARE): Removed.
  (AS_PREPARE, _AS_PREPARE): Don’t use _AS_ECHO_N_PREPARE.
  (_as_echo_var_prepare, _as_echo_n_var_prepare): New macros which
  emit the -Wobsolete warning and the support code for $as_echo and
  $as_echo_n respectively.
  (as_echo, as_echo_n): Move to bottom of the block that sets up
  the current implementation of AS_ECHO.  Invoke _as_echo_var_prepare
  and _as_echo_n_var_prepare, respectively, on first use.

* lib/autoconf/general.m4 (_AC_INIT_ECHO_N): New internal macro,
  contains the probe code that used to be in _AS_ECHO_N_PREPARE.
  AC_SUBSTs ECHO_C, ECHO_N, and ECHO_T.
  (AC_INIT): Don’t AC_SUBST ECHO_C, ECHO_N, and ECHO_T here.
  Invoke _AC_INIT_ECHO_N.
---
 lib/autoconf/general.m4 |  44 +++--
 lib/m4sugar/m4sh.m4 | 106 
 tests/m4sh.at   |  73 ++-
 3 files changed, 133 insertions(+), 90 deletions(-)

diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 4f64186e..f5ad64ba 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -1401,6 +1401,44 @@ m4_divert_pop([INIT_PREPARE])dnl
 ])# _AC_INIT_PREPARE
 
 
+# _AC_INIT_ECHO_N
+# ---
+# Emit code for backward compatibility with Makefiles that use the
+# ECHO_C, ECHO_N, and ECHO_T substitution variables.  From Autoconf's
+# perspective, these were undocumented internals of the old definition
+# of AS_ECHO_N, before that was changed to use 'printf' instead of
+# 'echo', but they were AC_SUBSTed and Makefiles were written to use
+# them.  We don't have any way to know whether substitution variables
+# are actually used in the project being configured, and the cost of
+# this test is minimal.
+#
+# Test logic borrowed from dist 3.0.  Use '*c*,', not '*c,' because if '\c'
+# failed there is also a newline to match.  Use 'xy' because '\c' echoed
+# in a command substitution prints only the first character of the output
+# with ksh version M-11/16/88f on AIX 6.1; it needs to be reset by another
+# backquoted echo.
+m4_define([_AC_INIT_ECHO_N], [
+# Determine whether it's possible to make 'echo' print without a newline.
+# These variables are no longer used directly by Autoconf, but are AC_SUBSTed
+# for compatibility with existing Makefiles.
+ECHO_C= ECHO_N= ECHO_T=
+case `echo -n x` in @%:@(
+-n*)
+  case `echo 'xy\c'` in
+  *c*) ECHO_T='';; # ECHO_T is single tab character.
+  xy)  ECHO_C='\c';;
+  *)   echo `echo ksh88 bug on AIX 6.1` > /dev/null
+   ECHO_T='';;
+  esac;;
+*)
+  ECHO_N='-n';;
+esac
+AC_SUBST([ECHO_C])dnl
+AC_SUBST([ECHO_N])dnl
+AC_SUBST([ECHO_T])dnl
+])
+
+
 # AU::AC_INIT([UNIQUE-FILE-IN-SOURCE-DIR])
 # 
 # This macro is used only for Autoupdate.
@@ -1457,14 +1495,14 @@ m4_ifval([$2], , [m4_ifval([$1], 
[AC_CONFIG_SRCDIR([$1])])])dnl
 dnl
 dnl Substitute for predefined variables.
 AC_SUBST([DEFS])dnl
-AC_SUBST([ECHO_C])dnl
-AC_SUBST([ECHO_N])dnl
-AC_SUBST([ECHO_T])dnl
 AC_SUBST([LIBS])dnl
 _AC_ARG_VAR_PRECIOUS([build_alias])AC_SUBST([build_alias])dnl
 _AC_ARG_VAR_PRECIOUS([host_alias])AC_SUBST([host_alias])dnl
 _AC_ARG_VAR_PRECIOUS([target_alias])AC_SUBST([target_alias])dnl
 dnl
+dnl Backward compatibility with old Makefiles and old macros.
+_AC_INIT_ECHO_N
+dnl
 AC_LANG_PUSH(C)
 dnl
 dnl Record that AC_INIT has been called.  It doesn't make sense to
diff --git a/lib/m4sugar/m4sh.m4 b/lib/m4sugar/m4sh.m4
index f6580d07..ba6d5409 100644
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -365,7 +365,6 @@ _AS_BASENAME_PREPARE
 _AS_DIRNAME_PREPARE
 _AS_ME_PREPARE
 _AS_CR_PREPARE

[COMMITTED 2/4] Add a FLAGS argument to AT_CHECK_M4SUGAR_TEXT.

[Zack Weinberg]

This is not actually used within the testsuite at present, but is
handy for troubleshooting m4sugar tests.  For instance, you can pass
-v to a specific autom4te invocation and get told the underlying m4
invocation.

* tests/m4sugar.at (AT_CHECK_M4SUGAR_TEXT): Add fourth argument
  FLAGS which specifies additional command line arguments to pass to
  autom4te.
---
 tests/m4sugar.at | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/m4sugar.at b/tests/m4sugar.at
index ba7191af..7ea786b7 100644
--- a/tests/m4sugar.at
+++ b/tests/m4sugar.at
@@ -19,8 +19,8 @@ AT_BANNER([M4sugar.])
 # along with this program.  If not, see .
 
 
-# AT_CHECK_M4SUGAR_TEXT(CODE, STDOUT, STDERR)
-# ---
+# AT_CHECK_M4SUGAR_TEXT(CODE, STDOUT, STDERR, FLAGS)
+# --
 # Check that m4sugar CODE expands to STDOUT and emits STDERR.
 m4_define([AT_CHECK_M4SUGAR_TEXT],
 [
@@ -31,7 +31,7 @@ m4_divert_push([])[]dnl
 m4_divert_pop([])
 ]])
 
-AT_CHECK_M4SUGAR([-o-],, [$2], [$3])
+AT_CHECK_M4SUGAR([$4 -o-],, [$2], [$3])
 ])# AT_CHECK_M4SUGAR_TEXT
 
 
-- 
2.44.2

[COMMITTED 4/4] Adjust set size correctly in all cases of m4_set_add_all.

[Zack Weinberg]

Both the recursive and the iterative versions of m4_set_add_all had a
bug where they did not update the set size correctly if the set
contained tombstones.  I guess m4_set_remove isn’t used that often.
(I found this bug by accident while investigating an unrelated thing.)

The root cause of the bug was that in the tombstone case we had two
different layers quarreling over who got the last word on the size of
the set: m4_set_add, called for each value argument, was updating the
set size for each actual addition, and then the outer expansion of
m4_set_add_all was clobbering those updates with a calculation based
on the number of times the loop evaluated to a ‘-’ character, which
in the tombstone case was always zero.

The fix is to not mess with the set size on each actual addition,
relying on the outer calculation in all cases.  Most of the volume
of the patch is refactoring to eliminate all the duplicate copies of
the “add this element only if it isn’t already there” logic which were
confusing the issue.

I also made m4_set_add_all not go into an infinite loop if invoked
with fewer than two arguments.  Possibly it should error out in this
case instead of silently doing nothing, but I don’t think it matters
very much.

* lib/m4sugar/m4sugar.m4 (_m4_set_add, _m4_set_add_clean):
  New macros, factoring out common “add element to set” logic.
  (m4_set_add): Redefine using _m4_set_add.
  (_m4_set_add_all): Rename to _m4_set_add_all_clean; use _m4_set_add_clean.
  (_m4_set_add_check): Use _m4_set_add, not m4_set_add; emit a string
  of dashes as _m4_set_add_all_clean does.
  (m4_set_add_all): Update to match renamed _m4_set_add_all_clean.
  Do nothing if invoked with fewer than two arguments.

* lib/m4sugar/foreach.m4: Define variants of _m4_set_add_all_clean and
  _m4_set_add_all_check, matching the behavior of the definitions in
  m4sugar.m4.  Do not define m4_set_add_all here.

* tests/m4sugar.at (m4_set): Add more tests of interaction among
  m4_set_add_all, m4_set_remove, and m4_set_size.
---
 lib/m4sugar/foreach.m4 | 15 +--
 lib/m4sugar/m4sugar.m4 | 60 --
 tests/m4sugar.at   | 53 +
 3 files changed, 105 insertions(+), 23 deletions(-)

diff --git a/lib/m4sugar/foreach.m4 b/lib/m4sugar/foreach.m4
index ab558ac5..e2f512ee 100644
--- a/lib/m4sugar/foreach.m4
+++ b/lib/m4sugar/foreach.m4
@@ -350,13 +350,10 @@ m4_define([_m4_minmax],
 #
 # _m4_foreach to the rescue.  If no deletions have occurred, then
 # avoid the speed penalty of m4_set_add.
-m4_define([m4_set_add_all],
-[m4_if([$#], [0], [], [$#], [1], [],
-   [m4_define([_m4_set_size($1)], m4_eval(m4_set_size([$1])
- + m4_len(_m4_foreach(m4_ifdef([_m4_set_cleanup($1)],
-  [[m4_set_add]], [[_$0]])[([$1],], [)], $@])])
+m4_define([_m4_set_add_all_clean],
+[m4_if([$#], [2], [],
+ [_m4_foreach([_m4_set_add_clean([$1],], [, [-])], m4_shift($@))])])
 
-m4_define([_m4_set_add_all],
-[m4_ifdef([_m4_set([$1],$2)], [],
- [m4_define([_m4_set([$1],$2)],
-[1])m4_pushdef([_m4_set([$1])], [$2])-])])
+m4_define([_m4_set_add_all_check],
+[m4_if([$#], [2], [],
+ [_m4_foreach([_m4_set_add([$1],], [, [-])], m4_shift($@))])])
diff --git a/lib/m4sugar/m4sugar.m4 b/lib/m4sugar/m4sugar.m4
index 67b31055..c722a830 100644
--- a/lib/m4sugar/m4sugar.m4
+++ b/lib/m4sugar/m4sugar.m4
@@ -2964,6 +2964,43 @@ m4_ifdef([m4_PACKAGE_VERSION],
 # supply the value via _m4_defn([_m4_set([name])]) without needing any
 # quote manipulation.
 
+
+# _m4_set_add(SET, VALUE, [IF-UNIQ], [IF-DUP])
+# 
+# Subroutine of m4_set_add and m4_set_add_all.
+# Add VALUE as an element of SET, but do not update the size of SET.
+# Expand IF-UNIQ on the first addition, and IF-DUP if it is already in
+# the set.
+#
+# Three cases must be handled:
+#  - _m4_set([$1],$2) is not defined:
+#  define _m4_set([$1],$2) to 1, push $2 as a definition of _m4_set([$1]),
+#  expand IF-UNIQ.
+#  - _m4_set([$1],$2) is defined with value 0:
+#  define _m4_set([$1],$2) to 1, *don't* modify _m4_set([$1]),
+#  expand IF-UNIQ.
+#  - _m4_set([$1],$2) is defined with value 1:
+#  do nothing but expand IF-DUP.
+m4_define([_m4_set_add],
+[m4_ifndef([_m4_set([$1],$2)],
+  [m4_pushdef([_m4_set([$1])],[$2])m4_define([_m4_set([$1],$2)],[1])$3],
+  [m4_if(m4_indir([_m4_set([$1],$2)]), [0],
+[m4_define([_m4_set([$1],$2)],[1])$3],
+[$4])])])
+
+# _m4_set_add_clean(SET, VALUE, [IF-UNIQ], [IF-DUP])
+# --
+# Subroutine of m4_set_add_all.
+# Add VALUE as an element of SET, but do not update the size of SET.
+# It is safe to assume that VALUE is not a tombstone, i.e. either
+# _m4_set([$1],$2) is not defined or it is defined with value 1.
+# Expand IF-UNIQ on the first addition, and IF-DUP if it is already in
+# the set.
+m4_define([_m4_set_add_clean],
+[m4_ifndef([_m4_set([$1],$2)],
+  

[COMMITTED 0/4] four small unrelated bug fixes

[Zack Weinberg]

While working on the AC_LOG_CMD/AC_LOG_FILE project
(see https://lists.gnu.org/archive/html/autoconf/2024-06/msg9.html)
I found two bugs in the m4sugar layer, plus a missing testsuite
feature and a way to avoid emitting some AS_ECHO-related backward
compatibility logic unless it's actually needed.  They are all
logically independent of the main project and don't need a lot of
testing so I have gone ahead and pushed them to trunk.

Zack Weinberg (4):
  Emit compat shims less often for old AS_ECHO implementation details.
  Add a FLAGS argument to AT_CHECK_M4SUGAR_TEXT.
  Quote separators in foreach.m4 version of m4_joinall.
  Adjust set size correctly in all cases of m4_set_add_all.

 lib/autoconf/general.m4 |  44 +-
 lib/m4sugar/foreach.m4  |  17 +++---
 lib/m4sugar/m4sh.m4 | 106 +-
 lib/m4sugar/m4sugar.m4  |  60 ++-
 tests/m4sh.at   |  73 ---
 tests/m4sugar.at| 124 ++--
 6 files changed, 292 insertions(+), 132 deletions(-)

-- 
2.44.2

Re: AC_TRY_COMMAND use case

[Zack Weinberg]

On Tue, Jul 2, 2024, at 9:36 AM, Florian Weimer wrote:
> We are using AC_TRY_COMMAND in glibc's configure.ac to log executed
> commands in config.log
>
> What's the recommended replacement for that?

There is none right now, AFAIK, but will the proposed new macros in 
https://lists.gnu.org/archive/html/autoconf/2024-06/msg9.html meet your 
needs?

zw

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

[Zack Weinberg]

On Sun, Jun 23, 2024, at 10:23 PM, Zack Weinberg wrote:
> I'm thinking of making AC_RUN_LOG, which has existed forever but is
> undocumented, an official documented macro under the new name
> AC_LOG_CMD.  I'm renaming it because I also want to add AC_LOG_FILE, a
> generalization of _AC_MSG_LOG_CONFTEST.

FYI, this seemed straightforward to implement but has exposed a whole
bunch of latent problems, so it'll be a week or two more before I have
patches ready to go, but there's no insurmountable obstacles.  You can
all follow along at
<https://git.savannah.gnu.org/cgit/autoconf.git/log/?h=zack/ac-log-cmd>.
(This branch will definitely be rebased at least once before things are
ready to merge.)

zw

Re: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

[Zack Weinberg]

On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote:
> On 2024-06-23 22:23, Zack Weinberg wrote:
>> I'm thinking of making AC_RUN_LOG, which has existed forever but is
>> undocumented, an official documented macro ...
>
> Yes, please!
>
> I will note that Autoconf has a lot of "run and log a command" internal
> macros with various comments of the form "doesn't work well" suggesting
> that this is a hard feature to get right.

... Wow, this is a bigger mess than I thought last night.  Up to bad
quotation in third party macros, however, I *think* almost all of it
is obsolete and can be scrapped.  Stay tuned.

> I think at the same time it would be worth documenting the AS_LINENO
> functionality, which is the main internal functionality of these
> macros that (unless you just goes ahead and use it) Autoconf users
> can't really replicate in their own logging.

I believe what you mean is you want _AS_ECHO_LOG to be promoted to a
documented and supported macro, and for AS_LINENO_PUSH and AS_LINENO_POP
also to be documented for external use.  Is this correct?  Did I miss
any other internal macros that ought to be available for external
use?  I don't think we should tell people to be using $as_lineno directly,
is there some use case for it that isn't covered by existing macros?

> If you implement this, please explain in the manual what "labeled with
> /label/" really means, otherwise I'm left wondering why this macro
> exists when we can almost as easily write something like:
>
>   { echo label; cat file; } >_MESSAGE_LOG_FD
>
> Including example logfile output together with the example program
> might be sufficient.

Will do.  The main point of the macro is that it does something a little
fancier than "cat file", so it's unambiguous where normal log output
resumes. Like the existing _AC_MSG_LOG_CONFTEST does:

configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "lexlib-probe"
| #define PACKAGE_TARNAME "lexlib-probe"
| #define PACKAGE_VERSION "1"
| ... etc ...
configure: result: no

The "label" will go where _AC_MSG_LOG_CONFTEST prints "failed program was".

zw

RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.

[Zack Weinberg]

I'm thinking of making AC_RUN_LOG, which has existed forever but is
undocumented, an official documented macro under the new name
AC_LOG_CMD.  I'm renaming it because I also want to add AC_LOG_FILE, a
generalization of _AC_MSG_LOG_CONFTEST.

These are handy any time you want to record details of why some test got
the result it did in config.log; AC_COMPILE_IFELSE and friends have been
able to do this forever, but hand-written tests of the shell environment
or of interpreters can't without reaching into autoconf's guts.
Automake has been carrying around its own copy of AC_LOG_CMD (under the
name AM_LOG_CMD) forever as well...

I haven't *implemented* this yet, but here's the proposed documentation.
What do you think?

zw

+@node Logging
+@section Logging Details of Tests
+
+It is helpful to record details of @emph{why} each test got the result
+that it did, in @file{config.log}.  The macros that compile test
+programs (@code{AC_COMPILE_IFELSE} etc.; @pxref{Writing Tests}) do this
+automatically, but if you write a test that only involves M4sh and basic
+shell commands, you will need to do it yourself, using the following macros.
+
+@anchor{AC_LOG_CMD}
+@defmac AC_LOG_CMD (@var{shell-command})
+Execute @var{shell-command}.
+Record @var{shell-command} in @file{config.log}, along with any error
+messages it printed (specifically, everything it wrote to its standard
+error) and its exit code.
+
+This macro may be used within a command substitution, or as the test
+argument of @code{AS_IF} or a regular shell @code{if} statement.
+@end defmac
+
+@anchor{AC_LOG_FILE}
+@defmac AC_LOG_FILE (@var{file}, @var{label})
+Record the contents of @var{file} in @file{config.log}, labeled with
+@var{label}.
+@end defmac
+
+Here is an example of how to use these macros to test for a feature of
+the system `awk'.
+
+@smallexample
+AC_PROG_AWK
+AC_MSG_CHECKING([whether $AWK supports 'asort'])
+cat > conftest.awk <<\EOF
+[@{ lines[NR] = $0 @}
+END @{
+  ORS=" "
+  asort(lines)
+  for (i in lines) @{
+print lines[i]
+  @}
+@}]
+EOF
+
+AS_IF([result=`AC_LOG_CMD([printf 'z\ny\n' | $AWK -f conftest.awk])` &&
+   test x"$result" = x"y z"],
+  [AWK_HAS_ASORT=yes],
+  [AWK_HAS_ASORT=no
+   AC_LOG_FILE([conftest.awk], [test awk script])])
+AC_MSG_RESULT([$AWK_HAS_ASORT])
+AC_SUBST([AWK_HAS_ASORT])
+rm -f conftest.awk
+@end smallexample
 
 @c == Programming in M4.

Re: patch to update Darwin's Systemology section - sr #111004

[Zack Weinberg]

On Thu, Jun 20, 2024, at 12:53 PM, Sevan Janiyan wrote:
> Hello,
> If the patch (file #55536) submitted in sr #111004 is of use, could it 
> be merged?
>
> https://savannah.gnu.org/support/?111004

Applied with some revision.

zw

Re: [PATCH] bootstrap: allow `ln -s' to be overriden by the user

[Zack Weinberg]

On Sat, Jun 22, 2024, at 8:45 AM, KO Myung-Hun wrote:
> * bootstrap: Use $LN_S instead of `ln -s'.

Applied, thank you.

zw

Re: Bug Resilience Program of German Sovereign Tech Fund

[Zack Weinberg]

On Thu, Jun 6, 2024, at 10:37 AM, Dan Kegel wrote:
> That's a really good idea.  Automake and Autotools in general underpin
> a fair amount of key open source software, but is taken for granted.
>
> Ideas for making the case for funding: identify...
> - how many commonly used Debian/Ubuntu/Alpine packages and/or GitHub
> projects rely on automake/Autotools
> - markers of risk (e.g. very out of date or buggy embedded Autotools files)
> - problems this has caused in the past
> - related government standards for software quality
> All of that might help make the case.

On the autoconf side of the fence, I do not have spare cycles to write a
proposal all by myself, but I would be interested in working with one or
more other people to write such a proposal, and in doing some of the
work.  In particular, I already have a mental list of things that
*ought* to be done in the near future for autoconf but I do not have the
capacity to do by myself on a volunteer basis.

I'm adding Sumana Harihareswara to the cc: list; she helped me secure the
funding for the release of autoconf 2.70 and might be interested in working
on this pitch as well.

zw

Re: configure adds -std=gnu++11 to CXX variable

[Zack Weinberg]

On Sun, May 26, 2024, at 12:31 PM, Paul Eggert wrote:
> As Zack mentioned, developers and builders need ways to say things like 
> "I want C++20 even if the compiler supports C++23". The simplest way to 
> do that would be to document the existing mechanism, which relies on 
> setting the appropriate cache variables. I volunteer to do that unless 
> someone else wants to do something fancier (which would make my work 
> unnecessary and possibly even counterproductive).

I intend to work on something for this - probably not *fancier*, but more 
presentable than cache variables - in June. If I haven't posted a patch by the 
beginning of July, please don't wait any longer.

zw

Re: [PATCH] AC_FUNC_MALLOC: fix cross compilation to musl

[Zack Weinberg]

On Wed, May 15, 2024, at 11:49 AM, Alyssa Ross wrote:
> This check returned yes for me on musl 1.2.3 on aarch64-unknown-linux-
> musl.

Thanks! I verified by code inspection that all three of musl libc's
malloc implementations return a non-NULL pointer for malloc(0), and
committed your patch.

zw

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

[Zack Weinberg]

Update of sr #111044 (group autoconf):

  Status:   Need Info => Confirmed  

___

Follow-up Comment #4:

Copying conversation from bug-autoconf:

Frank Eigler:
> On the other hand, we've had very real reports that e.g. diff was
> missing on some real platforms, which led autoconf astray and ended up
> in misconfigured build trees.  Perhaps autoconf can afford to do some
> sanity checking on these reasonable-sounding but not-universal
> expectations.

Zack Weinberg:
> Frank, do you have details of those real platforms with missing diff?
> As I wrote in <https://savannah.gnu.org/support/index.php?111044>, it's
> difficult to implement this kind of sanity check without access to an
> environment that *fails* this kind of sanity check.  I could set one up
> myself but I wouldn't know if I had picked the right things to leave out.

Frank Eigler:
> Not a live system I use day-to-day.  But I mean I can remove
> "diffutils" from my Fedora box, and see it break.
>
> I think the point was not so much that normal & typical developer
> systems may fail.  It's that unforseen restricted machines (maybe
> running in minimal fashionably-"secure" buildroots) could encounter
> these problems, and then QUIETLY FAIL by misconfiguring tools.
>
> Thus the idea was just to do lightweight & obvious sanity checking on
> the environment at configure startup.  e.g.:
>
>diff /dev/null /dev/null || exit 1

I think this gives me enough information to proceed.



___

Reply to this item at:

  <https://savannah.gnu.org/support/?111044>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [sr #111044] autoconf should assert existence of all subsidiary tools at startup

[Zack Weinberg]

On Mon, Apr 1, 2024, at 5:26 PM, Frank Ch. Eigler wrote:
> On Mon, Apr 01, 2024 at 05:10:17PM -0400, Paul Eggert wrote:
>> [...]
>> Not sure I'd go that far. The
>> [https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html GNU
>> Coding Standards for utilities in makefiles] lists the following as usable
>> without further ado:
>> 
>> awk cat cmp cp diff echo egrep expr false grep install-info ln ls
>> mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true
>> [...]
>
> On the other hand, we've had very real reports that e.g. diff was
> missing on some real platforms, which led autoconf astray and ended up
> in misconfigured build trees.  Perhaps autoconf can afford to do some
> sanity checking on these reasonable-sounding but not-universal
> expectations.

Frank, do you have details of those real platforms with missing diff?
As I wrote in , it's
difficult to implement this kind of sanity check without access to an
environment that *fails* this kind of sanity check.  I could set one up
myself but I wouldn't know if I had picked the right things to leave out.

zw

Re: C23 support in Autoconf

[Zack Weinberg]

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.
>
> Yes, we could add a new macro to do that, or a new argument to 
> AC_PROG_CC. Presumably it would have to be called very early.

I think a new macro would be more self-documenting and also wouldn't
interfere with the dozens of macros that AC_REQUIRE AC_PROG_CC.  Something
like

AC_C_STANDARD_EDITION([2011])
AC_PROG_CC

We could also offer

AC_C_STANDARD_EDITION([2011], [strict])

to enable use of -std=cXX instead of -std=gnuXX, or equivalent.

> Although the new keywords and the lack of K support is a problem, it's 
> a problem people will have anyway as C23 spreads. So a new macro (or new 
> argument) would merely be a backward compatibility hack for people who 
> for some reason can't fix their old code, and the hack should be 
> documented with that in mind.

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.  IIRC
the PostgreSQL people wanted this.  See 
<https://savannah.gnu.org/support/?110286>.

zw

Re: C23 support in Autoconf

[Zack Weinberg]

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 mentioning that, as I hadn't run into that problem. I 
> installed the attached.

Because of this class of problems, 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.

zw

Re: Making MSVC/clang-cl succeed AC_PROG_CC C11 discovery

[Zack Weinberg]

On Tue, Apr 23, 2024 at 09:07:49PM -0300, Antonin Décimo wrote:
> I'm hacking on the Autoconf scripts for the OCaml compiler [1]. I'm
> trying to make them more useful when compiling with the dreaded MSVC.

Thanks for tackling this!

> MSVC has supported C11 and C17 since September 2020 [2]. The options
> to enable support are `/std:c11` and `/std:c17`. There's an
> alternative syntax, `-std:c11` and `-std:c17` (dash instead of slash).
> 
> diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
> index d8eab7bb..01d4cfa6 100644
> --- a/lib/autoconf/c.m4
> +++ b/lib/autoconf/c.m4
> @@ -1553,6 +1553,7 @@ m4_define([_AC_C_C99_OPTIONS], [
>  # shell quotes around the group.
>  #
>  # GCC, Clang-std=gnu11
> +# MSVC  -std:c11
>  #
>  # For IBM XL C for AIX V16.1 or later, '-std=gnu11' should work if
>  # the user configured with CC='xlclang'.  Otherwise, do not try
> @@ -1562,6 +1563,7 @@ m4_define([_AC_C_C99_OPTIONS], [
>  # _Noreturn, which is a win.
>  m4_define([_AC_C_C11_OPTIONS], [
>  -std=gnu11
> +-std:c11
>  ])

This change looks correct to me in isolation, and I concur with using
the dash-prefix form for the reasons you stated in your other message.

> MSVC doesn't enable the `__STDC__` macro by default, it needs a
> `/Zc:__STDC__` flag [3]. This is done to prevent compatibility issues [4].
...
> MSVC fails this check. I'm tempted to add the `/Zc:__STDC__` flag to
> `_AC_C_C11_OPTIONS`, however its doc reads:
> 
> > Do not try "strictly conforming" modes (e.g. gcc's -std=c11); they
> > break some systems' header files.
...
> Should both `/std:c11 /Zc:__STDC__` be added to `_AC_C_C11_OPTIONS` to
> support MSVC? Should Autoconf remove the `__STDC__` check or check for
> MSVC at this stage?

This is a hard one.

I haven't done much programming for Windows at all, but I have had to work
with other systems that had more-or-less ISO-C89-conformant compilers and
C runtimes but didn't define __STDC__, for more or less the same reason
Microsoft isn't defining it -- they didn't want to claim conformance
outside of a "strict conformance" mode that caused more problems than
it solved.  In the 1990s and early 2000s, it was very common to see
#ifdef __STDC__ or #if __STDC__ in application code, for example using it
to decide whether to use prototyped or old-style function definitions.
That code would, in the worst case, fail to compile on the systems I'm
thinking of, because *both* modes were wrong -- with __STDC__ not defined,
they would use the "K compiler" side of the ifdefs and do things like
preprocessor token concatenation the wrong way; with __STDC__ defined,
the C library was in "strict" mode and missing important declarations
from the headers.

Nowadays, preprocessor conditionals on __STDC__ are less common, but I
am still worried that both possibilities are wrong: with /Zc:__STDC__
Microsoft's compilers will make  not declare open(), breaking
application code; without it, application code may assume that it's
dealing with a "K" compiler.

I think we need input here from an expert on low-level C programming
and portability issues specifically for Windows.  If anyone reading
this has those qualifications, please speak up.  I will try to find
someone through other means if nobody speaks up in a week or two.

(The comment about "strictly conforming" modes breaking system headers
was motivated by a related problem: on some systems, the code *inside*
important headers like  will throw compile errors if you
feed it to GCC in -std=cXX mode, because it's never been tested that
way.  However, that comment is definitely *relevant*.  If the preprocessor
macro under discussion was anything but __STDC__ or __STDC_VERSION__ I
would say "no, don't use that option here" without hesitation, but...)

(Can you check if there's maybe some way to make the UCRT declare
POSIX functions like open(), without a leading underscore, *even if*
__STDC__ is defined?  Another macro that you define, maybe?)

> The second problem is that MSVC has no support for Variable-Length
> Arrays (VLA) [5]. There is however a test for VLAs in
> `_AC_C_C99_TEST_MAIN`. C11 has introduced in _6.10.8.3 Conditional
> feature macros_:
> 
> > `__STDC_NO_VLA__` The integer constant `1`, intended to indicate
> > that the implementation does not support variable length arrays or
> > variably modified types.
> 
> However the VLA test is included as-is in the C11 main program, but
> C11 made that feature optional. MSVC correctly defines the
> `__STDC_NO_VLA__` macro, but fails the Autoconf test. This is clearly
> an Autoconf bug, but the fix isn't clear.

I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC.
Take the test for VLAs completely out of _AC_C_C99_TEST_MAIN, but
unconditionally *run* a test for VLAs as part of AC_PROG_CC.  If that
test fails, and __STDC_NO_VLA__ was not defined by the compiler,
then AC_DEFINE([__STDC_NO_VLA__], 1) and set a cache 

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

[Zack Weinberg]

Update of sr #111044 (group autoconf):

Priority:   5 - Unprioritized => 2 - Eventually 
Severity:  3 - Normal => 2 - Minor  
  Status:None => Need Info  

___

Follow-up Comment #2:

Thank you for (re-)reporting this bug.  I agree that autoconf should make
reasonable efforts to run in a minimal environment and, when the environment
is too minimal to tolerate, it should give clear error messages.  In
particular I agree that neither `diff` nor `awk` (and arguably not even `sed`)
should be an implicit dependency.

That said, this kind of bug is very difficult to work on without concrete test
cases and test environments.  If you could provide us with both of

* a minimized configure.ac that produces a configure script that malfunctions
(meaning, neither runs to completion correctly nor produces a useful error
message and halts) in the minimal environment you're working with

* details of the minimal environment you're working with, in particular the
complete list of available shell commands ("command names" as defined in
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
-- most importantly, both shell built-ins and external executables) and any
cases where functionality guaranteed by POSIX.1-2001 is absent; f there is a
straightforward recipe for constructing a matching environment from widely
available free software, please describe it

that would be super helpful and would probably get the bug addressed orders of
magnitude faster.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: configure adds -std=gnu++11 to CXX variable

[Zack Weinberg]

On Mon, Mar 4, 2024, at 9:54 AM, Zack Weinberg wrote:
> Fixing these things is a high priority for Autoconf 2.73 but nobody
> currently has time to work on it.  If you have time, we would
> appreciate your working on it -- even just a rough draft of revised
> test programs would be helpful.

Oh, also, as a workaround, try

./configure CXX='g++ -std=c++2a' ac_cv_prog_cxx_cxx11='none needed'

This _ought_ to bypass the troublesome test.  If it doesn't work,
try setting ac_cv_prog_cxx_cxx11='none needed' in a config.site
file instead of putting it on the command line.

zw

Re: configure adds -std=gnu++11 to CXX variable

[Zack Weinberg]

On Mon, Mar 4, 2024, at 12:17 AM, Peter Johansson wrote:
> This is with autoconf 2.72 and GCC 9.4.0.
> I try to configure a project with
>
> ./configure 'CXX=c++ -std=c++2a'
>
> but the configure seems to dislike that because it outputs
>
> checking whether the compiler supports GNU C++... yes
> checking whether c++ -std=c++2a accepts -g... yes
> checking for c++ -std=c++2a option to enable C++11 features... -std=gnu++11
> checking dependency style of c++ -std=c++2a -std=gnu++11... gcc3
>
> So it decides to add -std=gnu++11.

Yeah, the logic for selecting a version of the C++ standard is inflexible
at the moment.  It always tries to force the highest standard that it
already knows about -- and right now that's C++ 2011, no higher.
(At the time 2.72 was released, the 202x C and C++ standards were still
in flux so we elected not to add support for them.)  Making it more
flexible -- specifically, allowing the project to declare which version
of the standard they want to use -- is tracked as
.

Also, what we currently have assumes that code that's valid in C++ 
will _remain_ valid in C++ , where  > .  That used to be
reliably true but the 202x standard drafts broke it.  That's why the
test program threw the error you quoted...

> conftest.cpp: In function 'int main(int, char**)':
> conftest.cpp:199:22: error: invalid conversion from 'const char8_t*' to
> 'const char*' [-fpermissive]
>   199 |   char const *utf8 = u8"UTF-8 string \u2500";

Fixing these things is a high priority for Autoconf 2.73 but nobody
currently has time to work on it.  If you have time, we would
appreciate your working on it -- even just a rough draft of revised
test programs would be helpful.

zw

Re: Is it safe to use ax_gcc_builtin to detect __builtin_offsetof?

[Zack Weinberg]

On Sun, Feb 25, 2024, at 2:09 AM, Jeffrey Walton wrote:
>
> Is it safe to use ax_gcc_builtin to detect __builtin_offsetof?

Why do you need to do that? What's wrong with including stddef.h and then using 
plain offsetof? It's part of C1989.

Not a rhetorical question, I really would like to know how this came up.

zw

[sr #111016] Configure script fails to detect sctp on Alpine linux

[Zack Weinberg]

Update of sr#111016 (group autoconf):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH] Fix typo which causes test "m4_warn (bad categories)" to, fail.

[Zack Weinberg]

On Thu, Feb 1, 2024, at 7:00 AM, Collin Funk wrote:
> Hello, I ran into a test failure for "m4_warn (bad categories)". I
> believe that this is just a typo introduced by commit b553b19. I
> attached a patch that fixes the test failure.

Your patch is correct, but incomplete. The typo was introduced by an automatic 
process, namely the script run by "make fetch" (build-aux/fetch.pl, if I 
remember correctly). It must also be corrected, or else the typo will come back 
the next time someone runs "make fetch".

Can you try to fix that script? I can't do it myself right now because my work 
computer is broken.

zw

Re: cannot make gcc report undeclared builtins

[Zack Weinberg]

On Wed, Jan 31, 2024, at 6:23 AM, Simon Josefsson via Bug reports for autoconf 
wrote:
> I got this failure on a loong64 machine for libidn2 that was
> bootstrapped with autoconf 2.72:
>
> checking for gcc options needed to detect all undeclared functions... 
> cannot detect
> configure: error: in `/<>/build':
> configure: error: cannot make gcc report undeclared builtins

Can you please grab config.log from this failure and post it here?

Unavailable due to hardware problems

[Zack Weinberg]

In case anyone is waiting for me to respond to questions or write a patch or 
anything, please be advised that my work computer has crashed hard and until 
replacement components arrive (early next week) I can't do much of anything.

Re: bug#68274: automake 1.16j nonnumerical version confuses scripts

[Zack Weinberg]

On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
> On 13 Jan 2024 15:58, Karl Berry wrote:
>> Another alternative: when this came up 30-odd years ago, rms changed the
>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>> that would at least have the benefit of following a recommendation, and
>> as a side effect, would also fix jami's assumption (poor practice though
>> it is, IMHO).
>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>> 
>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>> (rough guess with some grep counting) the .90 convention is by far the
>> most common approach (a couple thousand), followed by the suffix letter
>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>> are both trailing the field. Other random conventions also present.
>> 
>> It all feels like bikeshedding to me, so my inclination is to do
>> nothing.  If we do change, I think we should use .90.  --best, karl.
>
> using .90 is certainly better than single-letters.  if you're fine with
> it, then let's switch.

For what it's worth, I had planned to switch Autoconf, starting with the
next release, to use *some* version numbering scheme for beta releases
that sorts correctly according to things like strverscmp() and
dpkg --compare-versions.  The "append a letter to the version number
intended for the final release" convention makes these algorithms sort
the betas *after* the release, which is backwards.

My plan *was* to append letters to the version number for the *previous*
release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
which I think is what Automake is doing now) but I like .9x version numbers
better because it's more common (as you observed) and therefore more likely
to be understood at sight.  I'd actually forgotten that .9x versions were
an official GNU recommendation.

zw

[sr #111007] autoconf 2.72 warning: file 'version.m4' included several times

[Zack Weinberg]

Update of sr#111007 (group autoconf):

Priority:   5 - Unprioritized => 8 - Release N (Blocker)

___

Follow-up Comment #3:

Introducing an annoying, spurious warning on code recommended by the automake
manual does seem important enough that it should be fixed in the very next
release, but bad warning messages by themselves never rise to the level of a
*critical* problem.  Are you saying that you're not getting your own
version.m4 anymore when you do `m4_include([version.m4])` ?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a loop

[Zack Weinberg]

Follow-up Comment #2, sr#110989 (group autoconf):

No, if I understood Nick and Jacob's suggestions correctly, the idea is to
replace $am_sleep / AT_MTIME_DELAY with something like


while [ ! newer_file -nt older_file ]; do
  sleep $am_cv_filesystem_timestamp_resolution
  touch newer_file
done


But we need a Perl helper to implement that, because test -nt isn't in POSIX,
and a test implementation that does support -nt will probably be comparing
'struct timespec's directly rather than converting to 'double' first as Perl
does.  My current vague plan is to make it be a special mode of autom4te,


autom4te --ensure-newer newer_file older_file


It could also be a separate helper script like move-if-change or automake's
"missing".


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

autoconf-2.72 released [stable]

[Zack Weinberg]

-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 32-bit platforms
(--enable-year2038).  See the NEWS below for a brief summary.

There have been 171 commits by 17 people in the 151 weeks since 2.71.
Thanks to everyone who has contributed:

  Andreas K. Hüttel (1)
  Ben Elliston (1)
  Bruno Haible (8)
  Detlef Riekenberg (1)
  Emanuele Giaquinta (2)
  Eric Blake (4)
  Gleb Fotengauer-Malinovskiy (1)
  Jim Meyering (5)
  KO Myung-Hun (1)
  Keno Fischer (1)
  Marshall Ward (1)
  Mike Frysinger (1)
  Paul Eggert (84)
  Sergei Trofimovich (1)
  Todd C. Miller (1)
  Xi Ruoyao (1)
  Zack Weinberg (57)

We would also like to thank everyone who submitted bug reports,
whether or not we were able to resolve them:

  Alain Knaff
  D. Lang
  David Allsopp
  Dominik Kummer
  E. Johnson
  G. Herfray
  Guillem Jover
  Jacob Bachmeyer
  James “the pedant”
  Johan Olsson
  Jonathan Birge
  Joshua Root
  Jörn Heusipp
  Marvin Scholz
  Maxim Cournoyer
  Michael Orlitzky
  Michal Nowak
  Natanael Copa
  Peter Eisentraut
  R. Diez
  Remi Attab
  Ross Burton
  Sam James
  Vadim Zeitlin
  Valery Ushakov
  Zlobin Nikita

and at least 14 more people who wished to remain anonymous.

zw
 [on behalf of the autoconf maintainers]
==

Here is the GNU autoconf home page:
http://gnu.org/s/autoconf/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=v2.72
or run this command from a git-cloned autoconf directory:
  git shortlog v2.71..v2.72

Here are the compressed sources:
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.gz   (2.1MB)
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.xz   (1.4MB)

Here are the GPG detached signatures:
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.gz.sig
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

  396c8236b777eabf7491a352c967d0f41465e06a  autoconf-2.72.tar.gz
  r7GBp24e5ygy9lgcDt343wMrg+LgI573nr7cRGfZLW4=  autoconf-2.72.tar.gz
  1d082d999ff4506ec8f92c6ecb9732546f5204fb  autoconf-2.72.tar.xz
  uohcExlXjWyU1G6bDc60AUyq/iSQ5Deg28o/JwoiP1o=  autoconf-2.72.tar.xz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify autoconf-2.72.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2010-01-14 [SC]
82F8 54F3 CE73 174B 8B63  1740 91FC C32B 6769 AA64
  uid   Zack Weinberg 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key za...@panix.com

  gpg --recv-keys 91FCC32B6769AA64

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=autoconf=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify autoconf-2.72.tar.gz.sig

This release was bootstrapped with the following tools:
  Automake 1.16.5

NEWS

* Noteworthy changes in release 2.72 (2023-12-22) [release]

** Backward incompatibilities

*** Configure scripts no longer support pre-1989 C compilers.
  Specifically, compilers that *only* implement the original “K”
  function definition syntax, and not the newer “prototyped” syntax,
  will not be able to parse the test programs now emitted by
  AC_CHECK_FUNC, AC_LANG_CALL, and similar macros.  AC_PROG_CC still
  accepts such compilers, but this may change in the near future.

  This change was necessary in order to support the upcoming 2024
  edition of the C standard (often referred to as “C23”), which will
  officially remove the function declaration syntax used by
  AC_CHECK_FUNC in Autoconf 2.71 and earlier.  We feel that support
  for compilers that support only C 2024 is more useful, nowadays,
  than support for compilers that don’t implement a core feature of
  C 1989.

*** Autoconf developers now need Perl 5.10 (2007) or later.
  “Autoconf developers” means specifically people hacking on Autoconf
  itself.  Autoconf *users*, i.e. authors of configure.ac files and
  add-on M4 macros, still need only Perl 5.6 (2000) or later.

  We do recommend all Autoconf users upgrade to Perl 5.10 or later if
  possible

autoconf-2.72 released [stable]

[Zack Weinberg]

-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 32-bit platforms
(--enable-year2038).  See the NEWS below for a brief summary.

There have been 171 commits by 17 people in the 151 weeks since 2.71.
Thanks to everyone who has contributed:

  Andreas K. Hüttel (1)
  Ben Elliston (1)
  Bruno Haible (8)
  Detlef Riekenberg (1)
  Emanuele Giaquinta (2)
  Eric Blake (4)
  Gleb Fotengauer-Malinovskiy (1)
  Jim Meyering (5)
  KO Myung-Hun (1)
  Keno Fischer (1)
  Marshall Ward (1)
  Mike Frysinger (1)
  Paul Eggert (84)
  Sergei Trofimovich (1)
  Todd C. Miller (1)
  Xi Ruoyao (1)
  Zack Weinberg (57)

We would also like to thank everyone who submitted bug reports,
whether or not we were able to resolve them:

  Alain Knaff
  D. Lang
  David Allsopp
  Dominik Kummer
  E. Johnson
  G. Herfray
  Guillem Jover
  Jacob Bachmeyer
  James “the pedant”
  Johan Olsson
  Jonathan Birge
  Joshua Root
  Jörn Heusipp
  Marvin Scholz
  Maxim Cournoyer
  Michael Orlitzky
  Michal Nowak
  Natanael Copa
  Peter Eisentraut
  R. Diez
  Remi Attab
  Ross Burton
  Sam James
  Vadim Zeitlin
  Valery Ushakov
  Zlobin Nikita

and at least 14 more people who wished to remain anonymous.

zw
 [on behalf of the autoconf maintainers]
==

Here is the GNU autoconf home page:
http://gnu.org/s/autoconf/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=v2.72
or run this command from a git-cloned autoconf directory:
  git shortlog v2.71..v2.72

Here are the compressed sources:
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.gz   (2.1MB)
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.xz   (1.4MB)

Here are the GPG detached signatures:
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.gz.sig
  https://ftpmirror.gnu.org/autoconf/autoconf-2.72.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

  396c8236b777eabf7491a352c967d0f41465e06a  autoconf-2.72.tar.gz
  r7GBp24e5ygy9lgcDt343wMrg+LgI573nr7cRGfZLW4=  autoconf-2.72.tar.gz
  1d082d999ff4506ec8f92c6ecb9732546f5204fb  autoconf-2.72.tar.xz
  uohcExlXjWyU1G6bDc60AUyq/iSQ5Deg28o/JwoiP1o=  autoconf-2.72.tar.xz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify autoconf-2.72.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2010-01-14 [SC]
82F8 54F3 CE73 174B 8B63  1740 91FC C32B 6769 AA64
  uid   Zack Weinberg 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key za...@panix.com

  gpg --recv-keys 91FCC32B6769AA64

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=autoconf=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify autoconf-2.72.tar.gz.sig

This release was bootstrapped with the following tools:
  Automake 1.16.5

NEWS

* Noteworthy changes in release 2.72 (2023-12-22) [release]

** Backward incompatibilities

*** Configure scripts no longer support pre-1989 C compilers.
  Specifically, compilers that *only* implement the original “K”
  function definition syntax, and not the newer “prototyped” syntax,
  will not be able to parse the test programs now emitted by
  AC_CHECK_FUNC, AC_LANG_CALL, and similar macros.  AC_PROG_CC still
  accepts such compilers, but this may change in the near future.

  This change was necessary in order to support the upcoming 2024
  edition of the C standard (often referred to as “C23”), which will
  officially remove the function declaration syntax used by
  AC_CHECK_FUNC in Autoconf 2.71 and earlier.  We feel that support
  for compilers that support only C 2024 is more useful, nowadays,
  than support for compilers that don’t implement a core feature of
  C 1989.

*** Autoconf developers now need Perl 5.10 (2007) or later.
  “Autoconf developers” means specifically people hacking on Autoconf
  itself.  Autoconf *users*, i.e. authors of configure.ac files and
  add-on M4 macros, still need only Perl 5.6 (2000) or later.

  We do recommend all Autoconf users upgrade to Perl 5.10 or later if
  possible

[sr #110987] AC_PROG_CC_C_O + AC_LANG([C++]) combines C-specific compiler options with C++ source

[Zack Weinberg]

Update of sr#110987 (group autoconf):

  Status:   Confirmed => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Turns out there is an obvious correct patch for this bug: all the *other*
AC_PROG_compiler_C_O macros do an AC_LANG_PUSH/POP to the appropriate
language, so AC_PROG_CC_C_O should too.  Committed as
e544a323845c1bcc33729927137b09c681073ebd.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: AT_MTIME_DELAY not working?

[Zack Weinberg]

On Fri, Dec 22, 2023, at 10:08 AM, Nick Bowler wrote:
> On 2023-12-22 09:28, Zack Weinberg wrote:
>> On Thu, Dec 21, 2023, at 10:07 PM, Jacob Bachmeyer wrote:
> [...]
>>> I suggest revising AT_MTIME_DELAY to actually create two files and
>>> loop touching one of them until the timestamps differ.
>> 
>> This won’t work, because whether *test* thinks two timestamps differ
>> may be different from whether *autom4te* thinks two timestamps differ
>> (due to the whole mess with Time::HiRes not necessarily being
>> available, timestamps getting rounded to the nearest IEEE double,
>> etc).  Also, test -nt isn’t portable, we’d have to do the same
>> mess with ls -t that’s in the code setting at_ts_resolution.
>
> Since for the purpose of testing autom4te behaviour one should be able
> to assume autom4te is available, a solution for this issue would be to
> simply add a mechanism to autom4te (or find a creative way to do it
> with existing autom4te) which compares two file timestamps, and use
> that in the loop.

Oh, that's a good idea.  I'm not going to do it for 2.72 but I have filed
https://savannah.gnu.org/support/index.php?110989 so I don't forget about it.

zw

[sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a loop

[Zack Weinberg]

Update of sr#110989 (group autoconf):

Priority:   5 - Unprioritized => 3 - Release N+1


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110989] Improve reliability of AT_MTIME_DELAY in test suite with a loop

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110989>

 Summary: Improve reliability of AT_MTIME_DELAY in test suite
with a loop
   Group: Autoconf
   Submitter: zackw
   Submitted: Fri 22 Dec 2023 04:21:35 PM UTC
Priority: 5 - Unprioritized
Severity: 1 - Wish
  Status: Confirmed
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Fri 22 Dec 2023 04:21:35 PM UTC By: Zack Weinberg 
Recording this idea for the next release cycle:

On Fri, Dec 22, 2023, at 10:08 AM, Nick Bowler wrote:
> On 2023-12-22 09:28, Zack Weinberg wrote:
>> On Thu, Dec 21, 2023, at 10:07 PM, Jacob Bachmeyer wrote:
> [...]
>>> I suggest revising AT_MTIME_DELAY to actually create two files and
>>> loop touching one of them until the timestamps differ.
>> 
>> This won’t work, because whether *test* thinks two timestamps differ
>> may be different from whether *autom4te* thinks two timestamps differ
>> (due to the whole mess with Time::HiRes not necessarily being
>> available, timestamps getting rounded to the nearest IEEE double,
>> etc).  Also, test -nt isn’t portable, we’d have to do the same
>> mess with ls -t that’s in the code setting at_ts_resolution.
>
> Since for the purpose of testing autom4te behaviour one should be able
> to assume autom4te is available, a solution for this issue would be to
> simply add a mechanism to autom4te (or find a creative way to do it
> with existing autom4te) which compares two file timestamps, and use
> that in the loop.

Rather than adding it to autom4te itself, perhaps a tiny Perl script
that does the loop.  We would still need to detect whether automake
understands high-resolution timestamps.

It would also make sense for autom4te to ensure that its output file
is newer than its cache file.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110989>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: AT_MTIME_DELAY not working? (was: Re: [platform-testers] autoconf-2.72e released [release candidate])

[Zack Weinberg]

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 issue maybe ?
>>
>> Yeah, this one is <https://savannah.gnu.org/support/?110986>.
>> We're expecting the second of two autoconf runs in quick succession
>> to pull from a cache and sometimes it doesn't.  I get it
>> reproducibly on one of my test machines and I may try to pin it
>> down later today, but I don't think it's worth holding the release
>> for.
> Looking at tests/tools.at, I think I found the problem: the
> generated configure script is the /output/ from autoconf; there is
> no reason for its timestamp to matter.

That's a reasonable thing to think, but autom4te really does compare
the timestamp of a file in its cache, to the timestamp of the *output*
file, in order to decide whether to replace the output file.  Right at
the bottom of bin/autom4te.in:

  {
# Actual M4 expansion, if the user wants it, or if $output is old
# (STDOUT is pretty old).
handle_output ($req, $output)
  if $force || mtime ($output) <= mtime ($ocache . $req->id);
  }

It's been that way since autom4te was created (~2001).  I'm not 100%
sure I understand what it's doing but I believe this is *not* a bug.
It regenerates *the file in the cache* ($ocache . $req->id) if *that*
file is older than the inputs (configure.ac, aclocal.m4, etc, in this
case).  Then, if the file in the cache is now newer than the output
file, it replaces the output file.  It might make more sense to think
of this as a move-if-change operation, more or less (there's several
transforms in between what's in the cache and the actual output).

Any how, I see several ways autom4te could be improved, here, but I
think all of them are too invasive for today.  The ‘touch’ that
I added to the test case in 3fbfb13e7a846e98fa931b2bce373b5b2364a11b
should be good enough for 2.72.

> I suggest revising AT_MTIME_DELAY to actually create two files and
> loop touching one of them until the timestamps differ.

This won’t work, because whether *test* thinks two timestamps differ
may be different from whether *autom4te* thinks two timestamps differ
(due to the whole mess with Time::HiRes not necessarily being
available, timestamps getting rounded to the nearest IEEE double,
etc).  Also, test -nt isn’t portable, we’d have to do the same
mess with ls -t that’s in the code setting at_ts_resolution.

> A quick look at tests/local.at (on Git master) suggests a possible
> merge error probably unrealated to this issue: the AS_ECHO on line
> 222 that announces the detected mtime resolution is in the subshell
> that verifies that required programs are available instead of the
> main level just after the "rm -f conftest.ts?" on line 170 that
> cleans up the timestamp test files.

That’s intentional.  We report what timestamp resolution we are using
after we report the versions of all the programs that might affect
the outcome.

zw

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

[Zack Weinberg]

On Fri, Dec 22, 2023, at 8:22 AM, Zack Weinberg wrote:
> (But I'll also see if it's practical to mark this test as an expected
> failure on systems where the write error isn't detected.)

Thus.  Tested only on Linux.  I don't have access to a machine that
has *both* /dev/full and a buggy printf(1).  (Alan, I saw what you
said about zero-cost installation media for Solaris 11.4 but I have
several higher-priority things to resolve and setting up a VM could
easily eat my entire day.)

zw

diff --git a/tests/torture.at b/tests/torture.at
index 288a5a55..d98b92c0 100644
--- a/tests/torture.at
+++ b/tests/torture.at
@@ -291,7 +291,21 @@ AT_CHECK_CONFIG_CREATION(command)
 # Create a link
 AT_CHECK_CONFIG_CREATION(link)
 
-# Now check for write errors
+# Now check for write errors.
+# Depending on the shell, 'printf' might or might not report write
+# errors on stdout.  Check /bin/sh regardless of $SHELL, because
+# config.status always uses /bin/sh.
+# Note: another way to force a write error is with ulimit -f, but
+# depending on the OS it might not be possible to set that limit
+# lower than one disk block, so we'd have to make the tests below
+# produce much more output.
+test_write_errors=false
+if test -w /dev/full && test -c /dev/full; then
+  if /bin/sh -c 'printf "write errors detected?\\n"' > /dev/full 2> /dev/null
+  then :
+  else test_write_errors=:
+  fi
+fi
 
 # Create a file
 AT_CHECK_CONFIG_CREATION_NOWRITE(file)
@@ -301,7 +315,7 @@ AT_CHECK([echo from-stdin | ./config.status --file=file:-],
 AT_CHECK([grep from-stdin file], [], [from-stdin
 ])
 # Force write error creating a file on stdout
-if test -w /dev/full && test -c /dev/full; then
+if $test_write_errors; then
   AT_CHECK([./config.status --file=-:input /dev/full || exit 1],
   [1], [ignore], [ignore])
 fi
@@ -320,7 +334,7 @@ AT_CHECK([./config.status --header=-:input /dev/full || exit 1],
   [1], [ignore], [ignore])
 fi
-- 
2.41.0

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

[Zack Weinberg]

On Fri, Dec 22, 2023, at 8:22 AM, Zack Weinberg wrote:
> (But I'll also see if it's practical to mark this test as an expected
> failure on systems where the write error isn't detected.)

Thus.  Tested only on Linux.  I don't have access to a machine that
has *both* /dev/full and a buggy printf(1).  (Alan, I saw what you
said about zero-cost installation media for Solaris 11.4 but I have
several higher-priority things to resolve and setting up a VM could
easily eat my entire day.)

zw

diff --git a/tests/torture.at b/tests/torture.at
index 288a5a55..d98b92c0 100644
--- a/tests/torture.at
+++ b/tests/torture.at
@@ -291,7 +291,21 @@ AT_CHECK_CONFIG_CREATION(command)
 # Create a link
 AT_CHECK_CONFIG_CREATION(link)
 
-# Now check for write errors
+# Now check for write errors.
+# Depending on the shell, 'printf' might or might not report write
+# errors on stdout.  Check /bin/sh regardless of $SHELL, because
+# config.status always uses /bin/sh.
+# Note: another way to force a write error is with ulimit -f, but
+# depending on the OS it might not be possible to set that limit
+# lower than one disk block, so we'd have to make the tests below
+# produce much more output.
+test_write_errors=false
+if test -w /dev/full && test -c /dev/full; then
+  if /bin/sh -c 'printf "write errors detected?\\n"' > /dev/full 2> /dev/null
+  then :
+  else test_write_errors=:
+  fi
+fi
 
 # Create a file
 AT_CHECK_CONFIG_CREATION_NOWRITE(file)
@@ -301,7 +315,7 @@ AT_CHECK([echo from-stdin | ./config.status --file=file:-],
 AT_CHECK([grep from-stdin file], [], [from-stdin
 ])
 # Force write error creating a file on stdout
-if test -w /dev/full && test -c /dev/full; then
+if $test_write_errors; then
   AT_CHECK([./config.status --file=-:input /dev/full || exit 1],
   [1], [ignore], [ignore])
 fi
@@ -320,7 +334,7 @@ AT_CHECK([./config.status --header=-:input /dev/full || exit 1],
   [1], [ignore], [ignore])
 fi
-- 
2.41.0

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

[Zack Weinberg]

On Thu, Dec 21, 2023, at 11:54 PM, Nick Bowler wrote:
> On 2023-12-21 19:26, Paul Eggert wrote:
>> 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.
>
> I tested several modern, current operating systems, including:
>   OpenBSD 7, NetBSD 9, FreeBSD 13, Alpine Linux 3.15
> I also tested several not-so-modern systems, including:
>   DJGPP, HP-UX 11, Solaris 8.
>
> On every single one of these systems, the /usr/bin/printf (or equivalent)
> does not generally diagnose errors that occur when writing to standard
> output, and an exit status of 0 is returned.

Right, I'm starting a campaign when I get back from vacation in January.

(But I'll also see if it's practical to mark this test as an expected
failure on systems where the write error isn't detected.)

zw

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

[Zack Weinberg]

On Thu, Dec 21, 2023, at 3:51 PM, Nick Bowler wrote:
> On 2023-12-21 13:48, Zack Weinberg wrote:
>  > and an unsuccessful exit status.  I would guess that on your machine
>  > the printf built-in and/or standalone printf executable are not
>  > reporting write errors.
>
> I think it is not reasonable to expect any utility to report any kind
> of error on writes to standard output.  This is not normal behaviour
> for C programs and, in the case of printf utilities which are not shell
> builtins, such behaviour is likely unique to GNU.

Sorry, I'm with GNU here: failure to report errors on writing to stdout
is a bug.  No excuses will be accepted.

zw

[sr #110986] "autoconf: forbidden tokens, basic" testsuite failure on some systems

[Zack Weinberg]

Follow-up Comment #2, sr#110986 (group autoconf):

This is a regression caused by commit 
,
"Fix timing bug on high-speed builds".  That commit changed autom4te's logic
for deciding whether its output file is newer than its cache file: if their
modification times are equal, the output is considered out of date.  Since
both files are created in quick succession, on file systems with coarse
timestamps (1 or 2s resolution), it is very easy for their modification times
to be equal.

For 2.72 I'm going to make the test suite adjust the modification time of the
file that's supposed to be newer, but I'm also going to leave this bug open,
because autom4te _ought_ to be able to ensure that the cache file is always
observed to be older than the output.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: m4_foreach_w(...AC_DEFINE...) expansion change in 2.72e?

[Zack Weinberg]

On Thu, Dec 21, 2023, at 2:39 PM, Paul Eggert wrote:
> 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".

Thanks for checking, Paul.

I see the same phenomenon with 2.71, I can't reproduce any difference
between 2.71 and 2.72 (dev trunk), and I can fix the generated
config.h.in and configure by making two changes: Unquote
"kpse_otftotfm_auto_opts" in the second foreach (the one that invokes
AC_DEFINE), and insert a newline immediately after the close parenthesis
of the AS_IF().

The second change is not necessary to make m4_foreach_w iterate, but it
*is* necessary to prevent the *result* of the iteration from running
each "fi" together with the next "if", causing shell syntax errors.

Optionally, also change AC_FOREACH to m4_foreach_w to fix the warning
about AC_FOREACH being obsolete.

Karl: you said that unquoting "kpse_otftotfm_auto_opts" did _not_ fix
the problem for you.  Is it possible that there's some difference
between the complete Texlive configure script and the cut-down version
you posted, that's responsible for this?

zw

Re: m4_foreach_w(...AC_DEFINE...) expansion change in 2.72e?

[Zack Weinberg]

On Thu, Dec 21, 2023, at 2:20 PM, Zack Weinberg wrote:
> On Thu, Dec 21, 2023, at 1:40 PM, Karl Berry wrote:
>> 2.72e creates a different autoconf.h.in and configure in TeX Live's
>> texk/lcdf-typetools
>> (https://github.com/TeX-Live/texlive-source/tree/trunk/texk/lcdf-typetools):
> ...
>> In other words, what was four separate HAVE_AUTO_* macros have become one.
>>
>> The configure.ac code that generates this runs through those four values
>> using m4_foreach_w
>
> Oof.  I have no idea what's wrong here.  The code for m4_foreach_w has not
> changed since 2008.  What is the most recent version of Autoconf that
> generates autoconf.h.in correctly?

It would also be interesting to know if the --enable arguments are being
generated correctly from this code fragment (should be obvious from
configure --help output) because AC_FOREACH is a obsolete macro that's
*supposed* to be just another name for m4_foreach_w ... except that it
*might* be stripping a layer of quotes.

zw

Re: m4_foreach_w(...AC_DEFINE...) expansion change in 2.72e?

[Zack Weinberg]

On Thu, Dec 21, 2023, at 1:40 PM, Karl Berry wrote:
> 2.72e creates a different autoconf.h.in and configure in TeX Live's
> texk/lcdf-typetools
> (https://github.com/TeX-Live/texlive-source/tree/trunk/texk/lcdf-typetools):
...
> In other words, what was four separate HAVE_AUTO_* macros have become one.
>
> The configure.ac code that generates this runs through those four values
> using m4_foreach_w

Oof.  I have no idea what's wrong here.  The code for m4_foreach_w has not
changed since 2008.  What is the most recent version of Autoconf that
generates autoconf.h.in correctly?

zw

Re: [GNU Autoconf 2.72e] testsuite: 11 332 failed on OS X 10.9

[Zack Weinberg]

On Thu, Dec 21, 2023, at 1:32 PM, Sevan Janiyan wrote:
> Intel laptop running 10.10.5, m4 included with OS is too old
> (1.4.6), so GNU m4 1.4.18 was used.
...
> ERROR: 549 tests were run,
> 6 failed (4 expected failures).
> 60 tests were skipped.

(ignoring test #11, as that's a known issue)

...
>   332: acc.at:20  AC_PROG_CC_C_O
...
>  > configure:2575: checking for C compiler version
>  > configure:2584: gcc --version >&5
>  > Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
>  > Target: x86_64-apple-darwin13.4.0
...
>  > configure:3008: gcc -std=gnu11 -c -g -O2  conftest.c >&5
>  > configure:3008: $? = 0
>  > configure:3030: result: -std=gnu11
>  > configure:3146: checking whether gcc -std=gnu11 and cc understand -c and 
> -o together
>  > configure:3178: gcc -std=gnu11 -c conftest.cpp -o conftest2.o >&5
>  > error: invalid argument '-std=gnu11' not allowed with 'C++/ObjC++'

Congratulations, you found a bug in Autoconf proper, not just in the
testsuite!  AC_PROG_CC_C_O is specifically a test of the C compiler.
There's another macro AC_PROG_CXX_C_O that does the same test on the
C++ compiler (and two more for Fortran compilers).  They should all be
either refusing to execute under the wrong AC_LANG setting, or ignoring
the AC_LANG setting; not invoking the C compiler, using C-specific options,
on a C++ source file.

As these macros are testing for a feature that's missing only from
very old compilers (from the mid-1990s at the latest), as the thing
the testsuite does to trigger the bug is somewhat bizarre compared to
what any real configure.ac is likely to be doing, and as the above
misuse of the C++ compiler is harmless with *most* versions of GCC
and Clang, I'm going to leave everything as is for release 2.72.
I filed https://savannah.gnu.org/support/index.php?110987 so we
don't forget about it.

zw

[sr #110987] AC_PROG_CC_C_O + AC_LANG([C++]) combines C-specific compiler options with C++ source

[Zack Weinberg]

Update of sr#110987 (group autoconf):

Priority:   5 - Unprioritized => 2 - Eventually 

___

Follow-up Comment #1:

Low priority as this affects only unusual configure.ac layout, and as all of
the AC_PROG_*_C_O macros are testing for a problem that exists only in very
old compilers. 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110987] AC_PROG_CC_C_O + AC_LANG([C++]) combines C-specific compiler options with C++ source

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110987>

 Summary: AC_PROG_CC_C_O + AC_LANG([C++]) combines C-specific
compiler options with C++ source
   Group: Autoconf
   Submitter: zackw
   Submitted: Thu 21 Dec 2023 07:14:49 PM UTC
Priority: 5 - Unprioritized
Severity: 2 - Minor
  Status: Confirmed
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Thu 21 Dec 2023 07:14:49 PM UTC By: Zack Weinberg 
A configure.ac like this


AC_INIT
AC_LANG([C++])
AC_PROG_CC_C_O
...


may (depending on exactly which compiler you have) run a compilation command
that combines C-specific options with a C++ source file.  Some compilers
object to this:


configure:2575: checking for C compiler version
configure:2584: gcc --version >&5
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
...
configure:3008: gcc -std=gnu11 -c -g -O2  conftest.c >&5
configure:3008: $? = 0
configure:3030: result: -std=gnu11
configure:3146: checking whether gcc -std=gnu11 and cc understand -c and -o
together
configure:3178: gcc -std=gnu11 -c conftest.cpp -o conftest2.o >&5
error: invalid argument '-std=gnu11' not allowed with 'C++/ObjC++'


and that in turn causes the test to get the wrong answer, thinking the C++
compiler does *not* support -c and -o together, when it does.

AC_PROG_CC_C_O is specifically a test of the C compiler. There's another macro
AC_PROG_CXX_C_O that does the same test on the C++ compiler (and two more for
Fortran compilers).  They should all be
either refusing to execute under the wrong AC_LANG setting, or ignoring the
AC_LANG setting; not invoking the C compiler, using C-specific options, on a
C++ source file.

Originally reported by Sevan Janiyan.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110987>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

[Zack Weinberg]

On Thu, Dec 21, 2023, at 12:34 PM, Alan Coopersmith wrote:
> For 119, the code in the Solaris find command that prints the
> "find: cannot read dir sub/unwritable" message was modified last year
> to make it not print that message if -prune was in effect for the directory,
> so it's possible a bug in find was introduced by those changes.

Yes, I believe this is a recently introduced bug in Solaris find.
This sequence of shell commands should reproduce:

mkdir sub
mkdir sub/unwritable
touch sub/unwritable/file
chmod a-wx sub/unwritable
find sub -type d ! -perm -700 -exec chmod u+rwx {} \;

As -depth is not in use here, find should execute the chmod _before_
attempting to descend into "sub/unwritable", and that should make the
directory accessible again.  I tested the above sequence of commands on
all the following operating systems, and did not encounter any errors:

aarch64c-freebsd14.0
powerpc-aix7.1.5.0
powerpc-aix7.3.1.0
sparc-solaris2.10
sparc-solaris2.11
x86_64-linux
x86_64-freebsd13.2
x86_64-netbsd9.3
x86_64-openbsd7.4

As previously mentioned, the Solaris 11 machine I have access to is
version 11.3 (unknown patch level; if you know how to get anything
more specific than that, please let me know).

> For 261, Solaris gained a /dev/full device in Solaris 11.4.51.
> Since the only purpose of this device is to return ENOSPC, I would
> hope that it's fully compatible with the implementations on other OS'es,
> but I don't know of any testing done to confirm that.

This may be a bug in your /bin/sh or {/usr,}/bin/printf.  The command
that failed in this test is

./config.status --header=-:input /dev/full

which is *expected* to print an error message (on stderr) and exit
unsuccessfully, but on your test machine it printed nothing and exited
successfully.

When I execute this command on my Linux workstation, using the files
'config.status' and 'input' from your tarball, I get

./config.status: line 978: printf: write error: No space left on device
config.status: error: could not create -

and an unsuccessful exit status.  I would guess that on your machine
the printf built-in and/or standalone printf executable are not
reporting write errors.

Since I don't have access to a Solaris 11.4 machine myself, and since
both of these appear to be plain bugs in the shell and utilities, I'm
currently not planning to make any changes because of these failures.
Please let me know if you disagree; in which case, please suggest what
we should do, because I don't see any good workaround in Autoconf's code
for either issue.

Thanks again for testing.
zw

Re: [GNU Autoconf 2.72e] testsuite: 11 40 41 45 280 281 282 286 287 failed on OS X 10.4

[Zack Weinberg]

On Thu, Dec 21, 2023, at 9:03 AM, Zack Weinberg wrote:
> On Wed, Dec 20, 2023, at 6:29 PM, Sevan Janiyan wrote:
>> aclocal: unrecognized option -- `--system-acdir=/Users/sme/tmp/autoconf-
>> 2.72e/tests/testsuite.dir/040/empty'
>
> This means your automake, version 1.6.3, is too old.  The current
> version is 1.16.5. Please try installing that version and see if that
> makes the above failures go away.

I have pushed a change which should make the test suite skip all
the tests that won't work if it encounters an aclocal that doesn't
understand --system-acdir. That includes all of 40 41 45 280 281
282 286 287.

zw

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

[Zack Weinberg]

On Wed, Dec 20, 2023, at 4:57 PM, Alan Coopersmith wrote:
> Failed tests:
> GNU Autoconf 2.72e test suite test groups:
>
>   NUM: FILE-NAME:LINE TEST-GROUP-NAME
>KEYWORDS
>
>11: tools.at:442   autoconf: forbidden tokens, basic
>   119: m4sh.at:2115   _AS_CLEAN_DIR
>   261: torture.at:189 AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS
>
> I don't see any obvious causes for these.  testsuite.log attached.

#119 and #261 pass for me on sparc64-sun-solaris11.3
(SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise).

Would you mind sending us a tarball of tests/testsuite.dir/{119,261}
from the machine where they failed?

zw

Re: [GNU Autoconf 2.72e] testsuite: 11 40 41 45 280 281 282 286 287 failed on OS X 10.4

[Zack Weinberg]

On Wed, Dec 20, 2023, at 6:29 PM, Sevan Janiyan wrote:
> G5 running OS X 10.4.11, m4 included with OS is too old (1.4.2), so GNU 
> m4 1.4.19 was used.

Thanks for all the testing.  The failure of test #11 is a known, minor
issue, see .

>40: tools.at:1462  autoupdating with aclocal and m4_include
>41: tools.at:1497  autom4te preselections
>45: tools.at:1708  autotools and relative TMPDIR
>   280: torture.at:1456Configuring subdirectories
>   281: torture.at:1584Deep Package
>   282: torture.at:1723Non-Autoconf AC_CONFIG_SUBDIRS
>   286: torture.at:1874Unusual Automake input files
>   287: torture.at:1909Specific warnings options for autoreconf

These I have not seen before, however...

> aclocal: unrecognized option -- 
> `--system-acdir=/Users/sme/tmp/autoconf-2.72e/tests/testsuite.dir/040/empty'

This means your automake, version 1.6.3, is too old.  The current version is 
1.16.5.
Please try installing that version and see if that makes the above failures go 
away.

Thanks,
zw

Re: autoconf-2.72e released [release candidate]

[Zack Weinberg]

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-based environments would be
>> particularly helpful.  Testing your own project’s configure.ac with
>> the new autoconf is also particularly helpful.
>
> I tested over 200 of the X.Org packages hosted under
> https://gitlab.freedesktop.org/xorg/ with autoconf-2.72e (along with
> automake 1.16.5 & libtool 2.4.7) on Solaris 11.4 x86, with each of
> the gcc 13.2.0, clang 13.0.1, and Solaris Studio 12.6 compilers, and
> didn't see any problems - they all seemed to build successfully.

Good to hear.  If you do find yourself with a little extra time, a really
useful thing to do is diff each package's config.h as generated by 2.72e
with config.h as generated by an older version of autoconf.  Differences
are not necessarily bugs but they are worth investigating.

> I did see 3 failures from "gmake check" with autoconf-2.72e, which I
> reported separately to bug-autoconf:
> https://lists.gnu.org/archive/html/bug-autoconf/2023-12/msg00156.html

Will follow up there.

zw

Re: [platform-testers] autoconf-2.72e released [release candidate]

[Zack Weinberg]

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)
>
> So far I got it on aarch64 and s390x. Timing issue maybe ?

Yeah, this one is <https://savannah.gnu.org/support/?110986>.  We're expecting
the second of two autoconf runs in quick succession to pull from a cache and
sometimes it doesn't.  I get it reproducibly on one of my test machines and
I may try to pin it down later today, but I don't think it's worth holding
the release for.

zw

Re: [platform-testers] autoconf-2.72e released [release candidate]

[Zack Weinberg]

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 (semantics.at:908)
> 421: AC_SYS_YEAR2038 FAILED (semantics.at:917)
> 422: AC_SYS_YEAR2038_RECOMMENDED FAILED (semantics.at:926)

This is .  It can only affect
projects that use one of the above three macros while AC_LANG([C++]) or
AC_LANG([ObjC]) is active, and it's harmless on a system with 64-bit off_t.
Furthermore, the changes that would be required to fix it properly seem a bit
too risky considering I want to make the release this week and not six weeks
from now.  I could be persuaded otherwise with an example of a real project that
breaks, or a patch that turns out less invasive than I expect, or both.

zw

autoconf-2.72e released [release candidate]

[Zack Weinberg]

-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 configure.ac with
the new autoconf is also particularly helpful.

Unless there are show-stopper bugs, I intend to make the final
release in 48 hours, on 2023 December 22.

There have been 19 commits by 4 people in the 20 days since 2.72d.
See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Bruno Haible (1)
  Detlef Riekenberg (1)
  Paul Eggert (5)
  Zack Weinberg (12)

zw
 [on behalf of the autoconf maintainers]
==

Here is the GNU autoconf home page:
http://gnu.org/s/autoconf/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=v2.72e
or run this command from a git-cloned autoconf directory:
  git shortlog v2.72e..v2.72e

Here are the compressed sources:
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.gz   (2.1MB)
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.xz   (1.4MB)

Here are the GPG detached signatures:
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.gz.sig
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

  8352c1ebf9e1f0c2f62cc31426ea6da02475195d  autoconf-2.72e.tar.gz
  80eNO1l9UfXWFZb7L29quknN2XS0sF/wusV/VrXP2zk=  autoconf-2.72e.tar.gz
  f85f9f1044bfc5fadd550c2c2fea15a541e5c02e  autoconf-2.72e.tar.xz
  fNwkseg6uiFz0+LdAoPgCpMWtKomDlk5I8frrgIX2co=  autoconf-2.72e.tar.xz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify autoconf-2.72e.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2010-01-14 [SC]
82F8 54F3 CE73 174B 8B63  1740 91FC C32B 6769 AA64
  uid   Zack Weinberg 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key za...@panix.com

  gpg --recv-keys 91FCC32B6769AA64

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=autoconf=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify autoconf-2.72e.tar.gz.sig

This release was bootstrapped with the following tools:
  Automake 1.16.5

NEWS since 2.71:

* Noteworthy changes in release 2.72e (2023-12-20) [release candidate]

** Further improvements to subsecond timestamp handling

  Two subtle bugs were fixed.  Also, ‘autom4te --version’ now reports
  whether autom4te is capable of reading subsecond timestamps from
  the file system, enabling other programs (notably Automake) to
  adjust their own behavior appropriately.

  There may still be problems with subsecond timestamps (see below).
  Because timestamp comparison is only used for autom4te’s cache,
  the only practical effect of these problems is to cause spurious
  failures in Autoconf and Automake’s test suites, in tests of the
  cache itself.

** Significant bug fixes

*** autom4te works with perl 5.6.x again
*** BusyBox ‘mkdir’ is correctly identified
*** AC_FUNC_MMAP successfully detects mmap on CheriBSD
*** Better error message for calling m4_warn() with a bad first argument

** Known bugs

*** AC_SYS_LARGEFILE and AC_SYS_YEAR2038 only work correctly in C mode.

  This is only a problem for configure scripts that invoke either
  macro while AC_LANG([something other than C]) is in effect, and
  will only be a *visible* problem on systems where support
  for large files and/or timestamps after 2038 are *available*
  but not enabled by default.

  See <https://savannah.gnu.org/support/index.php?110983> for details
  and a workaround.

*** “autoconf: forbidden tokens, basic” testsuite failure

  We believe this is another subtle bug in autom4te’s handling of
  timestamps that are very close together.  It only happens on some
  operating systems and/or some file systems.  It can safely be ignored.
  See <https://savannah.gnu.org/support/index.php?110986> for more detail.

*** “Substitute and define special characters” testsuite failure

  We believe this to be a bug in some versions of NetBSD /bin/sh.
  If you see this failure on any sy

autoconf-2.72e released [release candidate]

[Zack Weinberg]

-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 configure.ac with
the new autoconf is also particularly helpful.

Unless there are show-stopper bugs, I intend to make the final
release in 48 hours, on 2023 December 22.

There have been 19 commits by 4 people in the 20 days since 2.72d.
See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

  Bruno Haible (1)
  Detlef Riekenberg (1)
  Paul Eggert (5)
  Zack Weinberg (12)

zw
 [on behalf of the autoconf maintainers]
==

Here is the GNU autoconf home page:
http://gnu.org/s/autoconf/

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=v2.72e
or run this command from a git-cloned autoconf directory:
  git shortlog v2.72e..v2.72e

Here are the compressed sources:
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.gz   (2.1MB)
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.xz   (1.4MB)

Here are the GPG detached signatures:
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.gz.sig
  https://alpha.gnu.org/gnu/autoconf/autoconf-2.72e.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

  8352c1ebf9e1f0c2f62cc31426ea6da02475195d  autoconf-2.72e.tar.gz
  80eNO1l9UfXWFZb7L29quknN2XS0sF/wusV/VrXP2zk=  autoconf-2.72e.tar.gz
  f85f9f1044bfc5fadd550c2c2fea15a541e5c02e  autoconf-2.72e.tar.xz
  fNwkseg6uiFz0+LdAoPgCpMWtKomDlk5I8frrgIX2co=  autoconf-2.72e.tar.xz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify autoconf-2.72e.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   rsa4096 2010-01-14 [SC]
82F8 54F3 CE73 174B 8B63  1740 91FC C32B 6769 AA64
  uid   Zack Weinberg 

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key za...@panix.com

  gpg --recv-keys 91FCC32B6769AA64

  wget -q -O- 
'https://savannah.gnu.org/project/release-gpgkeys.php?group=autoconf=1'
 | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify autoconf-2.72e.tar.gz.sig

This release was bootstrapped with the following tools:
  Automake 1.16.5

NEWS since 2.71:

* Noteworthy changes in release 2.72e (2023-12-20) [release candidate]

** Further improvements to subsecond timestamp handling

  Two subtle bugs were fixed.  Also, ‘autom4te --version’ now reports
  whether autom4te is capable of reading subsecond timestamps from
  the file system, enabling other programs (notably Automake) to
  adjust their own behavior appropriately.

  There may still be problems with subsecond timestamps (see below).
  Because timestamp comparison is only used for autom4te’s cache,
  the only practical effect of these problems is to cause spurious
  failures in Autoconf and Automake’s test suites, in tests of the
  cache itself.

** Significant bug fixes

*** autom4te works with perl 5.6.x again
*** BusyBox ‘mkdir’ is correctly identified
*** AC_FUNC_MMAP successfully detects mmap on CheriBSD
*** Better error message for calling m4_warn() with a bad first argument

** Known bugs

*** AC_SYS_LARGEFILE and AC_SYS_YEAR2038 only work correctly in C mode.

  This is only a problem for configure scripts that invoke either
  macro while AC_LANG([something other than C]) is in effect, and
  will only be a *visible* problem on systems where support
  for large files and/or timestamps after 2038 are *available*
  but not enabled by default.

  See <https://savannah.gnu.org/support/index.php?110983> for details
  and a workaround.

*** “autoconf: forbidden tokens, basic” testsuite failure

  We believe this is another subtle bug in autom4te’s handling of
  timestamps that are very close together.  It only happens on some
  operating systems and/or some file systems.  It can safely be ignored.
  See <https://savannah.gnu.org/support/index.php?110986> for more detail.

*** “Substitute and define special characters” testsuite failure

  We believe this to be a bug in some versions of NetBSD /bin/sh.
  If you see this failure on any sy

[sr #110986] "autoconf: forbidden tokens, basic" testsuite failure on some systems

[Zack Weinberg]

Update of sr#110986 (group autoconf):

Priority:   5 - Unprioritized => 3 - Release N+1

___

Follow-up Comment #1:

The worst practical consequence of this is only that we may run M4 more often
than we needed to, but I'm still marking this as desirable to fix soon if we
can, just because it looks bad to have a known failure so early in the test
suite.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110986] "autoconf: forbidden tokens, basic" testsuite failure on some systems

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110986>

 Summary: "autoconf: forbidden tokens, basic" testsuite
failure on some systems
   Group: Autoconf
   Submitter: zackw
   Submitted: Wed 20 Dec 2023 02:11:14 PM UTC
Priority: 5 - Unprioritized
Severity: 2 - Minor
  Status: Need Info
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Wed 20 Dec 2023 02:11:14 PM UTC By: Zack Weinberg 
Observed by me on at least x86_64-netbsd9 and sparc64-solaris10: the
"autoconf: forbidden tokens, basic" test fails because the second invocation
of autoconf prints the same "possibly undefined token" error messages as the
first invocation, contrary to the test's expectations.  This is probably more
fallout from the sub-second timestamp changes: the second invocation is
supposed to pull 'configure' from cache and not re-run M4.  Unfortunately, the
second invocation of autoconf clobbers the mtime of all the files involved,
making it difficult to figure out exactly what went wrong after the fact.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110986>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110985] "Substitute and define special characters" test fails on NetBSD 9

[Zack Weinberg]

Update of sr#110985 (group autoconf):

Priority:   5 - Unprioritized => 2 - Eventually 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110985] "Substitute and define special characters" test fails on NetBSD 9

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110985>

 Summary: "Substitute and define special characters" test
fails on NetBSD 9
   Group: Autoconf
   Submitter: zackw
   Submitted: Wed 20 Dec 2023 01:59:11 PM UTC
Priority: 5 - Unprioritized
Severity: 2 - Minor
  Status: Need Info
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Wed 20 Dec 2023 01:59:11 PM UTC By: Zack Weinberg 
On x86_64-unknown-netbsd9.3, running Autoconf's test suite consistently
produces this failure:


Failed tests:
 NUM: FILE-NAME:LINE TEST-GROUP-NAME
 270: torture.at:913 Substitute and define special characters


This test checks whether it is possible to pass a string through AC_SUBST that
includes a byte with every possible value except 0x00.

The log for the testsuite says


configure: creating ./config.status
config.status: creating Foo
config.status: creating Zardoz
config.status: creating config.h
./torture.at:987: cat Foo
./torture.at:1000: cmp allowed-chars Zardoz
--- /dev/null   2023-12-19 14:19:58.701932966 -0500
+++
/net/u/1/z/zackw/autoconf-2.72d.16-9800e-dirty/tests/testsuite.dir/at-groups
/270/stdout 2023-12-19 14:19:58.910181000 -0500
@@ -0,0 +1 @@
+allowed-chars Zardoz differ: char 256, line 2
./torture.at:1000: exit code was 1, expected 0


Comparing hex dumps of the files "allowed-chars" and "Zardoz" shows that the
problem is that an extra byte (with value 0x81) has been inserted before each
byte with a value in the range 0x81 through 0x8b.  The extra bytes are *not*
present in the value of @zardoz@ recorded in config.status, but they *are*
present in the temporary file `subs1.awk` used by config.status (to see this
file run `./config.status -d` and then look in the directory named confXX,
where XX is some random sequence of alphanumerics).  Thus, this appears to
be a bug in the handling of here documents in this system's /bin/sh.  However,
the obvious cut-down version of the code in config.status does _not_ show the
bug:


$ printf 'xxd
<<\\EOF\n\x80\x81\x82\x83\x84\x85\x86\x87\n\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\nEOF\n'
> test.sh
$ /bin/sh test.sh
: 8081 8283 8485 8687 0a88 898a 8b8c 8d8e  
0010: 8f0a ..


We need to pin down exactly what the bug is before we can do anything about
it.

If you encounter a failure in this test on any platform _besides_
*-unknown-netbsd9*, please post a comment here.  Please attach a tarball of
the directory tests/testsuite.dir/270 (note: the number may be different if
you are testing a version of Autoconf other than 2.72).






___
File Attachments:


---
Date: Wed 20 Dec 2023 01:59:11 PM UTC  Name: failed-test-270.tar.gz  Size:
133KiB   By: zackw

<http://savannah.gnu.org/support/download.php?file_id=55471>

___

Reply to this item at:

  <https://savannah.gnu.org/support/?110985>

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH] [committed] autom4te: Don’t crash if Data::Dumper::Sortkeys is unavailable.

[Zack Weinberg]

On Tue, Dec 19, 2023, at 7:13 PM, Paul Eggert wrote:
>
> Solaris 10: the OS version that refuses to die

If I ever get around to CI for autoconf, one of the workers is going to be set 
up with "Heirloom" utilities, the least capable shell I can find that still 
passes M4sh's acceptance test, and the oldest supported version of every other 
tool we use.

zw

[sr #110983] AC_SYS_LARGEFILE doesn't honor AC_LANG setting

[Zack Weinberg]

Follow-up Comment #4, sr#110983 (group autoconf):

@Paul Eggert: Not today, hopefully tomorrow.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110983] AC_SYS_LARGEFILE doesn't honor AC_LANG setting

[Zack Weinberg]

Follow-up Comment #3, sr#110983 (group autoconf):

As a workaround, make sure to invoke AC_SYS_LARGEFILE and/or AC_SYS_YEAR2038
early in configure.ac (this is a good idea anyway, as they can affect the
results of later checks), in C mode, even if nothing else uses the C compiler.
 For example:


AC_INIT([my-C++-program], [1.0], ...)
AC_PROG_CC
AC_SYS_LARGEFILE
AC_PROG_CXX
AC_LANG([C++])
# rest of the configure script
AC_OUTPUT




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110983] AC_SYS_LARGEFILE doesn't honor AC_LANG setting

[Zack Weinberg]

Update of sr#110983 (group autoconf):

Priority:   5 - Unprioritized => 3 - Release N+1
Severity:  3 - Normal => 4 - Important  
Operating System: Solaris => None   

___

Follow-up Comment #1:

I don't want to mess with AC_SYS_LARGEFILE this close to a release, but we
should prioritize fixing this very soon afterward.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110983] AC_SYS_LARGEFILE doesn't honor AC_LANG setting

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110983>

 Summary: AC_SYS_LARGEFILE doesn't honor AC_LANG setting
   Group: Autoconf
   Submitter: zackw
   Submitted: Tue 19 Dec 2023 06:36:10 PM UTC
Priority: 5 - Unprioritized
Severity: 3 - Normal
  Status: Confirmed
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Solaris


___

Follow-up Comments:


---
Date: Tue 19 Dec 2023 06:36:10 PM UTC By: Zack Weinberg 
_AC_SYS_LARGEFILE_PROBE unconditionally modifies $CC, regardless of the
current AC_LANG setting. Therefore, a configure script like this


AC_INIT
AC_LANG([C++])
AC_SYS_LARGEFILE
AC_OUTPUT


will *not* enable large file support, on a system where it's off by default
but can be enabled.  Because it put -D_FILE_OFFSET_BITS=64 into $CC, where
AC_COMPILE_IFELSE won't pick it up because we're using $CXX instead.

Since AC_SYS_YEAR2038 depends on AC_SYS_LARGEFILE, this affects that macro as
well.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110983>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110982] Autotest: add some way to declare an expected failure halfway through the test

[Zack Weinberg]

Update of sr#110982 (group autoconf):

Priority:   5 - Unprioritized => 3 - Release N+1


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110982] Autotest: add some way to declare an expected failure halfway through the test

[Zack Weinberg]

URL:
  <https://savannah.gnu.org/support/?110982>

 Summary: Autotest: add some way to declare an expected
failure halfway through the test 
   Group: Autoconf
   Submitter: zackw
   Submitted: Tue 19 Dec 2023 06:26:52 PM UTC
Priority: 5 - Unprioritized
Severity: 1 - Wish
  Status: Confirmed
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None


___

Follow-up Comments:


---
Date: Tue 19 Dec 2023 06:26:52 PM UTC By: Zack Weinberg 
Shell code in the argument of AT_XFAIL_IF is always executed at the very
beginning of the test group, and, in fact, outside the subshell for the body
of the test group.  This is not documented.

Some of Autoconf's tests can only know for certain that the test is going to
fail due to a known bug, after doing several other operations that are
properly AT_CHECKed.  (Those operations are not affected by the known bug.) 
There should be a macro like AT_XFAIL_IF, but whose shell code is executed at
the point it appears in the test group.  Also, the documentation should
explain which AT_* macros' shell code gets hoisted to the beginning of the
test group.







___

Reply to this item at:

  <https://savannah.gnu.org/support/?110982>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110503] Autoconf 2.70 problem: gkt-doc/gtkdocize is now unconditionally required

[Zack Weinberg]

Update of sr#110503 (group autoconf):

Priority: 7 - Release N (Desirable) => 3 - Release N+1
  Status:   Need Info => Confirmed  

___

Follow-up Comment #7:

I understand the problem now.  You have an aclocal.m4 that defines
GTK_DOC_CHECK, so the m4_ifdef evaluates true and autoreconf *does* observe a
use of the macro and therefore tries to invoke gtkdocize.

In order to figure out how to make autoreconf reliable regardless of what's
available on the system, we're going to need to read up on actual uses of
gtk-doc and also on what pieces of it people tend to have installed, and there
isn't time for that before the next release, so I'm marking this deferred.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

[Zack Weinberg]

Update of sr#110554 (group autoconf):

Priority: 7 - Release N (Desirable) => 3 - Release N+1
  Status:  Ready For Test => In Progress

___

Follow-up Comment #2:

Turns out either your change or my change will break config.status on Solaris
10, because its /usr/bin/awk is incredibly limited.  It has a "nawk" that is
more capable, but we'd have to notice that we need to use that, and
config.status isn't currently bothering.

With regret, this pushes this change over the line to 'too risky when I want
to make the release this Friday'.

Revert:



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110927] 30 tests fail building on macOS Venture 13.5.1 with Xcode 14.3.1

[Zack Weinberg]

Update of sr#110927 (group autoconf):

  Status:  Ready For Test => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110872] m4_warn differs in various ways from its documentation

[Zack Weinberg]

Update of sr#110872 (group autoconf):

  Status: In Progress => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Revised, committed patch:
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=725652b0d81c163315aeac70d1e6b114be7ad767


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[PATCH v2, committed] Clarify error messages for misuse of m4_warn and --help for -W.

[Zack Weinberg]

m4_warn([category], [message]) passes its arguments directly to
Autom4te::Channels::msg.  If the category argument is not a recognized
“channel”, that function will crash and emit a *Perl* stack trace,
which makes it look like there’s something wrong with autoconf or
autom4te, rather than something wrong with the script.

Making matters worse, in autoconf 2.69, the manual said you could
use “all” and the empty string as the first argument to m4_warn.
As far as I can tell, neither of those was ever a valid message
channel, and the manual was corrected in 2.70, but we still got
a bug report from someone who tried it.

This patch makes us issue a nice helpful user error, instead of a
confusing internal error, when Autom4te::Channels::msg is called with
a bogus channel argument.  If the bogus channel is “all” or the empty
string, that error is demoted to a -Wobsolete warning.  If it is one
of the other special tokens recognized by -W, we customize the error
message, since someone might’ve thought that “none” being acceptable
to -W meant it was also acceptable to m4_warn.  The --help output for
autoconf, autoheader, autom4te, and autoreconf is also adjusted to
clarify that not all of the tokens recognized by -W count as
warning categories.

(Oddly enough, the lack of filtration at the autom4te level means
m4_warn([error], […]) actually does issue an error.  There’s no other
way to get exactly that effect — m4_errprintn(…)  and m4_fatal(…)
both do something a little different — so I I propose to leave that
alone for now and promote it to a proper, documented feature, probably
spelled m4_error(…), post-2.72.)

Channels.pm and ChannelDefs.pm are shared with Automake.  I believe
there is nothing you can write in a Makefile.am that will cause
Automake::Channels::msg to be called with an arbitrary user-supplied
channel argument, so these changes should have no visible effect on
that side of the fence.

Addresses .

 * lib/Autom4te/Channels.pm (msg): If the channel argument is invalid,
   don’t crash; report the mistake and use the ‘syntax’ channel.
   (report_bad_channel): New function for reporting invalid channels.

 * lib/Autom4te/ChannelDefs.pm (usage): Clarify that the list of
   warning categories is exhaustive, and that “all”, “none”,
   “no-CATEGORY”, and “error” are not warning categories.

 * bin/autoconf.in, bin/autoheader.in, bin/autom4te.in,
   bin/autoreconf.in: Tweak --help text.

 * tests/m4sugar.at (m4@@_warn (bad categories)): New test.
---
 bin/autoconf.in |  1 +
 bin/autoheader.in   |  1 +
 bin/autom4te.in |  1 +
 bin/autoreconf.in   | 10 +++---
 lib/Autom4te/ChannelDefs.pm | 10 +++---
 lib/Autom4te/Channels.pm| 47 ++-
 tests/m4sugar.at| 63 +
 7 files changed, 122 insertions(+), 11 deletions(-)

diff --git a/bin/autoconf.in b/bin/autoconf.in
index 060a9a04..5f4a2e5c 100644
--- a/bin/autoconf.in
+++ b/bin/autoconf.in
@@ -64,6 +64,7 @@ Operation modes:
   -f, --force   consider all files obsolete
   -o, --output=FILE save output in FILE (stdout is the default)
   -W, --warnings=CATEGORY   report the warnings falling in CATEGORY
+(comma-separated list accepted)
 
 " . Autom4te::ChannelDefs::usage . "
 
diff --git a/bin/autoheader.in b/bin/autoheader.in
index 4afa5f13..f5af0df2 100644
--- a/bin/autoheader.in
+++ b/bin/autoheader.in
@@ -74,6 +74,7 @@ or else 'configure.in'.
   -d, --debug  don\'t remove temporary files
   -f, --force  consider all files obsolete
   -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
+   (comma-separated list accepted)
 
 " . Autom4te::ChannelDefs::usage . "
 
diff --git a/bin/autom4te.in b/bin/autom4te.in
index 8957a6c9..2e4e7d52 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
@@ -160,6 +160,7 @@ Operation modes:
   -o, --output=FILEsave output in FILE (defaults to '-', stdout)
   -f, --force  don't rely on cached values
   -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
+   (comma-separated list accepted)
   -l, --language=LANG  specify the set of M4 macros to use
   -C, --cache=DIRECTORYpreserve results for future runs in DIRECTORY
   --no-cache   disable the cache
diff --git a/bin/autoreconf.in b/bin/autoreconf.in
index c6077efe..285d0f49 100644
--- a/bin/autoreconf.in
+++ b/bin/autoreconf.in
@@ -84,20 +84,18 @@ Operation modes:
   --no-recursive   don't rebuild sub-packages
   -s, --symlinkwith -i, install symbolic links instead of copies
   -m, --make   when applicable, re-run ./configure && make
-  -W, --warnings=CATEGORY  report the warnings falling in CATEGORY [syntax]
+  -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
+   (comma-separated list 

Re: AC_FUNC_MMAP not testing what the comments say

[Zack Weinberg]

I'll merge this after I do some testing.

On Mon, Dec 18, 2023, at 2:02 PM, Brooks Davis wrote:
> Thanks!  That's basically what I tested by hand on CheriBSD.
>
> -- Brooks
>
> On Fri, Dec 15, 2023 at 06:24:05PM -0800, Paul Eggert wrote:
>> 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, 15 Dec 2023 18:21:39 -0800
>> Subject: [PATCH] Fix AC_FUNC_MMAP on CheriBSD
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>> 
>> Problem reported by Brooks Davis in:
>> https://lists.gnu.org/r/autoconf/2023-12/msg00022.html
>> * lib/autoconf/functions.m4: Don???t unmap, since we
>> want to test remapping something already mapped,
>> and unmapping breaks on CheriBSD.
>> ---
>>  lib/autoconf/functions.m4 | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
>> index 4cfb5142..9b3f3c02 100644
>> --- a/lib/autoconf/functions.m4
>> +++ b/lib/autoconf/functions.m4
>> @@ -1385,8 +1385,7 @@ main (void)
>>  if (*(data2 + i))
>>return 7;
>>close (fd2);
>> -  if (munmap (data2, pagesize))
>> -return 8;
>> +  /* 'return 8;' not currently used.  */
>>  
>>/* Next, try to mmap the file at a fixed address which already has
>>   something else allocated at it.  If we can, also make sure that
>> -- 
>> 2.43.0
>>

Re: [bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

[Zack Weinberg]

On Fri, Dec 15, 2023, at 6:52 PM, Karl Berry wrote:
> Hi Zack,
>
> Since this touches code shared between Autoconf and Automake, I'm not
> checking it in yet and I'm requesting comments from both sides of the
> fence.
>
> Well, it seems good to me in principle, FWIW. I don't think this
> directly affects automake?

I doubt it, unless there's something you can put in a Makefile.am that will
cause Automake::Channels::msg to be called with a user-controlled $channel
argument.  (On the autoconf side of the fence, m4_warn([channel], [message])
does exactly that, hence the patch.)

zw

Re: [bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

[Zack Weinberg]

On Fri, Dec 15, 2023, at 7:08 PM, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
>> [...]
>> Also, there’s a perl 2.14ism in one place (s///a) which I need
>> to figure out how to make 2.6-compatible before it can land.
...
>> +  $q_channel =~ s/([^\x20-\x7e])/"\\x".sprintf("%02x", ord($1))/aeg;
...
> If I am reading perlre correctly, you should be able to simply drop the 
> /a modifier because it has no effect on the pattern you have written, 
> since you are using an explicit character class and are *not* using the 
> /i modifier.

Thanks, you've made me realize that /a wasn't even what I wanted in the
first place.  What I thought /a would do is force s/// to act byte by
byte -- or, in the terms of perlunitut, force the target string to be
treated as a binary string.  That might be clearer with a concrete example:

$ perl -e '$_ = "\xE2\x88\x85"; s/([^\x20-\x7e])/sprintf("\\x%02x", 
ord($1))/eg; print "$_\n";'
\xe2\x88\x85
$ perl -e '$_ = "\N{EMPTY SET}"; s/([^\x20-\x7e])/sprintf("\\x%02x", 
ord($1))/eg; print "$_\n";'
\x2205

What change do I need to make to the second one-liner to make it also
print \xe2\x88\x85?  How do I express that in a way that is backward
compatible all the way to 5.6.0?  And finally, how do I ensure that
there is absolutely nothing I can put in the initial assignment to
$_ that will cause the rest of the one-liner to crash?  For example
over in the Python universe it's very easy to get Unicode conversion
to crash:

$ python3 -c 'print("\uDC00".encode("utf-8"))'
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc00' in position 
0: surrogates not allowed

Given that having non-ASCII here in the first place is pretty unlikely,
I am going to go ahead and land the patch with your suggested changes,
but I'd still appreciate any further advice you have.

zw

[sr #110872] m4_warn differs in various ways from its documentation

[Zack Weinberg]

Update of sr#110872 (group autoconf):

  Status:   Confirmed => In Progress

___

Follow-up Comment #1:

Candidate patch:
. 
Needs a portability fix and feedback from Automake maintainers before landing.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

[Zack Weinberg]

In autoconf 2.69, the manual said that you could use “all” and the
empty string as the first argument to m4_warn.  As far as I can tell
this was never actually true, and the manual was corrected in 2.70,
but we still got a bug report from someone who tried it and got a
confusing internal error from the guts of autom4te.

This patch makes us issue a nice helpful user error, instead of a
confusing internal error, when Autom4te::Channels::msg is called with
a bogus channel argument.  If the bogus channel is “all” or the empty
string, that error is demoted to a -Wobsolete warning.  If it is one
of the other special tokens recognized by -W, we customize the error
message, since someone might’ve thought that “none” being acceptable
to -W meant it was also acceptable to m4_warn.  The --help output for
autoconf, autoheader, autom4te, and autoreconf is also adjusted to
clarify that not all of the tokens recognized by -W count as
warning categories.

(Oddly enough, m4_warn([error], […]) actually issues an error, because
the argument to m4_warn is passed straight through as the channel
argument to Autom4te::Channels::msg.  Since neither m4_errprintn(…)
nor m4_fatal(…)  does quite the same thing as m4_warn([error], […]),
I propose to leave that alone for now and promote it to a proper,
documented feature (probably spelled m4_error(…)) post-2.72.)

Since this touches code shared between Autoconf and Automake, I’m not
checking it in yet and I’m requesting comments from both sides of the
fence.  Also, there’s a perl 2.14ism in one place (s///a) which I need
to figure out how to make 2.6-compatible before it can land.

Addresses .

 * lib/Autom4te/Channels.pm (msg): If the channel argument is invalid,
   don’t crash; report the mistake and use the ‘syntax’ channel.
   (report_bad_channel): New function for reporting invalid channels.

 * lib/Autom4te/ChannelDefs.pm (usage): Clarify that the list of
   warning categories is exhaustive, and that “all”, “none”,
   “no-CATEGORY”, and “error” are not warning categories.

 * bin/autoconf.in, bin/autoheader.in, bin/autom4te.in,
   bin/autoreconf.in: Tweak --help text.

 * tests/m4sugar.at (m4@@_warn (bad categories)): New test.
---
 bin/autoconf.in |  1 +
 bin/autoheader.in   |  1 +
 bin/autom4te.in |  1 +
 bin/autoreconf.in   | 10 +++---
 lib/Autom4te/ChannelDefs.pm | 10 +++---
 lib/Autom4te/Channels.pm| 48 +++-
 tests/m4sugar.at| 63 +
 7 files changed, 123 insertions(+), 11 deletions(-)

diff --git a/bin/autoconf.in b/bin/autoconf.in
index 060a9a04..5f4a2e5c 100644
--- a/bin/autoconf.in
+++ b/bin/autoconf.in
@@ -64,6 +64,7 @@ Operation modes:
   -f, --force   consider all files obsolete
   -o, --output=FILE save output in FILE (stdout is the default)
   -W, --warnings=CATEGORY   report the warnings falling in CATEGORY
+(comma-separated list accepted)
 
 " . Autom4te::ChannelDefs::usage . "
 
diff --git a/bin/autoheader.in b/bin/autoheader.in
index 4afa5f13..f5af0df2 100644
--- a/bin/autoheader.in
+++ b/bin/autoheader.in
@@ -74,6 +74,7 @@ or else 'configure.in'.
   -d, --debug  don\'t remove temporary files
   -f, --force  consider all files obsolete
   -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
+   (comma-separated list accepted)
 
 " . Autom4te::ChannelDefs::usage . "
 
diff --git a/bin/autom4te.in b/bin/autom4te.in
index 8957a6c9..2e4e7d52 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
@@ -160,6 +160,7 @@ Operation modes:
   -o, --output=FILEsave output in FILE (defaults to '-', stdout)
   -f, --force  don't rely on cached values
   -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
+   (comma-separated list accepted)
   -l, --language=LANG  specify the set of M4 macros to use
   -C, --cache=DIRECTORYpreserve results for future runs in DIRECTORY
   --no-cache   disable the cache
diff --git a/bin/autoreconf.in b/bin/autoreconf.in
index c6077efe..285d0f49 100644
--- a/bin/autoreconf.in
+++ b/bin/autoreconf.in
@@ -84,20 +84,18 @@ Operation modes:
   --no-recursive   don't rebuild sub-packages
   -s, --symlinkwith -i, install symbolic links instead of copies
   -m, --make   when applicable, re-run ./configure && make
-  -W, --warnings=CATEGORY  report the warnings falling in CATEGORY [syntax]
+  -W, --warnings=CATEGORY  report the warnings falling in CATEGORY
+   (comma-separated list accepted)
 
 " . Autom4te::ChannelDefs::usage . "
 
-The environment variable 'WARNINGS' is honored.  Some subtools might
-support other warning types, using 'all' is encouraged.
-
 Library directories:
   -B, --prepend-include=DIR  prepend directory DIR to search path
   -I, --include=DIR   

[sr #110554] AC_CONFIG_HEADERS doesn't work properly for files with Windows line-endings

[Zack Weinberg]

Update of sr#110554 (group autoconf):

  Status:   Confirmed => Ready For Test 

___

Follow-up Comment #1:

Should be fixed in
,
thanks for reporting.

Thanks also for providing a patch; it might have taken me hours to figure out
what to change otherwise.  I made a somewhat different change, though, because
your code could produce a config.h with _inconsistent_ line endings, and also
because old non-GNU implementations of awk probably don't support using a
regexp as the third argument to 'split'.  (I'm not 100% sure about this; the
gawk manual is usually very good about pointing out portability issues but in
this case it's ambiguous.  For code this fundamental I think it's best to play
safe.)

I don't have access to a development environment on a machine that uses CRLF
line endings.  I would appreciate it if you could test autoconf trunk in the
environment where you originally encountered the problem.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[committed PATCH] config.status: handle CRLF line endings in AC_CONFIG_HEADERS input

[Zack Weinberg]

On systems that normally use Unix line endings, if config.h.in has
somehow been generated with DOS line endings, then awk will treat
each CR character as part of the line.  This breaks the regular
expressions used to edit config.h.in into config.h

To fix, manually strip trailing CRs from each “input record” before
any other processing.  For consistency I also made this change to the
code dealing with AC_CONFIG_FILES substitutions.  On systems that use
DOS line endings, both changes should be no-ops.

Reported by David Allsopp in .
He offered a different patch, which also worked on my machine, but it
used a regular expression as the third argument to ‘split’, which
might not be portable across awk implementations (the gawk manual is
unclear).  Also, it could produce a config.h with _inconsistent_ line
endings.

* lib/autoconf/status.m4 (_AC_OUTPUT_HEADERS_PREPARE): In the awk
  script, strip a trailing CR from each record as the first action.
  (_AC_OUTPUT_FILES_PREPARE): Likewise.
* tests/torture.at (CRLF line endings in .in files): New test.

Co-authored-by: David Allsopp 
---
 lib/autoconf/status.m4 |  2 ++
 tests/torture.at   | 29 +
 2 files changed, 31 insertions(+)

diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4
index 2bfaf32b..e5eb67bf 100644
--- a/lib/autoconf/status.m4
+++ b/lib/autoconf/status.m4
@@ -503,6 +503,7 @@ cat >>"\$ac_tmp/subs1.awk" <<_ACAWK &&
 }
 {
   line = $ 0
+  sub(/\r\$/, "", line)
   nfields = split(line, field, "@")
   substed = 0
   len = length(field[1])
@@ -824,6 +825,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
   for (key in D) D_is_set[key] = 1
   FS = ""
 }
+{ sub(/\r\$/, "", \$ 0) }
 /^[\t ]*#[\t ]*(define|undef)[\t ]+$ac_word_re([\t (]|\$)/ {
   line = \$ 0
   split(line, arg, " ")
diff --git a/tests/torture.at b/tests/torture.at
index ba52e12d..4e81d0dc 100644
--- a/tests/torture.at
+++ b/tests/torture.at
@@ -1093,6 +1093,35 @@ AT_CHECK_DEFINES([[#define foo one
 
 AT_CLEANUP
 
+## --- ##
+## CRLF line endings.  ##
+## --- ##
+
+AT_SETUP([CRLF line endings in .in files])
+
+AT_CONFIGURE_AC([[
+AC_DEFINE([MACRO], [1], [Define MACRO as 1 always.])
+AC_SUBST([VARIABLE], [value])
+AC_CONFIG_FILES([config.out:config.oin])
+]])
+
+# Shell `printf` should understand \r.
+AT_CHECK([printf '%s\r\n' \
+  '/* Define MACRO as 1 always. */' \
+  '#undef MACRO' \
+  > config.hin])
+AT_CHECK([printf '%s\r\n' \
+  'VARIABLE=@VARIABLE@' \
+  > config.oin])
+
+AT_SKIP_IF([grep '\\r' config.hin > /dev/null])
+
+AT_CHECK_AUTOCONF
+AT_CHECK_CONFIGURE
+AT_CHECK([grep '#define MACRO 1' config.h > /dev/null])
+AT_CHECK([grep 'VARIABLE=value' config.out > /dev/null])
+
+AT_CLEANUP
 
 ##  ##
 ## AC_SUBST: variable name validation.  ##
-- 
2.41.0

[sr #110746] GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

[Zack Weinberg]

Update of sr#110746 (group autoconf):

  Status:   Need Info => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I'm going to go ahead and close this as believed to be fixed.  If you
encounter further problems with F77 + mpicxx + autoconf 2.72 (which will be
released in about a week), please file new bug reports.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Zack Weinberg]

On Wed, Dec 13, 2023, at 9:29 AM, Florian Weimer wrote:
>   configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
>   

Trunk autoconf produces a configure script for that library which reports
"checking for getpagesize...yes" and "checking for working mmap... yes",
without the changes in that pull request, with GCC 13 and glibc 2.37,
even if CC is set to

gcc -std=c11 -Werror=implicit-function-declaration -Werror=implicit-int
-Werror=int-conversion -Werror=incompatible-pointer-types

"make check" runs to completion, with no test failures reported.

On the same system, this test program fails to compile with
those options:

#define _XOPEN_SOURCE 600
#include 
int main(void)
{ return getpagesize(); }

complaining about an implicit declaration of getpagesize.

... There may still be a problem, though: after the above tests,
htslib's config.h has "#define HAVE_GETPAGESIZE 1" in it, because
AC_FUNC_MMAP provided its own declaration of getpagesize.  There
may be programs that trust HAVE_GETPAGESIZE to mean unistd.h declares
getpagesize.

> I can't test this with htslib unfortunately because I'm not able to
> build autoconf from sources for some reason.

What errors are you getting?

zw

[sr #110971] busybox mkdir is misdetected

[Zack Weinberg]

Update of sr#110971 (group autoconf):

  Status:   Confirmed => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #7:

Paul's patch verified to work and committed as
.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[PATCH] AC_PROG_MKDIR_P: Fix detection of busybox mkdir.

[Zack Weinberg]

From: Paul Eggert 

Some versions of BusyBox mkdir respond to ‘mkdir --version’ by
printing “mkdir: unrecognized option: --version” to stderr, and then
the version message we’re looking for, also to stderr.  Adjust the
pattern matching in AC_PROG_MKDIR_P to account for this.

Problem reported by Valery Ushakov.
Resolves .

* lib/autoconf/programs.m4 (AC_PROG_MKDIR_P): Fix detection of busybox mkdir.
---
 lib/autoconf/programs.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
   AS_EXECUTABLE_P(["$as_dir$ac_prog$ac_exec_ext"]) || continue
   case `"$as_dir$ac_prog$ac_exec_ext" --version 2>&1` in #(
 'mkdir ('*'coreutils) '* | \
-'BusyBox '* | \
+*'BusyBox '* | \
 'mkdir (fileutils) '4.1*)
   ac_cv_path_mkdir=$as_dir$ac_prog$ac_exec_ext
   break 3;;
-- 
2.41.0

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Zack Weinberg]

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 find versions with generic issues.

Good to hear.  I'd be testing these things myself but I've gotten so
confused about which changes are actually in which released versions of
which compilers that I wouldn't have any confidence in anything I did.

> Some concern has been expressed that the AC_FUNC_MMAP test fails
> incorrectly if getpagesize is detected, but does not have a
> prototype in .  One way this can happen is if a project
> does not use AC_USE_SYSTEM_EXTENSIONS, but says (with glibc)
> _XOPEN_SOURCE directly, but not _DEFAULT_SOURCE.  Reportedly, it
> also happens on Darwin.  I think the autoconf position is that these
> projects should use AC_USE_SYSTEM_EXTENSIONS instead, so no attempt
> has been made to fix it.

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 problem and any remaining
issues you're aware of are useful to me)?

zw

[sr #110713] Use __STDC__VERSION as first test for C99 compatibility (patch attached)

[Zack Weinberg]

Update of sr#110713 (group autoconf):

  Status:   Confirmed => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Committed now with a slight revision:
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=ba719bedba517b501473b3d86af5202f379fced8


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[PATCH] [committed] Consistently use block comments at beginning of C99 and C11 tests

[Zack Weinberg]

From: Detlef Riekenberg 

Purely cosmetic improvement to the C standard version tests: Use /* */
comments above all three checks of __STDC__ and/or __STDC_VERSION__,
and make “// See if C++-style comments work” the very first // comment.

Resolves issue #110713.

* c.m4 (_AC_C_C99_TEST_GLOBALS, _AC_C_C11_TEST_GLOBALS):
  Improve stylistic consistency with _AC_C_C89_TEST_GLOBALS.
  Move explicit test of C++-style comments earlier.
---
 lib/autoconf/c.m4 | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 77ff1af8..6cdef6fa 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -1193,11 +1193,13 @@ AC_DEFUN([_AC_C_C99_TEST_GLOBALS],
 [m4_divert_text([INIT_PREPARE],
 [[# Test code for whether the C compiler supports C99 (global declarations)
 ac_c_conftest_c99_globals='
-// Does the compiler advertise C99 conformance?
+/* Does the compiler advertise C99 conformance? */
 #if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L
 # error "Compiler does not advertise C99 conformance"
 #endif
 
+// See if C++-style comments work.
+
 #include 
 extern int puts (const char *);
 extern int printf (const char *, ...);
@@ -1253,7 +1255,6 @@ typedef const char *ccp;
 static inline int
 test_restrict (ccp restrict text)
 {
-  // See if C++-style comments work.
   // Iterate through items via the restricted pointer.
   // Also check for declarations in for loops.
   for (unsigned int i = 0; *(text+i) != '\''\0'\''; ++i)
@@ -1348,7 +1349,7 @@ AC_DEFUN([_AC_C_C11_TEST_GLOBALS],
 [m4_divert_text([INIT_PREPARE],
 [[# Test code for whether the C compiler supports C11 (global declarations)
 ac_c_conftest_c11_globals='
-// Does the compiler advertise C11 conformance?
+/* Does the compiler advertise C11 conformance? */
 #if !defined __STDC_VERSION__ || __STDC_VERSION__ < 201112L
 # error "Compiler does not advertise C11 conformance"
 #endif
-- 
2.41.0

[PATCH] [committed] autom4te: Don’t crash if Data::Dumper::Sortkeys is unavailable.

[Zack Weinberg]

Commit c2ab755698db245898a4cc89149eb5df256e4bd0 added an unconditional
use of Data::Dumper’s Sortkeys method, which was added in version
2.12_01 of that module.  In terms of Perl versions, it is available in
5.8.x and later, and in 5.6.2, but not in 5.6.1 or earlier. At the
time, our minimum Perl version was 5.10, but we lowered it to 5.6.0
again in 05e295b60cfdf378b7ed8c1f8563a5644d5d4689.  It seems that
commit was not actually tested with 5.6.1 or earlier.

As we are only using Sortkeys to facilitate manual comparison of
autom4te.cache/requests files, we can just ignore the method lookup
failure with 5.6.[01] and everything will work fine without it.

Tested on x86_64-unknown-netbsd9.3 with perl 5.6.1.
Resolves https://savannah.gnu.org/support/?110561.

* lib/Autom4te/C4che.pm (marshall): Ignore method lookup failure for
  Data::Dumper::Sortkeys with very old perl.
* lib/Autom4te/Request.pm (marshall): Likewise.
---
 lib/Autom4te/C4che.pm   | 11 +++
 lib/Autom4te/Request.pm | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/lib/Autom4te/C4che.pm b/lib/Autom4te/C4che.pm
index 523f15bf..029138d1 100644
--- a/lib/Autom4te/C4che.pm
+++ b/lib/Autom4te/C4che.pm
@@ -155,13 +155,16 @@ Serialize all the current requests.
 sub marshall ($)
 {
   my ($caller) = @_;
-  my $res = '';
 
   my $marshall = Data::Dumper->new ([\@request], [qw (*request)]);
-  $marshall->Indent(2)->Terse(0)->Sortkeys(1);
-  $res = $marshall->Dump . "\n";
+  $marshall->Indent(2)->Terse(0);
 
-  return $res;
+  # The Sortkeys method was added in Data::Dumper 2.12_01, so it is
+  # available in 5.8.x and 5.6.2 but not in 5.6.1 or earlier.
+  # Ignore failure of method lookup.
+  eval { $marshall->Sortkeys(1); };
+
+  return $marshall->Dump . "\n";
 }
 
 
diff --git a/lib/Autom4te/Request.pm b/lib/Autom4te/Request.pm
index 53f9ad7a..f4ede8df 100644
--- a/lib/Autom4te/Request.pm
+++ b/lib/Autom4te/Request.pm
@@ -59,14 +59,17 @@ struct
 sub marshall($)
 {
   my ($caller) = @_;
-  my $res = '';
 
   # CALLER is an object: instance method.
   my $marshall = Data::Dumper->new ([$caller]);
-  $marshall->Indent(2)->Terse(0)->Sortkeys(1);
-  $res = $marshall->Dump . "\n";
+  $marshall->Indent(2)->Terse(0);
 
-  return $res;
+  # The Sortkeys method was added in Data::Dumper 2.12_01, so it is
+  # available in 5.8.x and 5.6.2 but not in 5.6.1 or earlier.
+  # Ignore failure of method lookup.
+  eval { $marshall->Sortkeys(1); };
+
+  return $marshall->Dump . "\n";
 }
 
 
-- 
2.41.0

[sr #110561] autoconf: store autom4te request keys in sorted order

[Zack Weinberg]

Update of sr#110561 (group autoconf):

  Status:   Confirmed => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Your patch was actually committed over a year ago,
.
 It's good that this bug was left open, though, because it did need adjustment
to work with very old perl, and I'm not sure I would have thought to test with
very old perl if I hadn't been looking at this bug.

The adjustment has now also been landed:
.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Zack Weinberg]

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=implicit-function-declaration
>
> 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

For clarity, both of these commits were already included in the 2.72d beta 
release:
.
If you are able, please test 2.72d with a compiler that has -Werror=implicit-int
and/or -Werror=implicit-function-declaration enabled by default, and report
your findings here as soon as possible.

I will consider any failure in autoconf's own testsuite, caused by
-Werror=implicit-int and/or -Werror=implicit-function-declaration,
to be a release blocker, unless it proves to be the fault of the system's
C library (e.g. some header file is _supposed_ to provide a prototype for
some function but it doesn't).  Regressions from the above two commits
will also be considered blockers, except if they boil down to "configure
scripts can't be used with a K compiler anymore", which is unavoidable.

> And then all we need... is for every project on earth to autoreconf.
> The real problem though is the thousands of existing configure.ac
> files with their own buggy compile/link tests that will silently fail.
>
> Here's a short TODO list: https://bugs.gentoo.org/870412

If there's anything we can do from our end to make that list easier to
grind through, please let us know.

zw

[sr #110318] autoreconf: support libtoolize being named glibtoolize

[Zack Weinberg]

Update of sr#110318 (group autoconf):

Priority: 7 - Release N (Desirable) => 3 - Release N+1

___

Follow-up Comment #6:

I looked into this a bit more, and it turns out I was wrong, it's not easy. 
autoreconf doesn't currently have the ability to try multiple names for any
tool, and adding that ability would be enough of a change that I think it had
best wait for 2.73.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110927] 30 tests fail building on macOS Venture 13.5.1 with Xcode 14.3.1

[Zack Weinberg]

Follow-up Comment #2, sr#110927 (group autoconf):

I tested current development trunk on macOS 12 with Xcode 14.2 (and GNU M4
1.4.19 from Homebrew; on macOS, Autoconf no longer supports use of the
system-provided M4 1.4.6) and observed no failures.  If I do not hear from
you, or someone else, to the effect that there are still failures on macOS 13
with current GNU M4, by the end of day on Sunday, Dec. 17, 2023, I will
presume that the problem is indeed fixed.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Bug triage for 2.72 complete; release freeze begins now

[Zack Weinberg]

Bug triage for 2.72 is complete.  All bug-autoconf subscribers, thank
you for your patience with the flood of low-information email.

I intend to make the final release of 2.72 no sooner than Monday, Dec.
18, but no *later* than Friday, Dec. 22.  Please consider the 'master'
branch to be in release freeze starting now: do not commit any patch to
'master' without first posting it to autoconf-patches and waiting for
me to OK it.

That said, please don't hesitate to tackle anything in the lists below,
even if it's not in the top two categories.

Testing is still extremely useful, especially testing on OSes other than
Linux, testing with development gcc and/or clang, and testing that goes
beyond autoconf's built-in test suite (e.g. pick your favorite project,
regenerate its configure script with trunk autoconf, and see if it still
probes everything correctly).

Here's the breakdown of all open bug reports, in decreasing order
of priority:

## Release blockers: 1 bug

* #110927: 30 tests fail building on macOS Venture 13.5.1 with Xcode 14.3.1

This is believed to have been fixed, but the fix needs testing.  I am
testing it right now on the GCC Compile Farm's macOS machine, but it's
running an older version of both the operating system (12.6) and of
Xcode (14.2).  If anyone is able to test with an OS that's a closer
match to the bug reporter's machine, please do.  (You just need to
check out the 'master' branch, bootstrap, and run the testsuite.
Note that you will need to install a current version of GNU M4 if
you haven't already.)

## Desirable for release: 7 bugs

* #110318: autoreconf: support libtoolize being named glibtoolize
* #110503: Autoconf 2.70 problem: gkt-doc/gtkdocize is now unconditionally 
required
* #110554: AC_CONFIG_HEADERS doesn't work properly for files with Windows 
line-endings
* #110561: autoconf: store autom4te request keys in sorted order
* #110713: Use __STDC__VERSION as first test for C99 compatibility (patch 
attached)
* #110872: m4_warn differs in various ways from its documentation
* #110971: busybox mkdir is misdetected

These all look easy, and many of them have patches from the reporter.
I plan to work through all of them over the next few days.

## Desirable for the release after this one: 13 bugs

* #110266 [Important]: Revert regression in Yacc support, and add Bison support
* #110286 [Important]: Make it possible to request a specific (non-latest) 
version of a language standard
* #109676 [Normal]: only one "checking whether the AC_LANG compiler works"
* #110347 [Normal]: Revise documentation of when configure enters 
cross-compilation mode.
* #110348 [Normal]: Simplify rules for when configure enters cross-compiling 
mode
* #108092 [Minor]: AC_PROG_GREP can select /usr/xpg4/bin/grep under Solaris 9 
but it doesn't support long lines
* #110416 [Minor]: documentation: ordering of basic macros?
* #110612 [Minor]: Re-exec of $as_myself chooses wrong configure script from 
PATH
* #110297 [Wish]: AC_PATH_PROG should accept a basename as an override
* #110382 [Wish]: Make confdefs.h idempotent vs compiler warnings
* #110394 [Wish]: Support optional use of the C++ compiler in AC_PROG_CXX (and 
similarly for other languages)
* #110431 [Wish]: AC_INIT should accept shell variable expansion in its 
arguments
* #110435 [Wish]: autoreconf: recognize when AM_ICONV is used without the rest 
of gettext

Currently I think all of these should be deferred to 2.73, but ideally
no *later* than 2.73.  If anyone thinks any of these should *not* be
deferred, please say so now.

## "To do eventually" and "blocked": 23 bugs

I don't expect any progress in the near future on any of these bugs
and I don't think we should commit to any time frame for them.
If you see something in these lists that you think should be addressed
in the near future, *and* you're prepared to tackle it yourself,
please speak up.

Whether a bug belongs in one or the other of these categories is
unfortunately somewhat fuzzy so I'm going to break them down
differently for this message.

* #110354: Parallel autotest produces mangled output on Solaris 10

I got dibs on this one. I plan to work on it early next year. But it
requires a complete overhaul of the parallel test driver and I don't
know how long it's going to take.

* #110300: configure >/dev/full does not fail promptly

May be easy, or may require an enormous amount of work.

* #110746: GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

Should be easy ... for someone who deeply understands Fortran and MPI.

* #110478: support for slibtool ans optional replacement for GNU libtool

This can't go anywhere until the slibtool project does a bunch more
work.  After that, the Automake project has to do a bunch of work.
We only get involved at the very end.

* #108879: Add m4_forbid_pattern for autoconf-archive macros
* #110212: Transform pkgdatadir using program-prefix and -suffix
* #110395: Makefile generated from Makefile.in unqoute *FLAGS variable twice