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

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

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

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

y 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

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

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

Re: C23 support in Autoconf

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 rec

Re: C23 support in Autoconf

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

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

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

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

Update of sr #111044 (group autoconf): Priority: 5 - Unprioritized => 2 - Eventually Severity: 3 - Normal => 2 - Minor Status:None => Need Info

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

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

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

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 >

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

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

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

Update of sr#111016 (group autoconf): Open/Closed:Open => Closed ___ Reply to this item at: ___

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

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

Re: cannot make gcc report undeclared builtins

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

Unavailable due to hardware problems

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

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

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

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

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

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

autoconf-2.72 released [stable]

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

autoconf-2.72 released [stable]

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

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

Update of sr#110987 (group autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Turns out there is

Re: AT_MTIME_DELAY not working?

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 th

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

Update of sr#110989 (group autoconf): Priority: 5 - Unprioritized => 3 - Release N+1 ___ Reply to this item at: ___

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

: 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

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

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. Timi

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

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 pr

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

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 pr

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

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. >

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

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 writ

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

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

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

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

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

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/trun

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

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

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

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) ...

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

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

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

: 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 co

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

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

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

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

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

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:

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

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:

Re: autoconf-2.72e released [release candidate]

On Wed, Dec 20, 2023, at 7:41 PM, Alan Coopersmith wrote: > On 12/20/23 08:16, Zack Weinberg wrote: >> autoconf-2.72e is now available. This is a *release candidate* >> for autoconf 2.72 final. Please test it as thoroughly as possible. >> Testing in Windows- and Darwin-bas

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

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) &

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

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:

autoconf-2.72e released [release candidate]

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

autoconf-2.72e released [release candidate]

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

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

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,

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

ing 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, basi

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

Update of sr#110985 (group autoconf): Priority: 5 - Unprioritized => 2 - Eventually ___ Reply to this item at: ___

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

ing 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

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

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,

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

Follow-up Comment #4, sr#110983 (group autoconf): @Paul Eggert: Not today, hopefully tomorrow. ___ Reply to this item at: ___ Message sent via

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

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:

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

Update of sr#110983 (group autoconf): Priority: 5 - Unprioritized => 3 - Release N+1 Severity: 3 - Normal => 4 - Important Operating System: Solaris => None

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

olaris ___ 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 A

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

Update of sr#110982 (group autoconf): Priority: 5 - Unprioritized => 3 - Release N+1 ___ Reply to this item at: ___

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

: 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, i

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

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

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

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

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

Update of sr#110927 (group autoconf): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Reply to this item at:

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

Update of sr#110872 (group autoconf): Status: In Progress => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Revised, committed

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

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

Re: AC_FUNC_MMAP not testing what the comments say

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

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

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

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

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])/"\

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

Update of sr#110872 (group autoconf): Status: Confirmed => In Progress ___ Follow-up Comment #1: Candidate patch: .

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

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

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

Update of sr#110554 (group autoconf): Status: Confirmed => Ready For Test ___ Follow-up Comment #1: Should be fixed in

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

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

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

Update of sr#110746 (group autoconf): Status: Need Info => Done Open/Closed:Open => Closed ___ Follow-up Comment #3: I'm going to go

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

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

[sr #110971] busybox mkdir is misdetected

Update of sr#110971 (group autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #7: Paul's patch

[PATCH] AC_PROG_MKDIR_P: Fix detection of busybox mkdir.

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

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

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

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

Update of sr#110713 (group autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #4: Committed now with a

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

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,

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

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

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

Update of sr#110561 (group autoconf): Status: Confirmed => Done Open/Closed:Open => Closed ___ Follow-up Comment #2: Your patch was

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

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 > >

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

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

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

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

Bug triage for 2.72 complete; release freeze begins now

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

Bug triage for 2.72 complete; release freeze begins now

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

[sr #110416] documentation: ordering of basic macros?

Update of sr#110416 (group autoconf): Priority: 2 - Eventually => 3 - Release N+1 ___ Reply to this item at: ___

[sr #110886] autoupdate produces broken configure.ac

Update of sr#110886 (group autoconf): Priority: 2 - Eventually => 1 - Blocked ___ Reply to this item at: ___

[sr #110537] AC_SEARCH_LIBS does not honor --with-sysroot=

Update of sr#110537 (group autoconf): Priority: 2 - Eventually => 1 - Blocked ___ Reply to this item at: ___

[sr #110382] Make confdefs.h idempotent vs compiler warnings

Update of sr#110382 (group autoconf): Summary: Make confdefs.h idempotent => Make confdefs.h idempotent vs compiler warnings ___ Reply to this item at:

[sr #110382] Make confdefs.h idempotent

Update of sr#110382 (group autoconf): Summary: In autoconf-2.69d AC_LANG_SOURCE implicitly includes '#include "confdefs.h"' => Make confdefs.h idempotent ___ Reply to this item at:

[sr #110435] autoreconf: recognize when AM_ICONV is used without the rest of gettext

Update of sr#110435 (group autoconf): Priority: 7 - Release N (Desirable) => 3 - Release N+1 Summary: autoreconf does not recognize AM_ICONV => autoreconf: recognize when AM_ICONV is used without the rest of gettext

[sr #110971] busybox mkdir is misdetected

Update of sr#110971 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

[sr #110886] autoupdate produces broken configure.ac

Update of sr#110886 (group autoconf): Status:None => Postponed ___ Reply to this item at: ___

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

Update of sr#110713 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

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

Update of sr#110872 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

Update of sr#110612 (group autoconf): Status:None => Need Info ___ Follow-up Comment #4: This is all helpful but I'm leaving this marked "need info" until someone has the time to do a

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

Update of sr#110561 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

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

Update of sr#110554 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

[sr #110537] AC_SEARCH_LIBS does not honor --with-sysroot=

Update of sr#110537 (group autoconf): Status:None => Need Info ___ Reply to this item at: ___

[sr #110435] autoreconf does not recognize AM_ICONV

Update of sr#110435 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

[sr #110418] Unable to specify build and target perl in cross builds

Update of sr#110418 (group autoconf): Priority: 7 - Release N (Desirable) => 1 - Blocked Status:None => Need Info ___ Reply to this item at:

[sr #110395] Makefile generated from Makefile.in unqoute *FLAGS variable twice while ./configure script only once

Update of sr#110395 (group autoconf): Status:None => Need Info ___ Reply to this item at: ___

[sr #110394] Support optional use of the C++ compiler in AC_PROG_CXX (and similarly for other languages)

Update of sr#110394 (group autoconf): Status:None => Confirmed ___ Reply to this item at: ___

  1   2   3   4   5   6   7   8   >