On Fri, Nov 19, 2021 at 05:58:19PM +0100, Florian Weimer wrote: > * Dmitry V. Levin: > > > Let's make clear what's going on here. First of all, dwfl-proc-attach.c > > does not use dlopen so it doesn't pull it in and doesn't need -ldl. > > In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so > > which in turn uses dlopen and is already linked with -ldl. > > When elfutils is configured with --enable-gprof or --enable-gcov, > > BUILD_STATIC is enabled and dwfl-proc-attach.o is linked with > > ../libdw/libdw.a -lz $(zip_LIBS) $(libelf) $(libebl) -ldl -lpthread > > which already contains -ldl. > > In any case, I fail to understand why dwfl-proc-attach might need > > an extra -ldl, especially in LDFLAGS which goes before LDADD > > in the linking command. > > It may have to do with --as-needed that some builds use. If there are > no pending undefined references, some linkers drop earlier shared object > references with --as-needed (similar to what happens with static > archives). > > The GCC LTO plugin results in ld looking at more objects in greater > detail for some reason. Without LTO and --as-needed, you probably don't > get a dlopen export (if you do not link with -E) because indirect > dependencies are not consulted, breaking the valgrind workaround because > there is no interposition.
Thanks. I suppose adding -rdynamic to dwfl_proc_attach_LDFLAGS should be a more correct fix. -- ldv
