unable to link xdr functions with groovy and hirsute

Bug #1923361 reported by Dominique Rousset
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libtirpc (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Hi,
I have a technical code that relies on XDR for it's internal data format. I cannot compile it anymore with hirsute (and groovy).

As a simpler test I tried to compile

#include <rpc/xdr.h>
int main(){
xdr_void();
}

called it testxdr.c
gcc -o testxdr -I/usr/include/tirpc -ltirpc testxdr.c

-I and -l options are indicated by package-config.

With the include compilation is OK but the linking fails with an indefinite reference to xdr_void.
With focal, nor -I neither -l options are necessary, xdr functions are within glibc.
With hirsute nm says that xdr_void symbol is defined in libtirpc.so and surprisingly (for me) in glibc 2.33 (should have been removed since 2.32 ?)

Any help is welcome !

D.

Revision history for this message
Robie Basak (racb) wrote :

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

Changed in libtirpc (Ubuntu):
importance: Undecided → Low
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (3.6 KiB)

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...

Read more...

Changed in libtirpc (Ubuntu):
status: New → Confirmed
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

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?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.