staging/stintel/tools/gnulib, branch master

tools: gnulib: remove stale gl_-prefixed macros from staging

2026-08-19T17:46:46Z

Commit c820f097e0 ("tools: gnulib: install .m4 file with gl_ prefix") installed gnulib autoconf macros under gl_-prefixed file names. The scheme was later reverted in commit cda598a595, but the previously installed files were never removed from share/aclocal. As aclocal reads the whole directory, stale gl_*.m4 files can override the current unprefixed macros. This breaks elfutils builds on macOS after the gnulib stable-202507 update, resulting in empty #if expressions in the generated ctype.h. Remove the stale files in Host/Uninstall. Host/Install calls it first, so affected build trees are cleaned up automatically on the next gnulib reinstall. Signed-off-by: Josef Schlehofer Link: https://github.com/openwrt/openwrt/pull/24759 Signed-off-by: Robert Marko

tools: gnulib: fix build with latest glibc C23 changes

2026-07-30T17:40:44Z

Backport a patch that covers a build problem with latest glibc being used as the host standard C library during tools build. The C23 standard changes some functions that used to drop qualifiers like "const" or "volatile" and are now forced to preserve them in the return type based on the input type at all times. Developers of glibc have responded by making these functions into macros after they are declared with prototypes. This is not compatible with the way gnulib is written, so when the functions are redeclared in gnulib, the preprocessor expands the _function name_ itself as if it is a macro name, but not fully, which results in unusual looking build errors, e.g. the failed processing of keywords that were never written and have no business being in a prototype, or, as a keyword that is expected to be there and nearly guarenteed to work but mysteriously is not working, displayed as: "error: expected identifier or '(' before _____". The backport patch introduces and implements a new macro in order to prevent function names from being interpreted as macros, by wrapping it in parentheses for C, or simply placing it back for C++ in the first stage of macro expansion which satisfies the goal of no further expansion taking place during preprocessing. Add an additional patch for the functions declared in the fts header, as this bug also applies to them, however, this was overlooked by upstream gnulib, likely because the bug is not presenting as an error. Yet another patch corrects the order between specifiers and attributes in GCC syntax for header lib/fts.in.h which can be blamed on an upstream commit. Specifically, the throw() or noexcept() keywords must be before attributes at the end of a declaration. There are two headers, lib/cdefs.h and lib/getopt-ext.h that already demonstrate the correct order which is very strictly necessary in the latest version of GCC when compiling C++ code, and acceptable for C code, as the "__THROW" macro is simply another attribute in that case. Added backport patch: - 400-c23-qualifier-generic.patch Added pending patch: - 410-unmacro-fts-functions.patch - 450-attribute-specifier-order.patch Ref: 80e5de158316 ("fts: Improve GCC 11 allocation-deallocation checking.") # gnulib.git Reported-by: Aditya Nugraha Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24247 Signed-off-by: Robert Marko

tools: gnulib: update to branch stable-202507

2026-07-30T17:40:44Z

Move to the July 2026 update of the last 2025 stable branch. This branch includes many new modules and changes to modules that were previously patched, so many patches are dropped. Newer gnulib now also has a proper fts header in the form of a template file for variable definitions that are set during configuration, however, it still ends up named with an underscore, so the patch 120-unmangle-darwin-fts-h.patch in order to resolve differences between macOS and standard fts headers is rewritten to patch the new header include guard and the fts module file in order to name it without an underscore. Manually Adjusted Patch: - 120-unmangle-darwin-fts-h.patch All other patches are automatically refreshed. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24247 Signed-off-by: Robert Marko

tools: gnulib: rename macro file for cond module

2026-07-12T09:26:53Z

It was reported that cond.m4 in gnulib is a name clash with cond.m4 provided by Automake, where they are for completely different purposes instead of different versions of the same macros. A quick survey of all the macro files in the build directory reveals that this is the only case where the gnulib copy is signficantly smaller than the rest of the copies of the same macro name distributed in the rest of the build system, and the only one that name clashes with Automake. A previous fix added a prefix to all macros from gnulib, but the name must match how it is described in the respective modules files as a functional requirement to build certain tools for certain (older) hosts, so patch the problematic module instead of renaming all macros from gnulib. Ref: c820f097e0be ("tools: gnulib: install .m4 file with gl_ prefix") Ref: 78a8cfb57772 ("tools: gnulib: fix broken install of .m4 files") Reported-by: Christian Marangi Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24136 Signed-off-by: Robert Marko

Revert "tools: gnulib: install .m4 file with gl_ prefix"

2026-07-12T09:26:53Z

A more proper fix follows this revert. This reverts commit c820f097e0bede3ec09c62ca9608d915da21e62d. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24136 Signed-off-by: Robert Marko

Revert "tools: gnulib: fix broken install of .m4 files"

2026-07-12T09:26:52Z

A more proper fix follows these reverts. This reverts commit 78a8cfb57772138ff5b925b9d69928e5878931bf. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/24136 Signed-off-by: Robert Marko

tools: gnulib: fix broken install of .m4 files

2025-12-04T15:35:40Z

Makefile foreach works only on parsing the Makefile and in this specific case only works if the package is already extracted and file actually exist. On scenario where the package still has to be built, foreach doesn't find any file causing Host/Install to not install any .m4 file. To handle this, use a shell for loop that scan files in the Host/install. Fixes: c820f097e0be ("tools: gnulib: install .m4 file with gl_ prefix") Signed-off-by: Christian Marangi

tools: gnulib: install .m4 file with gl_ prefix

2025-12-03T17:44:42Z

It was found that there is currently a conflict for the cond.m4 that is also shipped by automake, making the gnulib one having priority causing problem with finding AM_CONDITIONAL macro. To handle this, install gnulib .m4 file with a gl_ prefix to the filename. This make sure gnulib .m4 file won't have name conflict with automake .m4 default files permitting correct autoreconf run of any affected package by this. Signed-off-by: Christian Marangi

tools: gnulib: always use std-gnu23 module

2025-08-11T20:28:41Z

The new "std-gnu23" module has the stated goal of: "...to update the c99 module to depend on std-gnu23 instead of on std-gnu11, and to make std-gnu11 obsolete." in upstream commit 8990abb50 ("std-gnu23: new module"). However, for now, it's design is optional, so that definitions of the latest standard module overrides the former. At some point, upstream gnulib will replace the dependency instead of add it alongside the older one. Because all macros are copied to the aclocal directory, for complex projects, not including the module may cause the macros to apply only to some subdirectories rather than all of them and top-level together. For projects that import source from local gnulib, always include the std-gnu23.m4 macros for consistency. Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/19748 Signed-off-by: Robert Marko

tools: gnulib: do not cache C standard option test results

2025-08-02T22:41:05Z

After eliminating the possibility of automake having a bug by testing a revert to the recent updates to automake, the problems regarding autoreconf with some packages was bisected to the gnulib update instead, through aclocal macros. With the new module, std-gnu23, some packages are failing build due to both the host compiler and cross compiler being tested for availability of C23 standard features with the configure script. The results of one is being cached and used for the other, while the two compilers are different versions and may or may not both support C23 options and would otherwise have conflicting results. A similar patch may have to be done for the next release of Autoconf if upstream GNU does not accept this solution. Reported-by: Georgi Valkov Signed-off-by: Michael Pratt Link: https://github.com/openwrt/openwrt/pull/19627 Signed-off-by: Nick Hainke