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

Jaipaul Cheernam <[email protected]>
Newsgroups org.kernel.vger.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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.