[lttng-dev] making liburcu and lttng coexist in a LGPL'ed program

Jeff Layton jlayton at redhat.com
Tue Nov 27 13:17:55 EST 2018


The nfs-ganesha project has used lttng for quite some time to handle
tracing. Recently though, we decided to start building liburcu in as a
mandatory component, with an eye toward using it in certain areas.

Before this change, the code linked in liburcu-bp directly, but now we
just use liburcu. Unfortunately, when we enable tracepoints in the build
now, we get errors like this at link time:

--------------------8<----------------
[ 96%] Linking C executable ganesha.nfsd
/usr/bin/ld: libMainServices.a(nfs_worker_thread.c.o): undefined reference to symbol 'rcu_gp_bp'
/usr/bin/ld: //usr/lib64/liburcu-bp.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [MainNFSD/CMakeFiles/ganesha.nfsd.dir/build.make:308: MainNFSD/ganesha.nfsd] Error 1
make[1]: *** [CMakeFiles/Makefile2:2740: MainNFSD/CMakeFiles/ganesha.nfsd.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
--------------------8<----------------

nfs-ganesha defines _LGPL_SOURCE, and that makes lttng use the
redefinitions in tracepoint-rcu.h. If I disable _LGPL_SOURCE, it all
builds as expected.

I found a similar bug here:

    https://bugs.lttng.org/issues/1156

Any thoughts on the right fix for this? We'd like to eat our cake and
have it too, so that we can have _LGPL_SOURCE defined, lttng enabled,
and the urcu flavor be determined at runtime.

Many thanks,
-- 
Jeff Layton <jlayton at redhat.com>



More information about the lttng-dev mailing list