Created attachment 573514 [details]
When application linked with libell.so (net-wireless/iwd for example) starts, it crashes with error libell.so.0: undefined symbol: dlclose. ldd -r /usr/lib64/libell.so gives this output:
libc.so.6 => /lib64/libc.so.6 (0x00007f3fffdad000)
undefined symbol: dlclose (/usr/lib64/libell.so)
undefined symbol: dlopen (/usr/lib64/libell.so)
undefined symbol: dlsym (/usr/lib64/libell.so)
undefined symbol: dlerror (/usr/lib64/libell.so)
With LD_PRELOAD=/lib64/libdl-2.29.so application starts normally.
any update on this? bug still persists
I can reproduce the ldd -r output, but I have never been able to reproduce any crash
I just hit this, me and the reporter have this in common:
> ld GNU gold (Gentoo 2.32 p1 2.32.0) 1.16
The build system is missing -ldl somewhere, you can fix this temporarily (wrongly) by adding "-ldl" to your LDFLAGS.
I'm still not sure how to reproduce any runtime or build failure. This makes it harder to report upstream.
Yes ell should be linked to libdl but since iwd is linked to it anyway, I cannot see any failure *here*.
I guess, in some cases (e.g. GOLD linker, or LTO, or some other linker flags) the resulting iwd binary is not linked to libdl and then it crashes.
The gold linker should be all you need to reproduce it. We have --as-needed in LDFLAGS by default forever now.
Building both ell & iwd with ld.gold, I can now see an undefined symbol problem in "ldd -r /usr/libexec/iwd" output, but I'm still not able to reproduce any runtime crash.
I will still work on sending this upstream.
Upstream has removed all code using libdl so this will "resolve itself" on next release: