Method to get LTTNG-UST version during runtime?

[Kienan Stewart]

Hi Norbert,

On 6/23/25 3:04 PM, Norbert Lange wrote:
> I dont want to use anything else, I just want  to add instrumentation
> for dynamically loaded tracepoints that does next to nothing if not
> activated (see [1]).
> liblttng-ust-ctl is not even ABI compatible between 2.13 and 2.14
> (different soname), so that's pretty useless since it already binds to
> either 2.13 or 2.14 at compile-time.

I hadn't considered that the soname for liblttng-ust-ctl had changed 
between versions. Thanks for pointing that out.

> 
> [1] - https://lists.lttng.org/pipermail/lttng-dev/2021-May/030004.html
> 
> Norbert
>

Then, it sounds to me like there's not a way to do the check you're 
asking for with the public API at this time.

If there's a way you would like to address it that matches your needs, 
you're welcome to propose a patch to introduce it.

thanks,
kienan

> Am Mo., 23. Juni 2025 um 16:21 Uhr schrieb Kienan Stewart
> <kstewart at efficios.com>:
>>
>> Hi Norbert,
>>
>> If you link to liblttng-ust-ctl, you can use `lttng_ust_ctl_get_version`.
>>
>> thanks,
>> kienan
>>
>>
>> On 6/18/25 11:22 AM, Norbert Lange via lttng-dev wrote:
>>> Hi,
>>>
>>> there are some substantial changes in 2.14.0 that afffect how/if
>>> tracing is possible.
>>> For ex. c246521ddcba1d1d28cfa0482aa500b9122e7264 allows doing more work upfront
>>> by calling lttng_ust_init_thread().
>>> With 2.13.x the same code will instead do various syscalls or
>>> allocations during the first tracepoints, violating realtime
>>> constraints and possible abort the process.
>>>
>>> I miss an easy method to inspect the Lttng UST Version for checks or
>>> workarounds.
>>>
>>> There is the lttng_ust_loaded variable that could be abused to carry
>>> an packed version instead of 1. (Of course that could always cause
>>> fallout)
>>>
>>> Regards, Norbert
>>