Perché il collegamento di un progetto di autoconf/automake alla libreria installata non è la libreria di sviluppo locale?

Question

Sto creando una libreria libgdata con alcuni test e programmi non installati. Sto incontrando il problema che una volta che ho installato la libreria una volta, i programmi sembrano collegarsi alla versione installata e non alla versione locale in ../src/libgdata.la.

Cosa potrebbe causare questo? Sto facendo qualcosa di terribilmente sbagliato?

Ecco ciò che il mio test/Makefile.am assomiglia:

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 è un'altra libreria che ha alcune cose aiuto per trattare con libcurl e libxml ++)

Così, per esempio, se si esegue il test senza aver installato nulla, tutto funziona bene. Posso apportare modifiche localmente e vengono raccolte da questi programmi subito.

Se installo il pacchetto, questi programmi verranno compilati (sembra che in effetti appaia localmente per le intestazioni), ma una volta eseguito il programma si lamenta dei simboli mancanti.

Per quanto posso dire, è collegato alla libreria di nuova costruzione (../src/libgdata.la) in base all'output del make, quindi non sono sicuro del motivo per cui ciò avverrebbe. Se rimuovo i file installati, le modifiche locali a src/* vengono rilevate correttamente.

Ho incluso il risultato di produzione per gdatacalendar qui sotto.

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 

Help. :)

UPDATE

Ottengo i seguenti messaggi quando si tenta di eseguire il programma di calendario quando ho aggiunto il metodo addCommonRequestHeader() alla classe di servizio dopo aver installato la libreria senza il metodo 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_ 

suggerimento di Eugene a provare a impostare la variabile $LD_LIBRARY_PATH non ha aiutato.

UPDATE 2

ho fatto due prove. Per prima cosa, l'ho fatto dopo aver spazzato via la mia directory dev-install (--prefix) e in quel caso, crea test/.libs/lt-gdatacalendar. Una volta installata la libreria, invece, crea test/.libs/gdatacalendar. L'uscita del LDD è la stessa per entrambi con una sola eccezione:

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

cosa potrebbe causare questo creare lt-gdatacalendar in un caso ma gdatacalendar in un'altra?

L'uscita del ldd su 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) 

Answer 1

Non so come fare a autoconf, ma comando finale potrebbe essere necessario avere -L ../ src, quindi linker può trovare la libreria di nuova costruzione primo .

Provare manualmente a eseguire l'ultimo comando con quell'aggiunta e vedere se questo aiuta.

EDIT: Ok, immagino di averlo letto male, ho pensato che non fosse un collegamento, ma lo stai dicendo link ma non funziona?

In questo caso, esegui ldd sul tuo file binario e vedi quale .so preleva - molto probabilmente installati (e obsoleti).

In questo caso, installare le librerie aggiornate prima dell'esecuzione oppure esportare la variabile env LD_LIBRARY_PATH prima dell'esecuzione.

export LD_LIBRARY_PATH="/path to freshly built libs" 

Answer 2

So che per le dipendenze per funzionare correttamente, è necessario fare riferimento a libgdata.la con un percorso relativo a LDADD; è possibile che influenzi anche la situazione che stai descrivendo.

Non so perché, però. Il comportamento che stai descrivendo sembra un po 'strano; e forse vale la pena di riferire agli sviluppatori di libtool.

Answer 3

Penso di averlo risolto.

Il problema dovrebbe essere che libtool vede il flag "-L" nella riga di comando prima di vedere la parte "../src/libgdata.so". In questo caso, esegue il linker con "-Wl, -rpath, ..." per quel percorso "-L". Se quel percorso contiene "libgdata.so", sarà sempre usato, come nel caso qui.

Nel mio caso, ho riordinato "prog_LDADD" di come in questo modo: "prog_LDADD = $ (top_builddir) /src/my_lib.so $ (DEPENDENCY_LIBS)"

Nel tuo caso, tenta di eliminare AM_LDFLAGS e scrivere:

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

Answer 4

Senza -no-installare libtool crea wrapper script e mette gli eseguibili nella .libs/subdir (collegato con il installato librerie). La chiamata al wrapper rende il tuo eseguibile carico/link con la tua libreria locale (non installata), quindi tutto funziona correttamente, ad es. make check non esegue il test della libreria installata, ma quella appena preparata.

In alcuni casi (ad es. Durante il debug o il valgrinding), non si desidera avere quei wrapper, ma veri eseguibili direttamente collegati con la libreria locale. Per questo si utilizza AM_LDFLAGS = -no-install (o semplicemente impostato per obiettivi singoli).

Maggiori dettagli here