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

[Steve D. <st...@re...>]

Hello,

My apologies for the delayed response...

On 1/27/26 4:33 PM, Markus Mayer via Libtirpc-devel wrote:
> 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.
I do understand your point... My question is what would break if
--enable-rpcdb defaulted to yes, instead of no?

steved.

> 
> 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
> 
> 
> _______________________________________________
> Libtirpc-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
>