When building gnulib package, it success in F41 F42 EPEL9 and EPEL10, but it fails in F43 at an autoconf command. This is the error statement: configure:22731: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:22732: error: possibly undefined macro: AC_LIB_RPATH configure:22737: error: possibly undefined macro: AC_LIB_LINKFLAGS_BODY configure:22757: error: possibly undefined macro: AC_LIB_APPENDTOVAR Full log here: https://kojipkgs.fedoraproject.org//work/tasks/2686/134592686/build.log Successful builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=134596003 https://koji.fedoraproject.org/koji/taskinfo?taskID=134596551 https://koji.fedoraproject.org/koji/taskinfo?taskID=134596544 Reproducible: Always
The `AC_LIB_*` macros are provided by gnulib. Which makes things kind of weird, as if there was some kind of bootstrapping issue. For now I continue the investigation to find the root cause of the issue. @moceap Unfortunately, and even if the packages actually requires autoconf (it is executed during the build), the dependency isn't indicated in the spec file, so I couldn't catch this problem when I worked on the autoconf and m4 releases (assuming the problem comes from one or the other). Please fix that so that we can limit the risk in the future.
I've rebuilt gnulib in copr with latest autoconf (2.72-5)/m4 (1.4.20-1)/automake (1.18.1-1)/libtool (2.5.4-4), there is no issue so far in f42. Whatever happens in f43 that seems not related to any of these.
So the problem comes from latest gettext update. To fix this we probably need patches in Autoconf to deal with the update, and maybe update of gettext (to 0.25.1 from 0.25). I'm currently checking if the update of autoconf would be enough. For details: https://lists.gnu.org/archive/html/bug-gettext/2025-07/msg00002.html @matiwari I'd appreciate if you could run a [mass-prebuild](https://gitlab.com/fedora/packager-tools/mass-prebuild) on gettext before pushing a new release to uncover this kind of issues early.
Re-assigning to gettext as the failure is due to it. The failure happens since gettext 0.25, I tried to add the patches mentioned here [1] on autoconf and upgraded gettext to 0.25.1 in my tests, no success. So far, no solution I tired from upstream worked, but I may have missed something. [1] https://lists.gnu.org/archive/html/bug-gettext/2025-07/msg00026.html
I actually got an answer upstream, that I tested "rapidly": > The option '--avoid=havelib' is the problem. It tells gnulib-tool > to omit the lib-*.m4 files, but — as mentioned in the previous mail — > they are needed as dependencies of a couple of modules. > With older versions of gettext, the 'autopoint' invocation copied > these lib-*.m4 files, without protection against version mismatches. > The fix is thus to remove this option '--avoid=havelib'. On top of that: > You can considerably speed up your build jobs by adding python3 as a > build prerequisite. See > <https://lists.gnu.org/archive/html/info-gnu/2024-04/msg00003.html> With the following change autoconf and configure where executed successfully: diff --git a/gnulib.spec b/gnulib.spec index 5c5c73f..20f468c 100644 --- a/gnulib.spec +++ b/gnulib.spec @@ -77,6 +77,7 @@ BuildRequires: help2man BuildRequires: git BuildRequires: make BuildRequires: ncurses-devel +BuildRequires: python3 %description %common_desc @@ -93,7 +94,7 @@ do list="$(echo $list| sed "s:\b$item\b::g")" done #is necessary to avoid some modules to test prep pass -./gnulib-tool --create-testdir --with-tests --with-obsolete --avoid=alloca --avoid=lib-symbol-visibility --avoid=havelib --dir=build-tests $list +./gnulib-tool --create-testdir --with-tests --with-obsolete --avoid=alloca --avoid=lib-symbol-visibility --dir=build-tests $list rm lib/javaversion.class # MODULE #1 - git-merge-changelog
Thanks, Frédéric Unfortunately the gettext-0.25.1 release slipped under our radar... - wondering if it is better to slip it in just before the mass rebuild or not: I suppose it could well avert some build failures - anyway Manish is having a look at 0.25.1 now: I think we will probably defer 0.26 to F44 (even though the changes don't appear too intrusive).
(At least gettext-0.25.1 doesn't seem to fix this directly: see https://copr.fedorainfracloud.org/coprs/matiwari/gettext-0.25.1-test/build/9308474/ )
OK Fixed
FEDORA-EPEL-2026-3b29263ab5 (gnulib-0-55.20251223git.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-3b29263ab5
FEDORA-2026-83eb1cb148 (gnulib-0-55.20251223git.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-83eb1cb148
FEDORA-EPEL-2026-ab7a6aad65 (gnulib-0-55.20251223git.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-ab7a6aad65
FEDORA-EPEL-2026-ab7a6aad65 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-ab7a6aad65 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-83eb1cb148 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-83eb1cb148` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-83eb1cb148 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-3b29263ab5 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-3b29263ab5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-cf97e005ae has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-cf97e005ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-cf97e005ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-ab7a6aad65 (gnulib-0-55.20251223git.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2026-3b29263ab5 (gnulib-0-55.20251223git.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-cf97e005ae (gnulib-0-55.20251223git.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-83eb1cb148 (gnulib-0-55.20251223git.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.