Re: [Libtirpc-devel] Build problems after changes to RPC database support

[Markus M. <mm...@br...>]

Hello again,

Any thoughts or updates on this?

I believe that getrpcbyname() and getrpcbynumber() should be enabled
without the user having to specify "--enable-rpcdb", especially since
the build error that results from omitting it will only be found later
on when building rpcbind, by which point it might become quite a
hassle to identify the root cause and the fix.

Maybe a "--disable-rpcdb" flag would be more appropriate for those who
want to explicitly disable this functionality. I am assuming most
users would want it to be enabled, so that should be the default.

If that sounds undesirable, "--enable-rpcdb" could be retained, with
the intention of enabling /etc/rpc support, but without it affecting
whether getrpcbyname() and getrpcbynumber() are provided by libtirpc.
Instead, it should rely on "configure" to make that call, just like it
used to.

Thanks,
-Markus

On Thu, 8 Jan 2026 at 14:44, Markus Mayer <mm...@br...> wrote:
>
> Hi all,
>
> We have come across a build issue with libtirpc-1.3.7 that was not
> present with libtirpc-1.3.6. It happens only with a certain toolchain
> / libc combination and is due to the introduction of the
> "--enable-rpcdb" configure option.[1]
>
> The build is now failing with our LLVM + musl-libc toolchain. As far
> as I can tell, the issue isn't related to LLVM but caused by the fact
> that musl-libc does not provide getrpcbyname() and getrpcbynumber().
> Specifically, rpcbind will fail to link with the new libtirpc. The
> error looks like this:
>
> gcc  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -O2 -g0  -I/local/users/jenkins/workspace.o/buildroot_linux-5.4_llvm/output/stbllvm-13.0-0.6/arm/host/bin/../arm-buildroot-linux-musleabihf/sysroot/usr/include/tirpc
>   -o rpcinfo src/rpcinfo.o
> -L/local/users/jenkins/workspace.o/buildroot_linux-5.4_llvm/output/stbllvm-13.0-0.6/arm/host/bin/../arm-buildroot-linux-musleabihf/sysroot/usr/lib
> -ltirpc
> ld.lld: error: undefined symbol: getrpcbynumber
> >>> referenced by security.c
> >>>               src/security.o:(logit)
> clang-13: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[2]: *** [Makefile:534: rpcbind] Error 1
> make[2]: *** Waiting for unfinished jobs....
> ld.lld: error: undefined symbol: getrpcbynumber
> >>> referenced by rpcinfo.c
> >>>               src/rpcinfo.o:(main)
> >>> referenced by rpcinfo.c
> >>>               src/rpcinfo.o:(main)
> >>> referenced by rpcinfo.c
> >>>               src/rpcinfo.o:(pmapdump)
> >>> referenced 3 more times
>
> ld.lld: error: undefined symbol: getrpcbyname
> >>> referenced by rpcinfo.c
> >>>               src/rpcinfo.o:(getprognum)
> clang-13: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> So, while the build error happens with rpcbind, the root cause lies
> with libtirpc.
>
> With libtirpc-1.3.6, this was not an issue, because it would detect at
> configure time that it needed to provide getrpcbyname() & co, and so
> rpcbind would link just fine. Configure in 1.3.7 is still detecting
> correctly that getrpcbyname() & co. are missing, but it will do
> nothing about it unless "--enable-rpcdb" is given on the command line.
> Without "--enable-rpcdb", getrpcent.c will not be compiled in,
> regardless of configure's findings, so the missing functions will not
> be provided, and the link stage of rpcbind will fail.
>
> Of course, this can be worked around by specifying "--enable-rpcdb"
> when calling "configure" for libtirpc, but it is still a regression.
> The build of another tool (rpcbind), which has remained unchanged,
> suddenly fails, because libtirpc was upgraded from 1.3.6 to 1.3.7.
>
> If I understand the commit message correctly, the change in question
> was introduced to fix linker issues, specifically with LLD. Curiously,
> we are now *experiencing* linker issues with LLD as a result of this
> change (not that it is LLD's fault at all in this case).
>
> Is there a way the original goal of the fix can be preserved while at
> the same time also not causing the kind of linker problem we are
> seeing? Would it work to have "configure" enable getrpcent.c whenever
> it detects getrpcbyname() & co are missing without requiring a flag
> given by the user? It doesn't seem right that it correctly detects the
> functions are missing, but still won't include them, even though it
> could.
>
> Please let me know if there are some things I should try out or some
> experiments I should run.
>
> Thanks,
> -Markus
>
> [1] https://git.linux-nfs.org/?p=steved/libtirpc.git;a=commitdiff;h=7cea8ad66aec