Hi.
Can anyone tell me how the dlopen() calls work on a Fedora system if a static libdw is used?
On SuSE systems, if libdw.so is used (containing relevant libebl) I see the first dlopen("$ORIGIN/../$LIB/elfutils/libebl_x86_64.so" succeed as: open("/usr/lib64/../lib64/elfutils/libebl_x86_64.so", O_RDONLY) = 8
If the code is statically linked against libdw.a the first dlopen attempts to generate a path "/{path_to_static_exe}/../lib64/elfutils/libebl_x86_64.so" which fails. The second basename dlopen() attempts a path search but this never looks in the "elfutils" subfolder.
Tony
Probably nobody has really used static linking for libdw before. We wouldn't recommend it.
Since the library has no way to know where you're installing a program you link it into, the $ORIGIN methods are not really viable. Resorting to an absolute file name in the library would be dismal.
The library tries the unadorned DSO name if the $ORIGIN name fails. So you can just build your program with an appropriate DT_RUNPATH, as we do for libdw.so itself (see libdw/Makefile.am).
Thanks, Roland
On 12/14/2011 01:21 PM, Roland McGrath wrote:
Probably nobody has really used static linking for libdw before. We wouldn't recommend it.
Indeed. The usage in question comes from the makedumpfile package (http://sourceforge.net/projects/makedumpfile). They actually link everything using --static .... "$(CC) $(CFLAGS) $(LDFLAGS) $(OBJ_PART) $(OBJ_ARCH) -o $@ $< -static -ldw -lbz2 -lebl -ldl -lelf -lz"
I guess someone at our end (in an attempt to reduce the size of the kdump initrd) modified this to a combination of -Wl,-Bstatic for the elfutils stuff and -Wl,-Bdynamic for the remaining libs.
Since the library has no way to know where you're installing a program you link it into, the $ORIGIN methods are not really viable. Resorting to an absolute file name in the library would be dismal.
Agreed.
Tangentally: The whole dlopen() - to load the backend - seems fairly non-static friendly, i.e no way to statically incorporate these elements. No argument, I just wanted to verify I wasn't missing something.
The library tries the unadorned DSO name if the $ORIGIN name fails. So you can just build your program with an appropriate DT_RUNPATH, as we do for libdw.so itself (see libdw/Makefile.am).
Thanks Roland, I'll try this. Appreciate the reply.
Tony
Tangentally: The whole dlopen() - to load the backend - seems fairly non-static friendly, i.e no way to statically incorporate these elements. No argument, I just wanted to verify I wasn't missing something.
Yes, well, certain elfutils developers are thoroughly hostile to static linking. Last I knew, Debian was using a local patch that builds all the backends in rather than loading them. But I haven't looked at their packages lately.
On 12/14/2011 02:36 PM, Roland McGrath wrote:
Last I knew, Debian was using a local patch that builds all the backends in rather than loading them. But I haven't looked at their packages lately.
Thanks for the pointer! I see it in Lenny. In newer versions there is no libebl (backend so's are in libdw1) and the libdw-dev page states "It also contains a static version of libdw. Only link to the static version for special cases and when you don't need anything from the ebl backends". Curious as it seems to have some external references, ~shrug~
nm debian-sid/libdw-dev/usr/lib/libdw.a | grep backend U ebl_openbackend U ebl_closebackend U ebl_openbackend
Thanks for the help!
elfutils-devel@lists.fedorahosted.org
-
Roland McGrath -
Tony Jones