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

（libapiutillibcurlと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_

変数の設定を試みるというEugeneの提案$LD_LIBRARY_PATHは役に立ちませんでした。

更新2

私は2つのテストを行いました。まず、dev-installディレクトリ（--prefix）を吹き飛ばした後にこれを行いました。その場合、が作成されますtest/.libs/lt-gdatacalendar。ただし、ライブラリをインストールすると、test/.libs/gdatacalendar代わりにライブラリが作成されます。lddの出力は、1つの例外を除いて、両方で同じです。

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

4 に答える 4

2

これで整理できたと思います。

問題は、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)

于 2010-04-23T10:29:42.770 に答える
1

依存関係が正しく機能するにはlibgdata.la、 を相対パスで参照する必要があることはわかっていLDADDます。あなたが説明している状況にも影響を与える可能性があります。

理由はわかりませんが。あなたが説明している動作は少し奇妙に思えます。おそらく、libtool 開発者に報告する価値があります。

于 2009-07-28T09:51:53.590 に答える
1

autoconf でそれを行う方法がわかりませんが、最後のコマンドに -L../src が必要な場合があるため、リンカーは新しく構築されたライブラリを最初に見つけることができます。

その追加で最後のコマンドを手動で実行してみて、それが役立つかどうかを確認してください。

編集：わかりました、読み間違えたと思います。リンクしていないと思っていましたが、リンクしているが実行されないと言っていますか？

その場合は、バイナリで ldd を実行し、どの .so が検出されるかを確認します。ほとんどの場合、インストールされている (および古い) ものです。

この場合、実行前に更新されたライブラリをインストールするか、実行前に LD_LIBRARY_PATH 環境変数をエクスポートします。

export LD_LIBRARY_PATH="/path to freshly built libs"
于 2009-07-22T21:27:54.647 に答える
0

-no-install libtool を指定しないと、スクリプト ラッパーが作成され、実行可能ファイルが .libs/ サブディレクトリ (インストールされたライブラリにリンク) に配置されます。ラッパーを呼び出すと、実行可能ファイルがローカル (インストールされていない) ライブラリにロード/リンクされるため、すべて正常に動作します。たとえばmake check、インストール済みのライブラリはテストされませんが、焼きたてのライブラリはテストされません。

場合によっては (デバッグ時や valgrind 時など)、これらのラッパーを使用せずに、実際の実行可能ファイルをローカル ライブラリに直接リンクしたい場合があります。これには、使用しますAM_LDFLAGS = -no-install（または、単一のターゲットに設定します）。

詳細はこちら

于 2017-01-03T12:20:51.510 に答える