¿Por qué el enlace del proyecto autoconf/automake contra la biblioteca instalada en lugar de la biblioteca de desarrollo local?

Question

Estoy creando una biblioteca libgdata que tiene algunas pruebas y programas no instalados. Me encuentro con el problema de que una vez que haya instalado la biblioteca una vez, los programas parecen estar enlazando a la versión instalada y no a la versión local en ../src/libgdata.la.

¿Qué podría causar esto? ¿Estoy haciendo algo horriblemente mal?

Aquí es lo que mi 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 es otra biblioteca que tiene un poco de materia de ayuda para hacer frente a libcurl y libxml ++)

Así, por ejemplo, si se me acaban las pruebas sin haber instalado nada, todo funciona bien. Puedo hacer cambios localmente y estos programas los recogen de inmediato.

Si instalo el paquete, estos programas compilarán (parece que realmente se ve localmente para los encabezados), pero una vez que ejecuto el programa, se queja de los símbolos faltantes.

Por lo que puedo decir, está vinculándose con la biblioteca recién creada (../src/libgdata.la) en función de la salida de producción, por lo que no estoy seguro de por qué esto estaría sucediendo. Si elimino los archivos instalados, los cambios locales a src/* se recogen muy bien.

He incluido la salida make para gdatacalendar a continuación.

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 

Ayuda. :)

ACTUALIZACIÓN

consigo los siguientes mensajes cuando trato de ejecutar el programa de calendario cuando he añadido el método addCommonRequestHeader() a la clase de servicio después de haber instalado la biblioteca sin el método 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_ 

sugerencia de Eugene intentar establecer la variable $LD_LIBRARY_PATH no ayudó.

ACTUALIZACIÓN 2

Me hicieron dos pruebas. Primero, hice esto después de volar mi directorio dev-install (--prefix) y en ese caso, crea test/.libs/lt-gdatacalendar. Una vez que he instalado la biblioteca, crea en su lugar test/.libs/gdatacalendar. La salida del LDD es el mismo para ambos, con una excepción:

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

lo que haría esto para crear lt-gdatacalendar en un caso pero gdatacalendar en otro?

La salida de ldd en libgdata es:

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

No está seguro de cómo hacerlo en autoconf, pero comando final puede ser que necesite tener -L ../ src, por lo enlazador puede encontrar la biblioteca de nueva construcción primera .

Trate de ejecutar manualmente el último comando con esa adición y vea si eso ayuda.

EDIT: Ok, supongo que lo leí mal, pensé que no estaba vinculando, ¿pero está diciendo que enlaza pero no se ejecuta?

Si ese es el caso, ejecute ldd en su binario y vea qué .so retoma: lo más probable es que esté instalado (y desactualizado).

En este caso, instale las bibliotecas actualizadas antes de ejecutar o exporte la variable de entorno LD_LIBRARY_PATH antes de ejecutar.

export LD_LIBRARY_PATH="/path to freshly built libs" 

Answer 2

Sé que para dependencias funcionen correctamente, es necesario hacer referencia a libgdata.la con una ruta relativa en LDADD; es posible que también afecte la situación que describes.

No estoy seguro de por qué, sin embargo. El comportamiento que estás describiendo parece un poco extraño; y tal vez valga la pena informar a los desarrolladores de libtool.

Answer 3

Creo que he resuelto esto.

El problema debería ser que libtool ve el indicador "-L" en la línea de comando antes de ver la parte "../src/libgdata.so". En este caso, ejecuta el enlazador con "-Wl, -rpath, ..." para esa ruta "-L". Si esa ruta contiene "libgdata.so", entonces siempre se usará, que es el caso aquí.

En mi caso, he reorganizado "prog_LDADD" para recibir la siguiente manera: "prog_LDADD = $ (top_builddir) /src/my_lib.so $ (DEPENDENCY_LIBS)"

En su caso, intenta eliminar AM_LDFLAGS y escribir:

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

Answer 4

Sin -no-instalar libtool crea envolturas de guión y pone los ejecutables en el .libs/subdirectorio (vinculado con las instaladas en las bibliotecas). Llamar al contenedor hace que su carga/enlace ejecutable con su biblioteca local (no instalada) - para que todo funcione bien, p. make check no prueba la biblioteca instalada sino la biblioteca recién horneada.

En algunos casos (por ejemplo, al depurar o valorar), no desea tener esas envolturas, sino ejecutables reales directamente vinculados con su biblioteca local. Para esto, usa AM_LDFLAGS = -no-install (o simplemente configúrelo para objetivos únicos).

Más detalles here