14

我正在创建一个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()当我在安装没有该方法的库之后将方法添加到 Service 类时，当我尝试运行日历程序时收到以下消息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_

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

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)
4

4 回答 4

2

我想我已经解决了这个问题。

问题应该是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)

于 2010-04-23T10:29:42.770 回答
1

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

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

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

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

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

export LD_LIBRARY_PATH="/path to freshly built libs"
于 2009-07-22T21:27:54.647 回答
1

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

不过，我不确定为什么。您描述的行为确实有点奇怪。也许值得向 libtool 开发人员报告。

于 2009-07-28T09:51:53.590 回答
0

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

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

更多细节在这里

于 2017-01-03T12:20:51.510 回答