[BUG] nfs-utils 2.9.2: exportfs link failure with --disable-nfsdctl
Jaipaul Cheernam <[email protected]> Wed, 5 Aug 2026 09:32:35 +0200
| Newsgroups | gmane.linux.nfs |
|---|---|
| Message-ID | <[email protected]> |
Hi, Building nfs-utils 2.9.2 with --disable-nfsdctl fails to link exportfs. This is a regression from 2.9.1. Reproducer: tar xf nfs-utils-2.9.2.tar.xz cd nfs-utils-2.9.2 ./configure --disable-nfsdctl --disable-gss --disable-svcgss make (--disable-gss is just to avoid the krb5 dependency; the bug is triggered by --disable-nfsdctl alone.) Error: /usr/bin/ld: exportfs-exportfs.o: in function `unexportfs_parsed': exportfs.c:491: undefined reference to `nfsd_nl_cmd_str' collect2: error: ld returned 1 exit status Root cause: nfsdnl.c (new in 2.9.2) provides nfsd_nl_cmd_str() and is compiled into libnfs only under if CONFIG_NFSDCTL in support/nfs/Makefile.am. But exportfs.c calls it under #ifdef HAVE_NFSD_NETLINK, which configure.ac defines unconditionally: AC_DEFINE([HAVE_NFSD_NETLINK], 1, [Define to 1 if nfsd generic netlink support is available]) So exportfs always compiles the netlink code path, but the implementation isn't linked in when --disable-nfsdctl is used. This isn't triggered with the default configuration because enable_nfsdctl defaults to "yes". Possible fixes: Option A — always compile nfsdnl.c into libnfs (remove the CONFIG_NFSDCTL guard from support/nfs/Makefile.am). exportfs would always have netlink unlock-export support. libnl is already unconditionally required so this adds no new dependency: --- a/support/nfs/Makefile.am +++ b/support/nfs/Makefile.am @@ -11,14 +11,10 @@ libnfs_la_LIBADD = libnfsconf.la -luuid libnfs_la_CPPFLAGS = $(AM_CPPFLAGS) $(CPPFLAGS) -I$(top_srcdir)/support/reexport -if CONFIG_NFSDCTL libnfs_la_SOURCES += nfsdnl.c -libnfs_la_CPPFLAGS += $(LIBNL3_CFLAGS) $(LIBNLGENL3_CFLAGS) \ - -I$(top_srcdir)/utils/nfsdctl +libnfs_la_CPPFLAGS += $(LIBNL3_CFLAGS) $(LIBNLGENL3_CFLAGS) libnfs_la_LIBADD += $(LIBNL3_LIBS) $(LIBNLGENL3_LIBS) -endif libnfsconf_la_SOURCES = conffile.c xlog.c Option B — gate HAVE_NFSD_NETLINK on --enable-nfsdctl, so exportfs skips the netlink path when nfsdctl is disabled. nfsdnl.h already provides a static inline stub returning -ENOSYS for this case: --- a/configure.ac +++ b/configure.ac @@ -256,8 +256,6 @@ PKG_CHECK_MODULES(LIBNLGENL3, libnl-genl-3.0 >= 3.1) AC_CHECK_HEADERS(linux/nfsd_netlink.h) -AC_DEFINE([HAVE_NFSD_NETLINK], 1, - [Define to 1 if nfsd generic netlink support is available]) # ensure the system netlink headers have the latest features AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <linux/nfsd_netlink.h>]], @@ -279,6 +277,8 @@ enable_nfsdctl="yes") AM_CONDITIONAL(CONFIG_NFSDCTL, [test "$enable_nfsdctl" = "yes" ]) if test "$enable_nfsdctl" = yes; then + AC_DEFINE([HAVE_NFSD_NETLINK], 1, + [Define to 1 if nfsd generic netlink support is available]) PKG_CHECK_MODULES(LIBREADLINE, readline) fi Both build cleanly. I lean towards Option B as it preserves the design intent that --disable-nfsdctl disables all netlink interaction with nfsd, and keeps the feature gating consistent between configure.ac and Makefile.am. But Option A has merit if exportfs should always release state via netlink regardless of whether the nfsdctl utility is built. Which approach is preferred? Happy to send a formal patch either way. Thanks, Jaipaul