My lib_LTLIBRARIES library links, but check_LTLIBRARIES one does not? - linux

Question

I have a new c++ project built with autoconf, automake and libtool. Functionality is divided up into support libraries and user binaries. There is also a set of unittests binaries which link against these libraries, are built and run at make check time, but are not installed.
I said the the project is new. I'm actually just now getting around to extracting the first library that should be installed. Until now the (small amount of) written code was just compiled directly into a unittests.
My attempted Makefile.am snippet looks like this:
lib_LTLIBRARIES += libfoo.la
libfoo_la_SOURCES = foo.cc
In make check, I get this:
/bin/bash ./libtool --tag=CXX --mode=link g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -L/usr/local/lib -Wl,-rpath /usr/local/lib -o libfoo.la -rpath /usr/local/lib foo.lo -lboost_thread-mt -lboost_system-mt -pthread
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtbeginS.o .libs/foo.o -L/usr/local/lib -lboost_thread-mt -lboost_system-mt -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crtn.o -fprofile-arcs -O0 -fprofile-arcs -Wl,-rpath -pthread -pthread -Wl,-soname -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
/usr/bin/ld: cannot find libfoo.so.0: No such file or directory
collect2: ld returned 1 exit status
Notice the missing library is precisely the one I'm trying to compile.
(The library is not libfoo, but I am able to reproduce the same error with this stub library. The Makefile.am and error lines above are literal and unedited.)
If I change the automake lines to
check_LTLIBRARIES += libfoo.la
libfoo_la_SOURCES = foo.cc
then the compile looks like this:
/bin/bash ./libtool --tag=CXX --mode=link g++ -Wall -Wextra -Werror -ansi -fprofile-arcs -ftest-coverage -g -O0 -fprofile-arcs -ftest-coverage -L/usr/local/lib -Wl,-rpath /usr/local/lib -o libfoo.la foo.lo -lboost_thread-mt -lboost_system-mt -pthread
libtool: link: ar cru .libs/libfoo.a .libs/foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && cp -p "../libfoo.la" "libfoo.la" )
..and everything works fine (except my library isn't installed, being in check_.)
Notice the only difference in the command lines is some additional arguments in the 2nd one:
... -Wl,-rpath /usr/local/lib -o libfoo.la -rpath /usr/local/lib foo.lo -lboost_thread-mt ...
I don't know offhand if this new argument shouldn't be there, but it does appear to be causing the problem. Does anyone know what I'm missing?
Some more details:
On osx lion, this works fine (and the command lines are different.) This error manifests on
ubuntu 12.04, possibly other linuxes.
noinst_LTLIBRARIES and EXTRA_LTLIBRARIES work like check_LTLIBRARIES: no extra arguments, and it links. It seems libtool 'convenience' libraries are specifically the ones without these arguments.
automake 1.11.1
autoconf 2.68
libtool 2.4
EDIT
(Manually) dropping -Wl,-rpath /usr/local/lib from the arguments also fixes the problem.

Answer 1

I did it to myself. While bringing in autoconf support for boost, I encountered a bug described here. My work-around followed the suggestion of one post:
diff --git a/m4/boost.m4 b/m4/boost.m4
index 3d4e47c..9dd0c43 100644
--- a/m4/boost.m4
+++ b/m4/boost.m4
## -403,7 +403,7 ## dnl generated only once above (before we start the for loops).
LDFLAGS=$boost_save_LDFLAGS
LIBS=$boost_save_LIBS
if test x"$Boost_lib" = xyes; then
- Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-R$boost_ldpath"
+ Boost_lib_LDFLAGS="-L$boost_ldpath -Wl,-rpath $boost_ldpath"
Boost_lib_LDPATH="$boost_ldpath"
break 6
else
The -rpath introduced here is the same one apparently causing the issue. If I revert this change, the problem goes away (I am of course left with the first issue, but that's another story.)