Warum sollte autoconf/automake Projekt Link anstelle der lokalen Entwicklungsbibliothek gegen installierte Bibliothek?

Question

Ich erstelle eine Bibliothek libgdata, die einige Tests und nicht installierte Programme hat. Ich stoße auf das Problem, dass, sobald ich die Bibliothek einmal installiert habe, die Programme scheinen, mit der installierten Version und nicht der lokalen Version in ../src/libgdata.la länger zu verbinden.

Was könnte das verursachen? Mache ich etwas schrecklich falsch?

Hier ist, was meine test/Makefile.am wie folgt aussieht:

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 eine andere Bibliothek, die für den Umgang mit libcurl und libxml ++ einige Helfer Sachen hat)

So zum Beispiel, wenn ich die Tests laufen ohne etwas installiert zu haben, funktioniert alles gut. Ich kann Änderungen lokal vornehmen und sie werden sofort von diesen Programmen abgeholt.

Wenn ich das Paket installiere, werden diese Programme kompilieren (es sieht so aus, als ob es tatsächlich lokal nach den Headern sucht), aber sobald ich das Programm starte, beschwert es sich über fehlende Symbole.

Soweit ich das beurteilen kann, ist es eine Verknüpfung mit der neu erstellten Bibliothek (../src/libgdata.la) basierend auf der make-Ausgabe, also bin ich mir nicht sicher, warum das passieren würde. Wenn ich die installierten Dateien entferne, werden die lokalen Änderungen an src/* gut aufgenommen.

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

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 Kalender-Programm zu laufen, wenn ich die addCommonRequestHeader() Methode, um die Service-Klasse hinzugefügt habe, nachdem ich die Bibliothek ohne die addCommonRequestHeader() Methode installiert hatte.

/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 Vorschlag Einstellung zu versuchen, die $LD_LIBRARY_PATH Variable nicht helfen.

UPDATE 2

habe ich zwei Tests. Zuerst habe ich das getan, nachdem ich mein dev-install-Verzeichnis (-Prefix) weggeblasen habe und in diesem Fall test/.libs/lt-gdatacalendar erstellt habe. Sobald ich die Bibliothek installiert habe, wird stattdessen test/.libs/gdatacalendar erstellt. 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, dies lt-gdatacalendar in einem Fall aber gdatacalendar in einer anderen zu schaffen?

Die Ausgabe von ldd auf libgdata ist: erste

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

nicht sicher, wie das in autoconf zu tun, aber letzte Befehl könnte -L ../ src haben müssen, so können Linker neu gebaute Bibliothek finden .

Versuchen Sie manuell, letzten Befehl mit diesem Zusatz auszuführen und sehen, ob das hilft.

EDIT: Ok, ich denke, es falsch gelesen, dachte, es war nicht Verknüpfung, aber Sie sagen, dass es Links, aber nicht läuft?

Wenn dies der Fall ist, führen Sie LDD auf Ihrer Binärdatei und sehen, welche .so es abgreift - höchstwahrscheinlich installiert (und veraltet).

In diesem Fall installieren Sie entweder aktualisierte Bibliotheken vor dem Ausführen, oder exportieren Sie die Variable LD_LIBRARY_PATH env, bevor Sie ausgeführt werden.

export LD_LIBRARY_PATH="/path to freshly built libs" 

Answer 2

Ich weiß, dass für Abhängigkeiten richtig arbeiten zu können, in LDADD-libgdata.la mit einem relativen Pfad verweisen müssen; Es ist möglich, dass sich dies auch auf die Situation auswirkt, die Sie beschreiben.

Ich bin nicht sicher warum, obwohl. Das Verhalten, das Sie beschreiben, wirkt ein bisschen merkwürdig; und vielleicht einen Bericht an die libtool-Entwickler wert.

Answer 3

Ich denke, ich habe das aussortiert.

Das Problem sollte sein, dass libtool das Flag "-L" in der Befehlszeile sieht, bevor es den "../src/libgdata.so" Teil sieht. In diesem Fall führt es den Linker mit "-Wl, -rpath, ..." für diesen "-L" Pfad aus. Wenn dieser Pfad "libgdata.so" enthält, wird er immer verwendet, was hier der Fall ist.

In meinem Fall habe ich "prog_LDADD" neu angeordnet, wie dies zu mögen: "prog_LDADD = $ (top_builddir) /src/my_lib.so $ (DEPENDENCY_LIBS)" In Ihrem Fall

, versuchen zu löschen AM_LDFLAGS und schreiben:

LDADD = $ (top_builddir) /src/libgdata.la $ (APIUTIL_LIBS)

Answer 4

Ohne -no-installieren libtool erstellt Skript-Wrapper und setzt die ausführbaren Dateien in das .libs/subdir (verknüpft mit die installierten Bibliotheken). Durch das Aufrufen des Wrappers wird Ihre ausführbare Datei mit Ihrer lokalen (nicht installierten) Bibliothek geladen/verlinkt - damit alles funktioniert, z. make check testet nicht die installierte aber Ihre frisch gebackene Bibliothek.

In einigen Fällen (z. B. beim Debuggen oder Valgrinding) möchten Sie diese Wrapper nicht haben, sondern echte ausführbare Dateien, die direkt mit Ihrer lokalen Bibliothek verknüpft sind. Dazu verwenden Sie AM_LDFLAGS = -no-install (oder setzen Sie es einfach für einzelne Ziele).

Mehr Details here