unable to link xdr functions with groovy and hirsute

Thank you for taking the time to write up this report and helping to make Ubuntu better.

It's not clear to me if this is expected behaviour or not. Perhaps the easiest way to determine this would be to track down the root cause of what's happening with the xdr_void symbol by examining the libtirpc sources.

However as this isn't likely to affect many Ubuntu users, I'm going to set Importance: Low. I don't expect it to receive expert attention soon. Feel free to continue to use this bug to coordinate with others, and if you do find a specific solution then we can help with getting it landed.

In case it's not a bug, you can find community support options here: http://www.ubuntu.com/support/community

FYI this is a spin off from https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1905360

It is also related to the same seen in libvirt:
https://listman.redhat.com/archives/libvir-list/2020-August/msg00921.html

I have resolved it in those and others.
The TL;DR is that Ubuntu has kept this in glibc for years (was default disabled, but we kept it for compatibility) and now finally upstream removed it which causes this bumpy ride.

Still within impish we have
ii libc6:amd64 2.34-0ubuntu2 amd64 GNU C Library: Shared libraries
ii libtirpc3:amd64 1.3.2-2 amd64 transport-independent RPC library

And the example symbol that Dominique referred (as well as others that I hit in my other cases) are present in both but gladly properly versioned differently:

root@i:~# eu-readelf -a /lib/x86_64-linux-gnu/libc.so.6 | grep xdr_void | grep GLOBAL
  191: 000000000016da90 10 FUNC GLOBAL DEFAULT 16 xdr_void@GLIBC_2.2.5
root@i:~# eu-readelf -a /lib/x86_64-linux-gnu/libtirpc.so.3.0.0 | grep xdr_void | grep GLOBAL
  306: 0000000000013e70 10 FUNC GLOBAL DEFAULT 15 xdr_void@@TIRPC_0.3.0

You can just look at the linking step by keeping interim files:
$ gcc -v -o testxdr -save-temps=obj -I/usr/include/tirpc -L /usr/lib/x86_64-linux-gnu -ltirpc testxdr.c

Then you can re-run just the linking step and inspect the .o
$ /usr/lib/gcc/x86_64-linux-gnu/11/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/11/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper -plugin-opt=-fresolution=testxdr.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o testxdr /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/11/crtbeginS.o -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -ltirpc testxdr.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/11/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crtn.o

$ eu-readelf -a testxdr.o | grep xdr_void
  0x0000000000000009 X86_64_PLT32 000000000000000000 -4 xdr_void
    4: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UNDEF xdr_void
  [ 10] xdr_void

I'd expect/want to see (maybe only after linking) something like:
  149: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF xdr_uint64_t@TIRPC_0.3.0 (13)

I've checked the other successful builds that properly link against libtirpc now.
They all specify the target lib explicitly at build time.

In the short time I had I couldn't find where they pick it up, but this makes your test-build work f...

Subscribing Doko for his libc (for xdr removal) and even more so toolchain experience.
What would you recommend - is there a fix to the .pc file of libvtirpc needed - or anything else?