On 13 June 2017 at 13:18, Nathan Lynch <[email protected]> wrote: > Jérémie Galarneau <[email protected]> writes: >> Known limitations >> ----------------- >> >> Being a "pre" release, a number of features are still in active development >> and >> bugs are being worked on. >> >> This first release does not expose the Python packages (present in the Git >> tree) >> as we are reworking them to accomodate the latest round of API changes. >> >> * The "--stream-intersection" mode is not available. >> * Traces without their packet context field type's `timestamp_begin` and >> `timestamp_end` fields mapped to a clock class fail to be read >> (traces produced by old versions of LTTng and CTF Writer). >> * The man page has not been updated to match the new CLI. >> * Performance has not been a focus yet and "verbose" logging is built-in by >> default to facilitate bug reporting. We expect this to slow down Babeltrace >> significantly. > > Just confirming this :-) In my quick experiments the time to convert CTF > to text is about 6x vs the stable-1.5 branch. > > >> * API documentation is incomplete. >> * Plugin man pages are not available. >> * Discarded events and dropped packets notifications are not emitted. >> * A number of tests are failing. >> * Built-in plugins are not re-linked into the application if they are >> modified. >> * The babeltrace-log utility is not present. >> * This version does not build on Windows (patches pending). > > Where can I find the Windows/mingw patches? >
A fair number of them are in this pull request: https://github.com/efficios/babeltrace/pull/56 Michael (CC-ed) is still re-working/cleaning some patches on his end. I don't know if it's in a shareable state, Michael? > >> * API cleanups are planned (mostly namespacing changes). >> >> Let us know of all problems/bugs you encounter with this release! > > Static linking still needs work, specifically case #3 from this comment: > > https://bugs.lttng.org/issues/1055#note-2 > > Building on Fedora 25 with 'make LDFLAGS=-all-static' gets: Haven't tried that combination personally yet. FYI, the in-tree plugins are embed-able by setting BT_BUILT_IN_PLUGINS=1 at configure time. > > ../lib/.libs/libbabeltrace.a(common.o): In function `bt_get_home_dir': > /home/nathanl/src/babeltrace/tmp/native/all/common/../../../../common/common.c:138: > warning: Using 'getpwuid' in statically linked applications requires at > runtime the shared libraries from the glibc version used for linking > /usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libglib-2.0.a(libglib_2_0_la-gutils.o): > In function `g_get_user_database_entry': > (.text+0xdc): warning: Using 'getpwnam_r' in statically linked applications > requires at runtime the shared libraries from the glibc version used for > linking > /usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libglib-2.0.a(libglib_2_0_la-gutils.o): > In function `g_get_user_database_entry': > (.text+0x114): warning: Using 'getpwuid_r' in statically linked applications > requires at runtime the shared libraries from the glibc version used for > linking > /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in > `/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libc.a(strcmp.o)' > can not be used when making an executable; recompile with -fPIE and relink > with -pie > collect2: error: ld returned 1 exit status > > The getpwuid and getpwnam_r warnings are raised due to code that seems > intended to load plugins from the user's home directory; I wonder if > that facility could made configurable. Or is there another way to deal > with this? I have not looked into a solution for that, but I agree the dynamic plugin support could be disabled as a configuration option. > > The STT_GNU_IFUNC strcmp error implicates export-dynamic, I think. > Still looking into it. Thanks for looking into it! Jérémie -- Jérémie Galarneau EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
