Warum sollte das autoconf/automake-Projekt mit der installierten Bibliothek verknüpft werden, anstatt mit der lokalen Entwicklungsbibliothek?

Question

Ich erstelle eine Bibliothek libgdata die einige Tests und nicht installierte Programme enthält. Ich habe das Problem, dass, sobald ich die Bibliothek einmal installiert habe, die Programme anscheinend mit der installierten Version verknüpft werden und nicht mit der lokalen Version in ../src/libgdata.la nicht mehr.

Was könnte die Ursache dafür sein? Mache ich etwas schrecklich falsch?

Hier ist mein test/Makefile.am parece:

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 ist eine weitere Bibliothek, die einige Hilfsprogramme für den Umgang mit libcurl und libxml++ enthält)

Wenn ich zum Beispiel die Tests durchführe, ohne etwas installiert zu haben, funktioniert alles einwandfrei. Ich kann lokal Änderungen vornehmen, und diese werden von diesen Programmen sofort übernommen.

Wenn ich das Paket installiere, werden diese Programme kompiliert (es scheint, dass es tatsächlich lokal nach den Headern sucht), aber sobald ich das Programm ausführe, beschwert es sich über fehlende Symbole.

Soweit ich sagen kann, ist es Verknüpfung gegen die neu erstellte Bibliothek (../src/libgdata.la) basierend auf die make-Ausgabe, so dass ich nicht sicher bin, warum dies geschehen würde. Wenn ich die installierten Dateien entferne, werden die lokalen Änderungen an src/* problemlos übernommen.

Ich habe die make-Ausgabe für gdatacalendar unten eingefügt.

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

Hilfe. :)

UPDATE

Ich erhalte die folgenden Meldungen, wenn ich versuche, das Kalenderprogramm auszuführen, nachdem ich die addCommonRequestHeader() Methode in die Service-Klasse, nachdem ich die Bibliothek ohne die addCommonRequestHeader() Methode.

/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's Vorschlag, die Einstellung der $LD_LIBRARY_PATH Variable hat nicht geholfen.

UPDATE 2

Ich habe zwei Tests durchgeführt. Erstens habe ich dies getan, nachdem ich mein dev-install-Verzeichnis weggeblasen hatte (--prefix), und in diesem Fall wurde test/.libs/lt-gdatacalendar . Sobald ich die Bibliothek installiert habe, erstellt sie jedoch test/.libs/gdatacalendar stattdessen. Die Ausgabe von ldd ist für beide gleich, mit einer Ausnahme:

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

Was würde dazu führen, dass in einem Fall lt-gdatacalendar und in einem anderen Fall gdatacalendar erstellt wird?

Die Ausgabe von ldd für libgdata lautet:

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)