Re: Bug Resilience Program of German Sovereign Tech Fund

Hi Paul, the Sovereign Tech Fund also offers funding (called General Investments). The application describes what should be achieved and how much it should cost. But that is another program and the application is more difficult. I think we should apply for the Bug Resilience Program with

Re: Bug Resilience Program of German Sovereign Tech Fund

ng and fixing known issues, supporting projects > with additional coding capacity, re-engineering/re-coding/refactoring > or removing code, improving documentation and contributor > onboarding material, as well as help implementing best practices > or standards for maintainability S

Re: Bug Resilience Program of German Sovereign Tech Fund

ns, such > as triaging, sorting and fixing known issues, supporting projects > with additional coding capacity, re-engineering/re-coding/refactoring > or removing code, improving documentation and contributor > onboarding material, as well as help implementing best practices > or

Re: Bug Resilience Program of German Sovereign Tech Fund

Hi Zack, you mean we should apply for a combined autoconf and automake proposal? Sure, makes sense to me. Bye Christoph Am 06.06.24 um 17:10 schrieb Zack Weinberg: 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

Re: Bug Resilience Program of German Sovereign Tech Fund

On 2024-06-06 08:10, Zack Weinberg wrote: 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: As near as I can

Re: Bug Resilience Program of German Sovereign Tech Fund

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

Re: Improve Autoconf MSVC support

On 2024-06-03 16:19, Antonin Décimo wrote: >> I guess you are not using Automake, because both of these problems >> should be solved automatically by Automake. Automake replaces $CC >> with invocations through a wrapper script that knows how to translate >> -l and -o options into MSVC equivalents

Re: Improve Autoconf MSVC support

