How is an 'undefined symbol' error possible if shared dependencies provide that symbol?

Question

I'm trying to compile GTK 3.24.33 from source. At some point in the build process I got the following error

Cannot load module /home/felix/apps/src/libraries/gtk-3.24.33/modules/input/im-wayland.la: /home/felix/apps/src/libraries/gtk-3.24.33/modules/input/.libs/im-wayland.so: undefined symbol: wl_proxy_marshal_flags

Indeed

nm /home/felix/apps/src/libraries/gtk-3.24.33/modules/input/.libs/im-wayland.so | grep wl_proxy_marshal_flags

returns

U wl_proxy_marshal_flags

If I do

ldd /home/felix/apps/src/libraries/gtk-3.24.33/modules/input/.libs/im-wayland.so

I get among other dependencies

libwayland-client.so.0 => /home/felix/apps/install/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f417c745000)

and

nm /home/felix/apps/install/lib/x86_64-linux-gnu/libwayland-client.so.0 | grep wl_proxy_marshal_flags

returns

0000000000006740 T wl_proxy_marshal_flags

How is it possible that there occurs an undefined symbol error? It seems to me as if there's all the necessary information available to find the symbol wl_proxy_marshal_flags.

Answer 1

How is it possible that there occurs an undefined symbol error? It seems to me as if there's all the necessary information available to find the symbol wl_proxy_marshal_flags.

There are at least two possible answers:

1. The symbol definition is present in libwayland-client.so.0, but is not exported from it.
2. Some other version of libwayland-client.so.0 is getting loaded into whatever binary is invoked in the failing build step.

To prove or disprove (1), use nm -D /home/felix/apps/install/lib/x86_64-linux-gnu/libwayland-client.so.0 | grep wl_proxy_marshal_flags. If the symbol appears in nm -D ... output, then it is is exported (and available for linking by im-wayland.so). If it doesn't, then (1) is the root cause.

To figure out which libwayland-client.so.0 is getting loaded during the build, you'll have to figure out which Makefile command is being executed, and prefix it with env LD_DEBUG=files,libs .... Using that environment variable instructs the dynamic loader to print which binaries and libraries it is loading. Search that output for libwayland-client.so.0. If the system version (instead of the one you built) is getting loaded, that version may not have wl_proxy_marshal_flags exported from it.

If (2) is the cause, you may have to set LD_LIBRARY_PATH before executing the build. (This would also imply that the Makefiles for GTK are broken.)

Answer 2

A possible solution for people dropped off by google with amdgpu, maybe after updating some ubuntu 22.04:

In my case the problem was that the referred libwayland showing in ldd (e.g. ldd -r krusader - or whenever executable that gives you the issue) is in /opt/admgpu instead the one in /usr/lib/x86_64-linux-gnu.

Do not know exactly the reason for that. After upgrade this led to several problems (for example cannot get libgtk3 working again unless downgrading it).

Finally, the solution for me was to edit amdgpu files in /etc/ld.so.conf.d by adding /usr/lib/x86_64-linux-gnu at the first line. Then, rebuild the ld indexes with sudo rm /etc/ld.so.cache and sudo ldconfig. This way the ldd resolves the correct linked objects and things get to work again.

My /etc/ld.so.conf.d/20-amdgpu.conf looks like

/usr/lib/i386-linux-gnu
/usr/lib/x86_64-linux-gnu