[lttng-dev] lttng-ust, libtool and cross-compilation

[Mathieu Desnoyers]

* Christian Babeux (christian.babeux at efficios.com) wrote:
> Hi all,
> 
> When cross-compiling lttng-ust, some users might encounter an issue
> regarding missing libraries like this one:
> 
> /usr/lib/gcc/powerpc-linux-gnu/4.4.5/../../../../powerpc-linux-gnu/bin/ld:
> warning: liblttng-ust-tracepoint.so.0, needed by
> ../../liblttng-ust/.libs/liblttng-ust.so, not found (try using -rpath
> or -rpath-link)
> ../../liblttng-ust/.libs/liblttng-ust.so: undefined reference to
> `init_tracepoint'
> ../../liblttng-ust/.libs/liblttng-ust.so: undefined reference to
> `__tracepoint_probe_unregister'
> ../../liblttng-ust/.libs/liblttng-ust.so: undefined reference to
> `__tracepoint_probe_register'
> ../../liblttng-ust/.libs/liblttng-ust.so: undefined reference to
> `exit_tracepoint'
> 
> After some digging, this issue seems to appear only in cross-compilation
> setup, especially on Debian based system.
> 
> The lttng-ust libraries dependencies can be summarized as follow:
> 
> +-----------------+ -> liblttng-ust-tracepoint.so -> liburcu-bp.so
> | liblttng-ust.so | -> liblttng-ust-runtime.so
> +-----------------+ -> liblttng-ust-support.so    -> libringbuffer.so
> 
> The problem arise when linking libraries with indirect libraries dependencies.
> Other project have had this issue in the past [1].
> 
> This "bug" is caused by an upstream modification in the libtool package
> on Debian system [2]. The libtool "link_all_deplibs" flag is set to "no"
> by default on linux targets (AFAIK, other distros set it to unknown).
> 
> This has the unfortunate consequence of breaking cross-compilation
> builds because gnu-ld doesn't use rpath on cross-compilation targets.
> Hence the undefined reference errors messages.
> 
> Here are some possible ways to handle this problematic situation:
> 
> 1 - Cook our own libtool.m4 in the lttng-ust tree with the
>     libtool link_all_deplibs flag set to 'unknown'.
> 
>     Pro: No action required on the user side.
>     Con: Additional work for the maintainer to ensure that the proper
> 	 libtool.m4 is present in sources packages. Additionnal maintenance.
> 
> 2 - Add explicit dependencies to indirect libraries in the appropriates
>     Makefile.am (such as the ones found in tests/{hello, hello.cxx, fork}).
> 
>     Pro: No action required on the user side.
>     Con: Tedious.
> 
> 3 - Add a configure flag to detect bogus version of libtool and automagically
>     fix it.
> 
>     Pro: Less maintenance.
>     Con: Require user interaction when cross-compiling.

could we do a variant of (3) ? We could automagically change the
link_all_deplibs flag in our libtool.m4 in configure, and add a
"--disable-libtool-cross-compile-fixup" (or something shorter) to
disable running that script.

So typically it will require no interaction from users, except when they
"know what they are doing" and want to explicitely disable our
work-around.

Thoughts ?

Mathieu

> 
> Other components of LTTng might be affected be the same issue.
> 
> Any thoughts or additional input is quite welcome!
> 
> Thanks,
> 
> Christian
> 
> [1] - https://lists.isc.org/pipermail/bind10-dev/2011-August/002535.html
> [2] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297726

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com