为什么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 ++)

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

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

据我所知,它基于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

救命.:)

UPDATE

当我在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_

尤金建议尝试设置$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

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

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

编辑：好吧，我想读错了，以为它没有链接，但你是说它链接但不运行？

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

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

export LD_LIBRARY_PATH="/path to freshly built libs"