Hi Nick, Thank you for your reply! > I guess you are not using Automake, because both of these problems > should be solved automatically by Automake. Automake replaces $CC > with invocations through a wrapper script that knows how to translate > -l and -o options into MSVC equivalents (such as

Re: Improve Autoconf MSVC support

Hi Antonin, On 2024-06-03 12:05, Antonin Décimo wrote: > Dear maintainers, > > I've listed three little problems I've had using MSVC and Autoconf. > They stem from MSVC not accepting the same parameters from the usual > unix tools. I wonder if these could be fixed. I'm happy to help with >

Re: Improve Autoconf MSVC support

Thanks for your helpful comments. Would you be up to writing and testing Autoconf patches to support MSVC better? I don't use MSVC and so would not be good for that. Thanks.

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

On Wed, May 29, 2024 at 1:34 PM Tom Tromey wrote: > > "Jason" == Jason Merrill writes: > > Jason> Thanks, though I don't think all that code needs to go; > Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that > Jason> relies on features from a particular standard. We

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

> "Jason" == Jason Merrill writes: Jason> Thanks, though I don't think all that code needs to go; Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that Jason> relies on features from a particular standard. We just don't want Jason> AC_PROG_CXX to invoke it. I didn't

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

On 5/28/24 11:27, Jason Merrill wrote: AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that relies on features from a particular standard. It's called "_AC_PROG_CXX_STDCXX_EDITION_TRY" with a leading underscore, which means it's private to Autoconf and apps shouldn't (and I

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

On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote: > -std=gnu23 support is still incomplete even in GCC 14. It doesn't involve ABI issues, however, unlike C++, so using the option with GCC 14 is comparatively safe. (It might run into a few aliasing bugs related to tag compatibility right now,

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

On Tue, May 28, 2024 at 12:49 PM Paul Eggert wrote: > > On 2024-05-28 08:02, Jakub Jelinek wrote: > > even for C GCC updates the default > > True, but C seems to be different, in that using a later-than-default > -std=whatever is more likely to help than hurt, because the C > standardization

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

On 2024-05-28 08:02, Jakub Jelinek wrote: even for C GCC updates the default True, but C seems to be different, in that using a later-than-default -std=whatever is more likely to help than hurt, because the C standardization folks are more careful about compatibility. That's what I've been

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

On Tue, May 28, 2024 at 10:36 AM Paul Eggert wrote: > > On 2024-05-28 01:20, Jonathan Wakely wrote: > > I am not aware of any distro ever changing the default -std setting for g++ > > or clang++. Are you attempting to solve a non-problem, but introducing new > > ones? > > If it's a non-problem

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

On Tue, May 28, 2024 at 07:35:43AM -0700, Paul Eggert wrote: > On 2024-05-28 01:20, Jonathan Wakely wrote: > > I am not aware of any distro ever changing the default -std setting for g++ > > or clang++. Are you attempting to solve a non-problem, but introducing new > > ones? > > If it's a

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

On 2024-05-28 01:20, Jonathan Wakely wrote: I am not aware of any distro ever changing the default -std setting for g++ or clang++. Are you attempting to solve a non-problem, but introducing new ones? If it's a non-problem for C++, why does Autoconf upgrade to C++11 when the default is C++98?

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

On Tue, 28 May 2024, 02:51 Paul Eggert, wrote: > On 2024-05-27 12:18, Jakub Jelinek wrote: > > Maybe respect the carefully chosen compiler default (unless explicitly > > overridden in configure.ac)? > > Autoconf gave up on that idea long ago, as we had bad experiences with > compiler defaults

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

On Tue, 28 May 2024, 07:24 Florian Weimer via Gcc, wrote: > * Paul Eggert: > > > On 2024-05-27 03:35, Florian Weimer wrote: > >> Does this turn on experimental language modes by default? That's > >> probably not what we want. > > > > What do C++ developers want these days? Autoconf should have

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

* Paul Eggert: > On 2024-05-27 03:35, Florian Weimer wrote: >> Does this turn on experimental language modes by default? That's >> probably not what we want. > > What do C++ developers want these days? Autoconf should have a > reasonable default, and C++11 is surely not a good default anymore.

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

On 2024-05-27 12:18, Jakub Jelinek wrote: Maybe respect the carefully chosen compiler default (unless explicitly overridden in configure.ac)? Autoconf gave up on that idea long ago, as we had bad experiences with compiler defaults being chosen for the convenience of distro maintainers rather

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

On Mon, May 27, 2024 at 12:04:40PM -0700, Paul Eggert wrote: > On 2024-05-27 03:35, Florian Weimer wrote: > > Does this turn on experimental language modes by default? That's > > probably not what we want. > > What do C++ developers want these days? Autoconf should have a reasonable > default,

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

On 2024-05-27 03:35, Florian Weimer wrote: Does this turn on experimental language modes by default? That's probably not what we want. What do C++ developers want these days? Autoconf should have a reasonable default, and C++11 is surely not a good default anymore. It would be easy to

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

* Paul Eggert: > diff --git a/NEWS b/NEWS > index 20dbc173..4ba8f3fe 100644 > --- a/NEWS > +++ b/NEWS > @@ -16,6 +16,10 @@ GNU Autoconf NEWS - User visible changes. >C11 and later. Programs can use AC_C_VARARRAYS and __STDC_NO_VLA__ >to use VLAs if available. > > +*** AC_PROG_CXX now

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: configure adds -std=gnu++11 to CXX variable

Thanks for the patch. I installed something like it (see first attached patch; sorry, I misspelled "C++11" as "C11" in the commit message). This underscores the fact that Autoconf really, really should test for later C++ standards, as documented. I installed the second attached patch to get

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

Hi Zack, On 5/3/24 00:54, Zack Weinberg wrote: 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

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

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

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

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 5/2/24 04:01, Florian Weimer wrote: * Alan Coopersmith: https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042 This change: #ifndef __cplusplus +#if __STDC_VERSION__ >= 199901L +#include +#else typedef enum { false = 0,

Re: C23 support in Autoconf

* Alan Coopersmith: > https://gitlab.freedesktop.org/xorg/driver/xf86-video-vbox/-/commit/b66441a27fa85e2a3b63f10a0a5a846344327042 This change: #ifndef __cplusplus +#if __STDC_VERSION__ >= 199901L +#include +#else typedef enum { false = 0, true } bool; +#endif # define

Re: C23 support in Autoconf

On 2024-05-01 05:33, Nick Bowler wrote: Just configure with CFLAGS=-std=c99 or whatever. I was thinking along the same line. We should keep things simple. Using CFLAGS is a documented way to specify the compiler flags, and ideally there would be no need for a new feature in this area.

Re: C23 support in Autoconf

On 2024-04-30 21:59, Jacob Bachmeyer wrote: > Paul Eggert wrote: >> While we're adding to our wishlist that should also be a >> configure-time option, not merely something in configure.ac. That >> way, one could test a tarball's portability without having to modify >> the source code. This is

Re: C23 support in Autoconf

Paul Eggert wrote: On 2024-04-30 12:03, Zack Weinberg wrote: Another reason to want this type of control is if you are deliberately trying to ensure that your code continues to compile with old compilers. While we're adding to our wishlist that should also be a configure-time option, not

Re: C23 support in Autoconf

I wasn't there when the magic was written, but I would have expected AC_PROG_CC_C89, AC_PROG_CC_C99 and possibly new AC_PROG_CC_Cx macros to select a version of the C standard. Apparently that wasn't their job and now they've been deprecated in 2.70.

Re: C23 support in Autoconf

On 4/30/24 12:16, Paul Eggert wrote: On 2024-04-30 12:03, Zack Weinberg wrote: Another reason to want this type of control is if you are deliberately trying to ensure that your code continues to compile with old compilers. While we're adding to our wishlist that should also be a

Re: C23 support in Autoconf

On 2024-04-30 12:03, Zack Weinberg wrote: Another reason to want this type of control is if you are deliberately trying to ensure that your code continues to compile with old compilers. While we're adding to our wishlist that should also be a configure-time option, not merely something in

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 recent one we know about.

Re: C23 support in Autoconf

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

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

Thanks for the suggestion; I installed the attached. Part of the idea is for the first line to be a complete summary.From 02f232c67156da2d353c986fd77d408db5084f79 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 30 Apr 2024 11:48:31 -0700 Subject: [PATCH] Improve VLA wording in NEWS Thanks

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: C23 support in Autoconf

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

Re: C23 support in Autoconf

On 4/30/24 10:51, Paul Eggert wrote: I installed the attached patch into Savannah master to get the ball rolling on Autoconf supporting C23. Most C23 compatibility gizmos are now done in Gnulib. However, Autoconf's AC_PROG_CC needs to be changed to tack --std=gnu23 onto $CC. Although this may

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

Antonin Décimo writes: > Le mar. 30 avr. 2024 à 15:01, Sam James a écrit : >> >> Paul Eggert writes: >> >> > On 2024-04-26 08:10, Zack Weinberg wrote: >> > >> >> I think what we should do here is fold AC_C_VARARRAYS into AC_PROG_CC. >> >> Take the test for VLAs completely out of

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

> +*** AC_PROG_CC no longer tests for VLAs, or whether __STDC__ is defined. > + This ports better to MSVC, which does not support variable length > + arrays and does not define __STDC__. Suggestion: ``` *** AC_PROG_CC no longer tests for variable length arrays (VLAs), or whether __STDC__

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

> I installed the attached patch, which is less ambitious but should > address the original problem report. It does address the problem report and it looks good to me, thanks a lot! It's also a bit less invasive than passing -std:c11 -Zc:__STDC__. The manual of AC_C_VARARRAYS could mention using

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

Le mar. 30 avr. 2024 à 15:01, Sam James a écrit : > > Paul Eggert writes: > > > On 2024-04-26 08:10, Zack Weinberg wrote: > > > >> 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

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

Paul Eggert writes: > On 2024-04-26 08:10, Zack Weinberg wrote: > >> 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,

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

On 2024-04-26 08:10, Zack Weinberg wrote: 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

Re: ac_cv_sys_largefile_opts undocumented?

On Sat, Apr 27, 2024 at 11:42:23PM +0200, Bruno Haible wrote: > dmitrii.pasechnik wrote: > > By the way, ac_cv_sys_largefile_opts isn't fun to use - as sometimes > > it's a plain text, and sometimes flags which should be added to CFLAGS. > > So one has to write things like > > > >

Re: ac_cv_sys_largefile_opts undocumented?

On 2024-04-27 15:39, dmitrii.pasech...@cs.ox.ac.uk wrote: It's for nauty, a well-known program to deal with graph isomorphisms etc. I've made a Gentoo patch herehttps://bugs.gentoo.org/921138 and I wanted to upstream it. Oh my, that is indeed in an undocumented/hacky part of autoconf, one

Re: ac_cv_sys_largefile_opts undocumented?

On Sat, Apr 27, 2024 at 02:26:24PM -0700, Paul Eggert wrote: > On 2024-04-27 14:06, dmitrii.pasech...@cs.ox.ac.uk wrote: > > Thus I got questions whether a patch for a build system I submitted for > > a project is OK, as it uses an undocumented variable (thus, perhaps, > > unstable). > > Although

Re: ac_cv_sys_largefile_opts undocumented?

dmitrii.pasechnik wrote: > By the way, ac_cv_sys_largefile_opts isn't fun to use - as sometimes > it's a plain text, and sometimes flags which should be added to CFLAGS. > So one has to write things like > > AS_CASE([$ac_cv_sys_largefile_opts], > ["none needed"], [], > ["support not

Re: ac_cv_sys_largefile_opts undocumented?

On 2024-04-27 14:06, dmitrii.pasech...@cs.ox.ac.uk wrote: Thus I got questions whether a patch for a build system I submitted for a project is OK, as it uses an undocumented variable (thus, perhaps, unstable). Although it's poorly designed and not documented and not stable, the patch may be

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

> > 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! Thanks for your reply and thorough comments. > (Can you check if there's maybe some way to make the UCRT declare > POSIX

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

Re: autoreconf --force seemingly does not forcibly update everything

Paul Eggert writes: > On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: >> Is bootstrap intended to be reliable from within a tarball? I thought >> the bootstrap script was not included in tarballs because it wasn't >> designed to be ran that way, and the way it is designed

Re: autoreconf --force seemingly does not forcibly update everything

Nick Bowler wrote: > Not including the scripts used to build configure in a source tarball > is a mistake, particularly for a GPL-licensed package. The configure > script itself is clearly object code, and the GPL defines corresponding > source to include any "scripts to control [its

Re: autoreconf --force seemingly does not forcibly update everything

On 2024-04-10 16:36, Simon Josefsson wrote: > Is bootstrap intended to be reliable from within a tarball? I thought > the bootstrap script was not included in tarballs because it wasn't > designed to be ran that way, and the way it is designed may not give > expected results. Has this changed,

Re: autoreconf --force seemingly does not forcibly update everything

On Wed, Apr 10, 2024 at 5:44 PM Paul Eggert wrote: > > On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: > > Is bootstrap intended to be reliable from within a tarball? I thought > > the bootstrap script was not included in tarballs because it wasn't > > designed to be ran that

Re: autoreconf --force seemingly does not forcibly update everything

On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: Is bootstrap intended to be reliable from within a tarball? I thought the bootstrap script was not included in tarballs because it wasn't designed to be ran that way, and the way it is designed may not give expected results.

Re: autoreconf --force seemingly does not forcibly update everything

Bruno Haible writes: > Bernhard Voelker wrote: >> > Last month, I spent 2 days on prerelease testing of coreutils. If, after >> > downloading the carefully prepared tarball from ftp.gnu.org, the first >> > thing a distro does is to throw away the *.m4 files and regenerate the >> > configure

Re: autoreconf --force seemingly does not forcibly update everything

On 4/10/24 4:22 PM, Bruno Haible wrote: Sure, if downstream applies a patch that modifies bootstrap.conf, they need to rerun 'bootstrap'. That goes without saying. I hope downstream then also runs "make check". Sure, full automated QA is in action on all supported platforms. Have a nice day,

Re: autoreconf --force seemingly does not forcibly update everything

On 4/1/24 11:54 PM, Bruno Haible wrote: > Last month, I spent 2 days on prerelease testing of coreutils. If, after > downloading the carefully prepared tarball from ftp.gnu.org, the first > thing a distro does is to throw away the *.m4 files and regenerate the > configure script with their own

Re: autoreconf --force seemingly does not forcibly update everything

Bernhard Voelker wrote: > > Last month, I spent 2 days on prerelease testing of coreutils. If, after > > downloading the carefully prepared tarball from ftp.gnu.org, the first > > thing a distro does is to throw away the *.m4 files and regenerate the > > configure script with their own one, >

Re: autoreconf --force seemingly does not forcibly update everything

On 2024-04-09 18:06, Sam James wrote: > Nick poses that a specific combination of tools is what is tested and > anything else invalidates it. But how does this work when building on > a system that was never tested on, or with different flags, or a > different toolchain? > > It's reasonable to say

Re: autoreconf --force seemingly does not forcibly update everything

Sam James replied to Bruno Haible who cited Nick Bowler: > >> If I distribute a release package, what I have tested is exactly what is > >> in that package. If you start replacing different versions of m4 macros, > >> or use some distribution-patched autoconf/automake/libtool or whatever, > >>

Re: autoreconf --force seemingly does not forcibly update everything

Bruno Haible writes: > Nick Bowler wrote: >> If I distribute a release package, what I have tested is exactly what is >> in that package. If you start replacing different versions of m4 macros, >> or use some distribution-patched autoconf/automake/libtool or whatever, >> then this you have

Re: [sr #111048] Add a syntax check to code snippets

Fabrice BAUZAC-STEHLY writes: > Follow-up Comment #3, sr #111048 (group autoconf): > > I agree, it's not so easy. > > On CMake side, I think they are considering adding an "escape hatch" that > would not go unnoticed either. > > For Autoconf, maybe we could add a separate macro (with a very

Re: Suggestion for improving an error message

On Sat, 6 Apr 2024 at 22:05, Paul Eggert wrote: > Thanks for the suggestion. Although I didn't go to the trouble of > writing code to generate the multiline diagnostic you suggested, it's > easy to change "possibly undefined macro" (which doesn't cover the > situation you mentioned) to the

Re: Suggestion for improving an error message

Thanks for the suggestion. Although I didn't go to the trouble of writing code to generate the multiline diagnostic you suggested, it's easy to change "possibly undefined macro" (which doesn't cover the situation you mentioned) to the slightly less confusing "undefined or overquoted macro".

Re: autoreconf --force seemingly does not forcibly update everything

Guillem Jover wrote: > > It may be unexpected to you, but it is very much intended. > > The only unexpected part (which I perhaps failed to convey) was that > it is being taken into account with --force. This is documented in https://www.gnu.org/software/automake/manual/html_node/Serials.html

Re: autoreconf --force seemingly does not forcibly update everything

are looking for even if we make '-f' pull in *.m4 files regardless of serial number. There will be other files that are not updated from the central system package. It was never intended as a re-bootstrapping tool. Nick Bowler writes: > On 2024-04-01 16:43, Guillem Jover wrote: &

Re: autoreconf --force seemingly does not forcibly update everything

Nick Bowler wrote: > If I distribute a release package, what I have tested is exactly what is > in that package. If you start replacing different versions of m4 macros, > or use some distribution-patched autoconf/automake/libtool or whatever, > then this you have invalidated any and all release

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

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

Re: autoreconf --force seemingly does not forcibly update everything

On 2024-04-01 16:43, Guillem Jover wrote: > But if as a downstream distribution I explicitly request everything > to be considered obsolete via --force, then I really do want to get > whatever is in the system instead of in the upstream package. If I distribute a release package, what I have

Re: autoreconf --force seemingly does not forcibly update everything

Hi! [ See also my other reply to Eric. ] On Mon, 2024-04-01 at 20:29:59 +0200, Bruno Haible wrote: > Guillem Jover wrote in > : > > > While analyzing the recent xz backdoor hook into the build system [A], > > > I noticed that

Re: autoreconf --force seemingly does not forcibly update everything

a linear history (everything is > monotonically increasing, no forks for the serial number to diverge > on). In light of this weekend's mess, Bruno may have more ideas about > how to prevent his files from being turned into backdoor delivery > mechanisms in the future. I think the

Re: autoreconf --force seemingly does not forcibly update everything

Jeffrey Walton wrote: > Please forgive my ignorance... If you bump the authentic version of > the m4 file to version 31, will the issue mostly clear itself? If we bump gnulib's build-to-host.m4 to 'serial 31', this will override the one from xz-5.6.x in *some* situations. In other situations, it

Re: autoreconf --force seemingly does not forcibly update everything

On Mon, Apr 1, 2024 at 2:31 PM Bruno Haible wrote: > > Thanks for the forward, Eric. > > Guillem Jover wrote in > : > > > Hi! > > > > > > While analyzing the recent xz backdoor hook into the build system [A], > > > I noticed

Re: autoreconf --force seemingly does not forcibly update everything

Thanks for the forward, Eric. Guillem Jover wrote in : > > Hi! > > > > While analyzing the recent xz backdoor hook into the build system [A], > > I noticed that one of the aspects why the hook worked was because it > > seems

Re: autoreconf --force seemingly does not forcibly update everything

Hi! On Mon, 2024-04-01 at 12:43:02 -0500, Eric Blake wrote: > Widening the audience to include bug-gnulib, which is the upstream > source of "# build-to-host.m4 serial 3" which was bypassed by the > malicious "# build-to-host.m4 serial 30". > > On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem

Re: autoreconf --force seemingly does not forcibly update everything

Widening the audience to include bug-gnulib, which is the upstream source of "# build-to-host.m4 serial 3" which was bypassed by the malicious "# build-to-host.m4 serial 30". On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote: > Hi! > > While analyzing the recent xz backdoor hook into

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

Hi Zack, On Tue, Mar 5, 2024 at 12:58 AM Zack Weinberg wrote: > 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 --

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 helpful. Oh,

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?

Jeffrey Walton wrote: On Sun, Feb 25, 2024 at 2:09 AM Jeffrey Walton wrote: The page does not list __builtin_offsetof in the list of documented builtins. But the page says "Unsupported built-ins will be tested with an empty

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

On 2024-02-25 02:28, Jeffrey Walton wrote: > On Sun, Feb 25, 2024 at 2:09 AM Jeffrey Walton wrote: >> The page >> does not list __builtin_offsetof in the list of documented builtins. >> But the page says "Unsupported built-ins

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

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

On Sun, 25 Feb 2024 at 07:29, Jeffrey Walton wrote: > > Cancel. We can't use AX_GCC_BUILTIN in production. Using > AX_GCC_BUILTIN produces broken configure's: That's weird it didn't work. I tried with this minimal file (autoconf 2.71) and it was fine: #

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

Jeffrey Walton wrote: > On Sun, Feb 25, 2024 at 2:09???AM Jeffrey Walton wrote: > > Is it safe to use ax_gcc_builtin to detect __builtin_offsetof? > Cancel. We can't use AX_GCC_BUILTIN in production. Using > AX_GCC_BUILTIN produces broken configure's: > ... > ./configure: line 15023: syntax

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: > > The page > does not list __builtin_offsetof in the list of documented builtins. > But the page says "Unsupported built-ins will be tested with an empty > parameter set and

Re: [GNU Autoconf 2.72] testsuite: 420 421 422 failed

On 2/12/24 8:58 AM, Valentin Lefebvre via Bug reports for autoconf wrote: > From the log, we can see "checking for gcc option to enable large file > support... -D_FILE_OFFSET_BITS=64". For my understanding, for a 32bits > architecture, Should it be "-D_LARGE_FILES=1" instead ? I think that

Re: [PATCH] Add quotes in AS_IF test for gid_t

Paul Eggert writes: > On 2/6/24 20:37, Nick Bowler wrote: >> On 2024-02-06 22:33, Sam James wrote: >>> Noticed when building Emacs: >>> ``` >>> * checking type of array argument to getgroups... ./configure: 42782: test: >>> =: unexpected operator >>> ``` > >> Oh look, I see this line in

Re: [PATCH] Add quotes in AS_IF test for gid_t

Nick Bowler writes: > On 2024-02-06 22:33, Sam James wrote: >> Noticed when building Emacs: >> ``` >> * checking type of array argument to getgroups... ./configure: 42782: test: >> =: unexpected operator >> ``` >> This turns out to be because of missing quotes in AS_IF for >> ac_cv_type_gid_t

Re: [PATCH] Add quotes in AS_IF test for gid_t

On 2/6/24 20:37, Nick Bowler wrote: On 2024-02-06 22:33, Sam James wrote: Noticed when building Emacs: ``` * checking type of array argument to getgroups... ./configure: 42782: test: =: unexpected operator ``` Oh look, I see this line in emacs-29.2/configure.ac:

Re: [PATCH] Add quotes in AS_IF test for gid_t

m, which Emacs are you talking about? > > The issue is still present on emacs git master as far as I can see. > > You have to be (re)generating the configure script with Autoconf 2.72. > The actual emacs 29.2 release bundle ships with a configure script > built wi

  1   2   3   4   5   6   7   8   9   10   >