LTTng » Babeltrace

After looking into this a bit I think there are two parts to this issue:

1.) Using inappropriate link flags (-Wl,--export-dynamic) prevents static link from being attempted.
2.) Once (1) is fixed, GLib APIs are used from constructor code which can run before GLib itself is initialized, causing program abort.

(1) arises from running pkg-config against "gmodule" instead of just "glib". Babeltrace doesn't use any GModule facilities, so it shouldn't need --export-dynamic to work correctly. See:

https://developer.gnome.org/glib/stable/glib-compiling.html

Fixing (1) allows static linking of the babeltrace executable to succeed. Note that configuring with --enable-static isn't enough; one must also add CFLAGS=-static LDFLAGS=--static to the configure line.

Running the binary results in many GLib assertion failures and eventual abort, due to GLib API calls in constructor functions before GLib's initialization has run (I verified this in GDB):

(process:17328): GLib-CRITICAL **: g_hash_table_lookup: assertion 'hash_table != NULL' failed                                                                                  

(process:17328): GLib-CRITICAL **: g_hash_table_insert_internal: assertion 'hash_table != NULL' failed

GLib:ERROR:gquark.c:60:g_quark_init: assertion failed: (quark_seq_id == 0)
Aborted (core dumped)

I'm not sure how to address the runtime issue with constructors at this time.

I opened this issue with an incorrect expectation on my part: that "configure --disable-shared --enable-static" is the convention for telling Autotools to build a statically linked executable. This is not so. These options only tell libtool what kinds of libraries (PIC/shared and non-PIC/static) to produce during the build, and the executable is linked according to the options available, with a preference for the shared libraries.

So there are three kinds of babeltrace executable that can be produced:
1. Fully dynamic: runtime dependencies on internal libraries (libbabeltrace.so.1, libbabeltrace-ctf.so.1, and so on) as well as runtime dependencies on external libraries (libpopt, libuuid, et al). This is the default when configured with --enable-shared and make is invoked without the user setting LDFLAGS.
2. Partially dynamic: internal libraries built-in but runtime dependencies on external libraries. (make LDFLAGS=-static)
3. Static: all dependencies built-in, no runtime dependencies. (make LDFLAGS=-all-static)

Configuring with --disable-shared --enable-static just causes the default to be case #2 since internal shared libraries are not available.

However, this produces an executable without all the plugins included:

$ ./converter/babeltrace --list
Formats available: text, ctf.

This is because the lttng-live, ctf-metadata, and dummy format libraries are dead code in the linker's view (and --no-as-needed does not change this when these are being linked statically). --whole-archive might work around it but it doesn't seem easy to use from Automake/libtool in my experimentation.

In conclusion, there is still an issue here, but it is a different one from the original report, and fully static linking is a whole other mess :) Let me know if I should open new issues so it's less confusing.

Thanks for doing the digging! I don't think a new bug report is necessary.

Case #2 from my previous comment (Partially dynamic: internal libraries built-in but runtime dependencies on external libraries. (make LDFLAGS=-static)) now works correctly, thanks.