libtool不提供庫鏈接鏈接

Question

我在ubuntu lucid上使用libtool 2.2.6b，在ubuntu上使用libtool 2.4.2精確。在清晰的我的項目將正確鏈接。在精確它無法鏈接。下面是示例代碼，演示了我的問題;

configure.ac

AC_INIT([ltp], [0.0.1], [someone]) 
AM_INIT_AUTOMAKE 
AC_CONFIG_HEADERS([config.h]) 
AC_CONFIG_MACRO_DIR([.m4]) 
AC_CONFIG_FILES([Makefile foo/Makefile bar/Makefile wah/Makefile]) 
AC_PROG_CXX 
AC_PROG_LIBTOOL 
AM_SANITY_CHECK 
AC_LANG_CPLUSPLUS 
AC_OUTPUT 

Makefile.am

SUBDIRS = foo bar wah 
ACLOCAL_AMFLAGS = -I .m4 

富/ foo.h中

#ifndef FOO_FOO_H_ 
#define FOO_FOO_H_ 
namespace Foo 
{ 
    class Foo 
    { 
    public: 
    Foo(long l); 
    private: 
    long l; 
    }; 
} 
#endif 

富/ Foo.cpp中

#include "foo/Foo.h" 
namespace Foo 
{ 
    Foo::Foo(long l) : l(l) {} 
} 

富/ Makefile.am

lib_LTLIBRARIES = libfoo.la 
libfoo_la_SOURCES = Foo.cpp 
libfoo_la_CPPFLAGS = 
libfoo_la_LDFLAGS = -release 0.0.1 
libfoo_la_LIBADD = 

酒吧/ Bar.h

#ifndef BAR_BAR_H_ 
#define BAR_BAR_H_ 
#include "foo/Foo.h" 
namespace Bar 
{ 
    class Bar 
    { 
    public: 
    Bar(const Foo::Foo & f); 
    private: 
    Foo::Foo f; 
    }; 
} 
#endif 

酒吧/ Bar.cpp

#include "bar/Bar.h" 
namespace Bar 
{ 
    Bar::Bar(const Foo::Foo & f) : f(f) { } 
} 

酒吧/ Makefile.am

lib_LTLIBRARIES = libbar.la 
libbar_la_SOURCES = Bar.cpp 
libbar_la_CPPFLAGS = 
libbar_la_LDFLAGS = -release 0.0.1 
libbar_la_LIBADD = -L../foo -lfoo 

wah/main.cpp

#include "bar/Bar.h" 
int main(int argc, char * argv[]) 
{ 
    Bar::Bar(5); 
    return 0; 
} 

華/ Makefile.am

bin_PROGRAMS = wah 
wah_SOURCES = main.cpp 
wah_CPPFLAGS = 
wah_LDADD = -L../bar -lbar 

在清醒，華環節，對精確，它失敗：

wah/main.cpp:5 undefined reference to `Foo::Foo::Foo(long)' 

我可以通過添加-L../foo -lfoo到wah_LDADD解決這個問題，但真正，是不是libtool應該爲我自動做到這一點？關於「鏈接可執行文件」的libtool手冊部分似乎表明，它正是它應該做的。

Answer 1

在我用於開發的任何Debian機器上，我必須手動編譯和安裝Libtool，因爲Debian提供的版本已修補並忽略了依賴性，從而破壞了我的構建。

如果Ubuntu的版本類似，您可能也想安裝Libtool from source。

Answer 2

適用於Ubuntu 12.04（精準穿山甲）32位，libtool 2.4.2。

我確實有幾分正確地改變你的Makefile來make dist（更多）：

富/ Makefile.am：

lib_LTLIBRARIES = libfoo.la 
libfoo_la_SOURCES = Foo.cpp Foo.h 
libfoo_la_CPPFLAGS = 
libfoo_la_LDFLAGS = -release 0.0.1 
libfoo_la_LIBADD = 

酒吧/ Makefile.am：

lib_LTLIBRARIES = libbar.la 
libbar_la_SOURCES = Bar.cpp Bar.h 
libbar_la_CPPFLAGS = 
libbar_la_LDFLAGS = -release 0.0.1 
libbar_la_LIBADD = -L../foo -lfoo 

華/ Makefile文件。我

bin_PROGRAMS = wah 
wah_SOURCES = main.cpp ../bar/Bar.h 
wah_CPPFLAGS = 
wah_LDADD = -L../bar -lbar 

下面是它的鏈接main.cpp：

make[2]: Entering directory `/xxx/ltp-0.0.1/wah' 
g++ -DHAVE_CONFIG_H -I. -I..  -g -O2 -MT wah-main.o -MD -MP -MF .deps/wah-main.Tpo -c -o wah-main.o `test -f 'main.cpp' || echo './'`main.cpp 
mv -f .deps/wah-main.Tpo .deps/wah-main.Po 
/bin/bash ../libtool --tag=CXX --mode=link g++ -g -O2 -o wah wah-main.o -L../bar -lbar 
libtool: link: g++ -g -O2 -o .libs/wah wah-main.o -L../bar /xxx/ltp-0.0.1/bar/.libs/libbar.so -L../foo /xxx/ltp-0.0.1/foo/.libs/libfoo.so 

不libtool的應該爲我做自動的？

是的，至少在非Ubuntu發行版上創建分發tarball時是這樣。在Ubuntu盒子上進行autoreconf後，我會遇到同樣的錯誤。 顯然（根據ADL）Ubuntu的發行具有libtool一個補丁版本，其設置libtool的腳本變量：

link_all_deplibs=no 

我修補的configure產生libtool的腳本，以取代所有這些實例：

link_all_deplibs=unknown 

和一切按預期鏈接。我想你可以在調用autoreconf的腳本中做同樣的事情。或者在Ubuntu主機上安裝libtool的未修補版本。或者在Ubuntu主機上修補修補過的libtool。所以有幾個選項可以解決這個問題。

Answer 3

我想你可以說這是在理念更多的差別。 Debian的變化點是爲了鼓勵用戶要明確告知他們依賴於什麼，這reduces the amount of unnecessary churn when dependencies deep down the tree get upgraded。

當link_all_deplibs=yes（未修改libtool的），如果你的程序wah取決於bar和bar取決於foo，則暗示是wah取決於foo爲好。

當link_all_deplibs=no（Debian的修改libtool的），如果你的程序wah取決於bar和bar取決於foo，那麼它是不是暗示是wah取決於foo爲好。

所以，服用Debian的角度看，這是你的程序假：wah確實取決於foo憑藉這一行：

Bar::Bar(5); 

在這裏，你是隱式調用的Foo::Foo構造。至於C++編譯器而言，你的程序看起來更像：

Bar::Bar(Foo::Foo(5)); 

因此，wah取決於foo不只是間接的，但直接。因此，從Debian的角度來看，你是應該明確通過-lfoo鏈接到foo。

特別是，這是而不是與libtool的示例Linking Executables相同的情況。在該示例中，main.o沒有明確依賴於libm，因此-lm原則上在連接main.o（main.c不直接呼叫cos）時應該是不必要的。也許libtool鏈接遞歸的原因是爲了解決鏈接器無法處理間接依賴關係的舊系統？