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

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++ 的辅助工具)

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

如果我安装包，这些程序将编译(看起来它实际上确实在本地查找 header )，但是一旦我运行该程序，它就会提示缺少符号。

据我所知，它基于 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( ) 方法。

/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 的输出对于两者都是相同的，但有一个异常(exception):

# 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？

ldd 在 libgdata 上的输出是:

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”标志。在这种情况下，它使用“-Wl,-rpath,...”为那个“-L”路径执行链接器。如果该路径包含“libgdata.so”，则将始终使用它，这里就是这种情况。

就我而言，我已将“prog_LDADD”重新排列为如下所示: "prog_LDADD = $(top_builddir)/src/my_lib.so $(DEPENDENCY_LIBS)"

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

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