我的lib_LTLIBRARIES庫鏈接，但check_LTLIBRARIES不是？

我有一個新的c + +項目建立autoconf，automake和libtool。功能分爲支持庫和用戶二進制文件。還有一組unittests二進制文件鏈接到這些庫，它們都是在make check時間構建和運行的，但未安裝。我的lib_LTLIBRARIES庫鏈接，但check_LTLIBRARIES不是？

我說這個項目是新的。實際上，我現在正在考慮提取應該安裝的第一個庫。直到現在，（少量）書面代碼直接編譯到unittests。

我試圖Makefile.am片段看起來是這樣的：

lib_LTLIBRARIES += libfoo.la 
libfoo_la_SOURCES = foo.cc

在make check，我得到這個：

/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

通知失蹤庫恰恰是一個我試圖編譯。

（庫不是libfoo，但是我能夠重現同樣的錯誤與此存根庫。上述Makefile.am和錯誤行文字和未經編輯。）

如果我改變的automake線

check_LTLIBRARIES += libfoo.la 
libfoo_la_SOURCES = foo.cc

然後編譯如下：

/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")

..和一切工作正常（除未安裝我的圖書館，在check_是）

請注意，在命令行唯一的區別是：第二個一些額外的參數：

... -Wl，-rpath在/ usr/local/lib目錄-o libfoo.la -rpath在/ usr/local/lib目錄 foo.lo -lboost_thread-MT ...

我不知道隨便，如果此說法不應該存在，但它似乎是造成問題的原因。有誰知道我錯過了什麼？

更多的細節：

在OSX獅子，這工作正常（和命令行是不同的。）在的Ubuntu 12.04，可能還有其他Linux版本此錯誤表現。
noinst_LTLIBRARIES和EXTRA_LTLIBRARIES工作像check_LTLIBRARIES：沒有額外的參數，它鏈接。看來libtool'便利'庫是專門沒有這些論點的。
automake的1.11.1
的autoconf 2.68
libtool的2.4

EDIT

（手動）滴從參數-Wl,-rpath /usr/local/lib也解決了這個問題。

來源

2012-06-23 phs

我對自己做過。在引入autoconf對boost的支持時，我遇到了一個描述爲here的錯誤。我的工作，跟着周圍的一個職位的建議：

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

這裏介紹的-rpath是同一個顯然是導致該問題。如果我恢復這個變化，問題就會消失（我當然會留下第一個問題，但那是另一回事）。

來源

2012-06-23 09:06:29 phs

我的lib_LTLIBRARIES庫鏈接，但check_LTLIBRARIES不是？

回答

相關問題