Question

我正在创建一个包含一些测试和未安装程序的库libgdata。我遇到的问题是，一旦我安装了一次库，程序似乎就会链接到已安装的版本，而不再是../src/libgdata.la中的本地版本。

是什么导致这个？我做了一件可怕的错事吗？

以下是我test/Makefile.am的样子：

INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/test/

# libapiutil contains all of our dependencies!
AM_CXXFLAGS = $(APIUTIL_CFLAGS)
AM_LDFLAGS = $(APIUTIL_LIBS)

LDADD = $(top_builddir)/src/libgdata.la

noinst_PROGRAMS = gdatacalendar gdatayoutube

gdatacalendar_SOURCES = gdatacalendar.cc

gdatayoutube_SOURCES = gdatayoutube.cc

TESTS = check_bare

check_PROGRAMS = $(TESTS)

check_bare_SOURCES = check_bare.cc

（libapiutil是另一个库，它有一些帮助程序来处理libcurl和libxml ++）

因此，例如，如果我在没有安装任何东西的情况下运行测试，一切正常。我可以在本地进行更改，并立即通过这些程序获取。

如果我安装了这个程序包，这些程序就会被编译（看起来它实际上看起来本身就是标题），但是一旦我运行该程序就会抱怨缺少符号。

据我所知，它基于make输出链接到新构建的库（../src/libgdata.la），所以我不确定为什么会发生这种情况。如果我删除已安装的文件，那么对src / *的本地更改就可以了。

我在下面列出了gdatacalendar的make输出。

g++ -DHAVE_CONFIG_H -I. -I.. -I../src/ -I../test/   -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -g -O2 -MT gdatacalendar.o -MD -MP -MF .deps/gdatacalendar.Tpo -c -o gdatacalendar.o gdatacalendar.cc
mv -f .deps/gdatacalendar.Tpo .deps/gdatacalendar.Po
/bin/bash ../libtool --tag=CXX   --mode=link g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -g -O2 -L/home/altern8/workspaces/4355/dev-install/lib -lapiutil -lcurl -lgssapi_krb5 -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0    -o gdatacalendar gdatacalendar.o ../src/libgdata.la 
mkdir .libs
g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -o .libs/gdatacalendar gdatacalendar.o  -L/home/altern8/workspaces/4355/dev-install/lib /home/altern8/workspaces/4355/dev-install/lib/libapiutil.so /usr/lib/libcurl.so -lgssapi_krb5 /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so ../src/.libs/libgdata.so  -Wl,--rpath -Wl,/home/altern8/workspaces/4355/dev-install/lib
creating gdatacalendar

帮助。：）

更新

当我在没有使用addCommonRequestHeader()方法安装库之后将addCommonRequestHeader()方法添加到Service类时，尝试运行日历程序时收到以下消息。

/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
symbol lookup error:
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
undefined symbol:
_ZN55gdata7service7Service22addCommonRequestHeaderERKSsS4_

<> Eugene建议尝试设置$LD_LIBRARY_PATH变量没有帮助。

更新2

我做了两次测试。首先，我在删除了我的dev-install目录（--prefix）后执行了此操作，在这种情况下，它创建了test/.libs/lt-gdatacalendar。但是，一旦我安装了库，它就会创建test/.libs/gdatacalendar。 ldd的输出对于两者都是相同的，只有一个例外：

# before install
# ldd test/.libs/lt-gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 (0xb7c32000)

# after install
# ldd test/.libs/gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/dev-install/lib/libgdata.so.0 (0xb7c87000)

什么会导致这个在一个案例中创建lt-gdatacalendar而在另一个案例中创建gdatacalendar？

libgdata上的ldd输出为：

altern8@goldfrapp:~/workspaces/4355/libgdata$ ldd /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0
        linux-gate.so.1 =>  (0xb7f7c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f3b000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)
        /lib/ld-linux.so.2 (0xb7f7d000)

Answer 1

我想我已经对此进行了整理。

问题应该是libtool在看到“../src/libgdata.so”部分之前在命令行中看到“-L”标志。在这种情况下，它为“-L”路径执行带有“-Wl，-rpath，...”的链接器。如果该路径包含“libgdata.so”，那么将始终使用它，这就是这里的情况。

在我的情况下，我重新安排了“prog_LDADD”，就像这样： “prog_LDADD = $（top_builddir）/src/my_lib.so $（DEPENDENCY_LIBS）”

在您的情况下，尝试删除AM_LDFLAGS并写：

LDADD = $（top_builddir）/src/libgdata.la $（APIUTIL_LIBS）

Answer 2

不确定如何在autoconf中执行此操作，但最终命令可能需要-L ../ src，因此链接器可以首先找到新构建的库。

尝试使用该添加手动运行最后一个命令，看看是否有帮助。

编辑：好的，我想误读了它，认为它没有链接，但是你说它是链接但不运行？

如果是这种情况，请在您的二进制文件上运行ldd，看看它选择了哪个。 - 很可能已安装（和过时）。

在这种情况下，要么在运行之前安装更新的libs，要么在运行之前导出LD_LIBRARY_PATH env变量。

export LD_LIBRARY_PATH="/path to freshly built libs"

Answer 3

我知道要使依赖项正常工作，您需要在libgdata.la中使用相对路径引用LDADD;它可能会影响你所描述的情况。

但是，我不确定为什么。你描述的行为似乎有点奇怪;也许值得向libtool开发者报告。

Answer 4

如果没有-no-install，libtool会创建脚本包装器并将可执行文件放入.libs / subdir（与已安装的库链接）。调用包装器使您的本地（未安装）库可执行加载/链接 - 所以一切正常，例如make check不测试已安装但刚刚刷新的库。

在某些情况下（例如，在调试或valgrinding时），您不希望拥有这些包装器，而是直接与本地库链接的实际可执行文件。为此，您使用AM_LDFLAGS = -no-install（或仅将其设置为单个目标）。

更多详情here

为什么autoconf / automake项目会链接到已安装的库而不是本地开发库？

4 个答案: