Re: [BUG] nfs-utils 2.9.2: exportfs link failure with --disable-nfsdctl

On 8/5/26 3:32 AM, Jaipaul Cheernam wrote:
> 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.
I just went ahead an took Option B adding you as the author
and I did the Signed-off-by: since it did fix the bug.

Committed (tag: nfs-utils-2-9-3-rc1)

thanks!

steved.

> 
>    Thanks,
>    Jaipaul
> 
>