Construyendo el módulo .so con autotools/libtool sin las variantes .la y .a instaladas

Question

Cómo compilar e instalar un módulo .so con autotools/libtool sin tener las bibliotecas .la y .a instaladas también en --prefix path?

Actualmente estoy usando Makefile.am siguiente:

lib_LTLIBRARIES = libCurlDownloader.la 
libCurlDownloader_la_SOURCES = Curl.cpp 
libCurlDownloader_la_LDFLAGS = -module -avoid-version 

Funciona, pero además de libCurlDownloader.so también instala libCurlDownloader.la y libCurlDownloader.a, lo que es indeseable.

Actualización # 1

Es posible hacer .a no ser generados, ya sea mediante el uso de

./configure --disable-static 

o

AC_ENABLE_SHARED(yes) 
AC_ENABLE_STATIC(no) 

en configure.ac

Pero todavía es la pregunta de cómo hacer .la no b eing instalado en la instalación --prefix al tener .so instalado.

Actualización # 2

Es posible eliminar los archivos .la de la instalación usando --prefix

install-exec-hook: find $(DESTDIR)$(libdir) -type f -name \*.la -delete 

Answer 1

Usted no necesariamente debe eliminar los archivos .la. Los archivos .la contiene información que se utiliza en dos situaciones:

1. estáticamente une en contra de la biblioteca construida. Al vincular estáticamente (es decir, .a con -static), no hay información sobre las dependencias de la biblioteca que se está enlazando, por lo que libtool puede usar la información en el archivo .la para crear un comando ld apropiado que haga referencia a todas las dependencias necesarias. Esto a menudo es más importante en un entorno como MinGW donde el vinculador requiere los mismos múltiplos especificados en la biblioteca en un orden particular para resolver dependencias recursivas. Esto es solo una preocupación si uno tiene la intención de construir un binario estático.

2. dinámicamente cargar la biblioteca Construir sobre algunos plataformas (es decir, con lt_dlopen si se utiliza libltdl). Del mismo modo, en ciertas plataformas, las dependencias del módulo de compilación no están codificadas en el binario, por lo que el archivo .la es necesario para que lt_dlopen encuentre y cargue las dependencias correctas. En plataformas ELF (incluidas Linux) y plataformas PE (es decir, Windows), las dependencias se almacenan en la biblioteca, por lo que lt_dlopen funcionará sin los archivos .la. El formato MachO en MacOS puede requerir archivos .la al compilar paquetes.

Los empaquetadores de Debian/Ubuntu han decidido excluir .la archivos de sus paquetes debido a que la segunda razón no es apropiado en Linux y que preferirían que no construyeron binarios estáticos en el primer lugar. En otras plataformas, que libtool está diseñado para admitir, los archivos .la pueden ser necesarios para vincular o ejecutar el programa.

Answer 2

Me encontré con esta pregunta porque usaba el término "módulo", que en automake/libtool speak es el término para un complemento. Tengo un sistema de complemento en Finit, así que construyo mis complementos con '-module' para evitar crear archivos .a. Pero todavía tengo instalados los archivos .la, que en realidad ni siquiera son aplicables en el caso '-module'.

todavía tengo que encontrar una manera documentada para saltar .la archivos de plugins, pero aquí es cómo lo hago:

AM_LDFLAGS = -module -avoid-version -shared 
pkglib_LTLIBRARIES = alsa-utils.la bootmisc.la 

install-exec-hook: 
     @(cd $(DESTDIR)$(pkglibdir) && $(RM) $(pkglib_LTLIBRARIES)) 

Para que quede claro, en mi caso de uso no hay nadie va a "enlace" contra mi complemento .so, por lo que los archivos .la realmente no sirven de nada.