Fix: liblttng-ust-ctl have dependencies on liburcu

Observed issue
==============

On a yocto build the liblttng-ust-ctl shared object have dependencies on
liburcu.

(The 'not found's are irrelevant here)
 ./liblttng-ust-ctl.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./liblttng-ust-ctl.so)
        linux-vdso.so.1 (0x00007ffc07910000)
        libpseudo.so => /root/oe-core/build/tmp-glibc/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib64/libpseudo.so (0x00007f8fa3e0d000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8fa3c05000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8fa3a01000)
        liburcu-bp.so.6 => not found
        liburcu-cds.so.6 => not found
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8fa37e2000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8fa33f1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8fa4069000)

On my ubuntu system:

	linux-vdso.so.1 (0x00007ffcd20aa000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faaf5282000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faaf527c000)
	libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007faaf526f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faaf524c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faaf505a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007faaf52ed000)

Cause
=====

The default behavior for AC_CHECK_LIB, when the `action-if-found` is NOT
defined, is to prepend the library to LIBS. [1]

"
If action-if-found is not specified, the default action prepends
-llibrary to LIBS and defines ‘HAVE_LIBlibrary’ (in all capitals).
"

It is important to note that the LIBS variable is used for ALL linking.

This is normally not a problem for most distributions since they force
the use of `--as-needed` at the toolchain level (gcc specs) (for example
debian [2]). One could also pass the `--as-needed` flag manually but
libtool reorganize flags in the case of shared object creation [3].

In our case, we normally explicitly state the dependencies via the *_LIBADD
automake clause. We do not rely on the LIBS variable.

For the current tree, when the configure script is run, the LIBS
variable has the following value:

 LIBS='-lnuma -lurcu-bp -lurcu-bp -lurcu-cds -lpthread '

The current configure.ac does define what seems to be `empty but
defined` clause for the `action-if-found` as "[]". This is not a valid
"empty but defined" `action-if-find` clause and end up generating the
default behavior as defined in [1]. "[ ]" would be but is supposedly not
the case for all autoconf version.

This leads to unnecessary dependencies for most of the shared objects, at
link time, generated when using a distro that do not enforce the
`--as-needed` flag on linking.

Solution
========

Define an actual no-op shell operation `:` for the `action-if-found`
parameter.

For libnuma define HAVE_LIBNUMA manually. This prevent the prepending to
LIBS while providing the HAVE_LIB* default behavior.

Known drawbacks
=========

None.

References
==========
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Libraries.html
[2] https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/gcc-as-needed.diff
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I8fbb41eb85a98800902fbd23bfbea3ed41faaf26

diff --git a/configure.ac b/configure.ac
index 9fde055e30656a6b3d07f4c40d9a02bb56b3cb8a..c9a963afdeab9af6c3c0f109ef9d609fbcb0ca7f 100644 (file)
--- a/configure.ac
+++ b/configure.ac
@@ -228,7 +228,7 @@ AC_CHECK_LIB([$libdl_name], [dlmopen],
        [AC_DEFINE([HAVE_DLMOPEN], [1])]
 )
 
-AC_CHECK_LIB([pthread], [pthread_create])
+AC_CHECK_LIB([pthread], [pthread_create], [:])
 AC_CHECK_LIB([pthread], [pthread_setname_np],
        AC_DEFINE([HAVE_PTHREAD_SETNAME_NP], [1], [Define to 1 if pthread_setname_np is available.]),
        AC_CHECK_LIB([pthread], [pthread_set_name_np],
@@ -256,7 +256,7 @@ This error can also occur when the liburcu package's configure script has not be
 
 # urcu-cds - check that URCU Concurrent Data Structure lib is available to compilation
 # Part of Userspace RCU library 0.7.2 or better.
-AC_CHECK_LIB([urcu-cds], [_cds_lfht_new], [], [AC_MSG_ERROR([Cannot find
+AC_CHECK_LIB([urcu-cds], [_cds_lfht_new], [:], [AC_MSG_ERROR([Cannot find
 liburcu-cds lib, part of Userspace RCU 0.7 or better. Use [LDFLAGS]=-Ldir to specify its location.])])
 
 AC_MSG_CHECKING([caa_likely()])
@@ -275,10 +275,10 @@ AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
 ])
 
 # urcu - check that URCU lib is available to compilation
-AC_CHECK_LIB([urcu-bp], [urcu_bp_synchronize_rcu], [], [AC_MSG_ERROR([Cannot find liburcu-bp 0.11 or newer. Use [LDFLAGS]=-Ldir to specify its location.])])
+AC_CHECK_LIB([urcu-bp], [urcu_bp_synchronize_rcu], [:], [AC_MSG_ERROR([Cannot find liburcu-bp 0.11 or newer. Use [LDFLAGS]=-Ldir to specify its location.])])
 
 # urcu - check that URCU lib is at least version 0.11
-AC_CHECK_LIB([urcu-bp], [urcu_bp_call_rcu], [], [AC_MSG_ERROR([liburcu 0.11 or newer is needed, please update your version or use [LDFLAGS]=-Ldir to specify the right location.])])
+AC_CHECK_LIB([urcu-bp], [urcu_bp_call_rcu], [:], [AC_MSG_ERROR([liburcu 0.11 or newer is needed, please update your version or use [LDFLAGS]=-Ldir to specify the right location.])])
 
 # numa.h integration
 AS_IF([test "x$NO_NUMA" = "x1"],[
@@ -295,7 +295,7 @@ AS_HELP_STRING([--disable-numa], [disable NUMA support])
 
 AS_IF([test "x$enable_numa" = "xyes"], [
        # numa - check that numa lib is available
-       AC_CHECK_LIB([numa], [numa_available], [],
+       AC_CHECK_LIB([numa], [numa_available], [AC_DEFINE([HAVE_LIBNUMA], [1], [Define to 1 if libnuma is available.])],
 [AC_MSG_ERROR([libnuma is not available. Please either install it (e.g. libnuma-dev) or use [LDFLAGS]=-Ldir to specify the right location, or use --disable-numa configure argument to disable NUMA support.])])
        have_libnuma=yes
 ])