[lttng-dev] [RELEASE] Babeltrace 2.0.0-pre1

[Jérémie Galarneau]

On 13 June 2017 at 13:18, Nathan Lynch <nathan_lynch at mentor.com> wrote:
> Jérémie Galarneau <jeremie.galarneau at efficios.com> 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