Zfs fails to build with autoconf 2.70 #11413
Comments
edacval
added
Status: Triage Needed
behlendorf
added
Type: Building
|
Yeah, just ran into this too. |
|
Opened PR #11419 to address this. Note it doesn't resolve the following warning. However, this warning isn't fatal, isn't specific to 2.70, and isn't harmful. Additional investigation will be needed to fully quiet this warning with the gettext integration. |
|
The warning is actually an "error" as specified by the message text, it is fatal (autoreconf exits 1), and it is (in this incarnation) specific to 2.70... The autoconf 2.69 output is: (no mention of "error", does not return failure) ... I noticed this and posted to the autoconf mailing list trying to understand the cause: https://lists.gnu.org/archive/html/autoconf/2020-12/msg00044.html |
|
I applied @behlendorf's 2.70 patch and the |
|
@eli-schwartz you're right, it does appear to have been promoted to an error. I overlooked that since as @tycho mentioned even after the error everything can still be build properly. We'll of course need to get it sorted out. But while we're looking at there I don't think there's any reason to hold off merging the other unrelated autoconf 2.70 updates. |
|
@tycho, ignoring the error (at least for me) allows the compile but the DKMS files are hosed: As a workaround, is it safe to remove user-gettext.m4 (and references) temporarily? |
Uh, hm. Seems to work here? EDIT: My PKGBUILD is probably different though. https://git.uplinklabs.net/steven/projects/archlinux/ec2/ec2-packages.git/tree/zfs-git |
|
Possibly a packaging related issue, if I figure out the difference I'll post here. FYI @eli-schwartz (I'm just using a version from the zfs-dkms-git AUR + @behlendorf's patch) I can confirm removing the function contents in user-gettext.m4 prevents the autoconf error. |
That's true. PR #11419 does not solve this issue, but it does solve the
I'm sure it does -- at the "cost" of removing gettext functionality (and resulting in linker errors if libc does not contain a gettext symbol usable without Admittedly, it does not seem like the utils distribute .mo catalogs either, despite decorating several message strings as translatable (and of course linking to libc/libintl) -- meaning this intl infrastructure is spending time in order to do nothing since there's nothing to translate to. Perhaps there was intent at some point to set up a translation team that never panned out?
My packaging scripts do not install the entire source tree, to cut down on the size. This file was not needed for autoconf 2.69 and is needed for autoconf 2.70; I would update the PKGBUILD but it's blocked by the gettext problem... @tycho's PKGBUILD is everything I moved away from; it is 5 times the download size and nearly 3 times the installed size due to the high number of unused files it packages. |
Several m4 macros have been retired in autoconf 2.70. Update the the build system to use the new macros provided to replace them. * Replaced AC_HELP_STRING with AS_HELP_STRING. * Replaced AC_TRY_COMPILE with AC_COMPILE_IFELSE/AC_LANG_PROGRAM. * Replaced AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET * Replaced AC_PROG_LIBTOOL with LT_INIT * $CPP is not defined in ZFS_AC_KERNEL and really shouldn't be directly used like this. Replace it with an $AWK command to extract the kernel source version. Reviewed-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #11413 Closes #11419
The backstory here is that the ZFS code has always decorated the CLI messages with |
Looks like most of the package size in my PKGBUILD is just diff --git a/zfs-git/PKGBUILD b/zfs-git/PKGBUILD
index b4c64bd5..2115c421 100644
--- a/zfs-git/PKGBUILD
+++ b/zfs-git/PKGBUILD
@@ -35,6 +35,8 @@ prepare() {
cd "$srcdir/${_module}"
patch -Np1 -i ../0001-dsl_scan-allow-users-to-clear-scan-logs-entirely.patch
patch -Np1 -i ../0001-Autoconf-2.70-compatibility.patch
+ sed -ri '/^[ \t]*tests\//d' configure.ac
+ sed -ri 's/ tests / /' Makefile.am
}
build() {
@@ -72,6 +74,7 @@ package_zfs-dkms() {
install -d ${pkgdir}/usr/src
cp -a ${srcdir}/${_module}-${pkgver} ${pkgdir}/usr/src/
rm -rf ${pkgdir}/usr/src/${_module}-${pkgver}/.git
+ rm -rf ${pkgdir}/usr/src/${_module}-${pkgver}/tests
}
package_zfs-utils() {Anyway, I guess we're getting a bit off topic. |
|
wouldn't just adding |
Sadly, no, that doesn't solve it. It still spews the same error and returns a nonzero exit code. It seems like autoconf has trouble noticing that |
|
Opened PR #11430 with a minimal change to avoid the fatal error and restore the status quo for the moment. |
The fatal error should be fixed by https://git.savannah.gnu.org/cgit/autoconf.git/commit/?h=branch-2.70&id=35b1708c3961dce31e4ce43014e71d77aa4b5e31 See the autoconf maintainer's reply here: https://lists.gnu.org/archive/html/autoconf/2021-01/msg00006.html
So, there should be a new bugfix release of autoconf in a few days that no longer errors out here. |
|
@eli-schwartz that's excellent news! In that case, there's no need for us to add a workaround and I'll close that PR. |
Several m4 macros have been retired in autoconf 2.70. Update the the build system to use the new macros provided to replace them. * Replaced AC_HELP_STRING with AS_HELP_STRING. * Replaced AC_TRY_COMPILE with AC_COMPILE_IFELSE/AC_LANG_PROGRAM. * Replaced AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET * Replaced AC_PROG_LIBTOOL with LT_INIT * $CPP is not defined in ZFS_AC_KERNEL and really shouldn't be directly used like this. Replace it with an $AWK command to extract the kernel source version. Reviewed-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #11413 Closes #11419
|
Closing. This should be resolved with the next version of autoconf. The required changes for 2.70 were included in OpenZFS v2.0.1 and upstream autoconf will be switching the AM_GNU_GETTEXT error back to a warning. |
|
@behlendorf if you would like to improve the localization infrastructure, I could help with this. We would not need to manage our own team of translators, there are services like transifex where people do this and you just pull updates from them, I do this for another project I work on. |
Several m4 macros have been retired in autoconf 2.70. Update the the build system to use the new macros provided to replace them. * Replaced AC_HELP_STRING with AS_HELP_STRING. * Replaced AC_TRY_COMPILE with AC_COMPILE_IFELSE/AC_LANG_PROGRAM. * Replaced AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET * Replaced AC_PROG_LIBTOOL with LT_INIT * $CPP is not defined in ZFS_AC_KERNEL and really shouldn't be directly used like this. Replace it with an $AWK command to extract the kernel source version. Reviewed-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11413 Closes openzfs#11419
Several m4 macros have been retired in autoconf 2.70. Update the the build system to use the new macros provided to replace them. * Replaced AC_HELP_STRING with AS_HELP_STRING. * Replaced AC_TRY_COMPILE with AC_COMPILE_IFELSE/AC_LANG_PROGRAM. * Replaced AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET * Replaced AC_PROG_LIBTOOL with LT_INIT * $CPP is not defined in ZFS_AC_KERNEL and really shouldn't be directly used like this. Replace it with an $AWK command to extract the kernel source version. Reviewed-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#11413 Closes openzfs#11419
System information
Describe the problem you're observing
After update autoconf to 2.70 version, ./autogen.sh exits with error
configure.ac: error: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION or AM_GNU_GETTEXT_REQUIRE_VERSION.Describe how to reproduce the problem
Include any warning/errors/backtraces from the system logs
./autogen.sh output:
The text was updated successfully, but these errors were encountered: