私はいくつかのテストとインストールされていないプログラムを持っているライブラリlibgdataを作成しています。私は一度ライブラリーをインストールしてしまえば、プログラムはインストールされているバージョンにリンクされているように見えますが、ローカルバージョンではなく、../src/libgdata.laにリンクしているようです。なぜautoconf/automakeプロジェクトは、ローカル開発ライブラリの代わりにインストールされたライブラリとリンクしますか？
この原因は何ですか？恐ろしいことをしていますか？私がテストを実行する場合、例えば、そう
（libapiutilはlibcurlのとのlibxml ++に対処するためのいくつかのヘルパーのものを持っている別のライブラリである）
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
：ここ
は私test/Makefile.amは、次のようになります何もインストールせずに、すべて正常に動作します。私はローカルで変更を加えることができ、すぐにこれらのプログラムによって取得されます。
パッケージをインストールした場合、これらのプログラムはコンパイルされます（実際にはヘッダーがローカルにあるようです）が、プログラムを実行するとシンボルの欠落があると文句を言います。
私の知る限り、これは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()メソッドを追加したカレンダープログラムを実行しようとすると、私は次のメッセージを取得します。
/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変数を設定しようとするユージンの提案。
UPDATE 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)
、これは別の1つのケースが、gdatacalendarには、LT-gdatacalendarを作成する原因となりますか？
libgdataにLDDの出力は次のとおりです。
[email protected]:~/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)
あなたも、このLT-プレフィックスが実際に何で、LDDのLT-gdatacalendar – Eugene
そしてすべてのあなたのlibs – Eugene
フムにLDDの出力の出力をポストてもらえますか？ – Eugene