Creazione di un modulo .so con autotools/libtool senza .la e .a varianti installate

Question

Come creare e installare un modulo .so con autotools/libtool senza librerie .la e .a essere installato anche in --prefix percorso?

Attualmente sto usando seguente Makefile.am:

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

Funziona, ma oltre a libCurlDownloader.so installa anche libCurlDownloader.la e libCurlDownloader.a, ciò che è indesiderabile.

Update # 1

E 'possibile rendere non .a essere generato, utilizzando uno

./configure --disable-static 

o

AC_ENABLE_SHARED(yes) 
AC_ENABLE_STATIC(no) 

in configure.ac

Ma è ancora la domanda su come fare .la non b eing installato nell'installazione --prefix mentre ha installato .so.

Aggiornamento # 2

E 'possibile rimuovere i file .la dall'installazione --prefix utilizzando

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

Answer 1

non si deve necessariamente eliminare i file .la. I file .la contiene informazioni che viene utilizzato in due situazioni:

1. staticamente che collega alla libreria incorporata. Quando si collega staticamente (ovvero .a con -static), non vi sono informazioni sulle dipendenze della libreria collegata, quindi libtool può utilizzare le informazioni nel file .la per creare un appropriato comando ld che fa riferimento a tutte le dipendenze necessarie. Questo è spesso più importante in un ambiente come MinGW, in cui il linker richiede gli stessi multipli di libreria specificati in un particolare ordine per risolvere dipendenze ricorsive. Questa è solo una preoccupazione se si intende costruire un binario statico.

2. dinamicamente il caricamento della libreria generazione su alcuni piattaforme (vale a dire, con lt_dlopen se si utilizza libltdl). Allo stesso modo, su alcune piattaforme, le dipendenze del modulo di compilazione non sono codificate nel file binario, quindi il file .la è necessario in modo che lt_dlopen trovi e carichi le dipendenze corrette. Sulle piattaforme ELF (incluso Linux) e piattaforme PE (ad es. Windows), le dipendenze sono archiviate nella libreria, quindi lt_dlopen funzionerà senza i file .la. Il formato MachO su MacOS può richiedere i file .la durante la creazione di pacchetti.

I confezionatori Debian/Ubuntu hanno deciso di escludere .la file dal loro pacchetti perché il secondo motivo non è appropriato su Linux e che preferirebbe non hai costruire binari statici, in primo luogo. Su altre piattaforme, che libtool è progettato per supportare, i file .la potrebbero essere necessari per il collegamento o l'esecuzione del programma.

Answer 2

Mi sono imbattuto in questa domanda perché ha usato il termine "modulo", che in automake/libtool parla è il termine per un plugin. Ho un sistema di plugin in Finit, quindi costruisco i miei plugin con '-module' per evitare di creare file .a. Ma ho ancora i file .la installati, il che non è nemmeno applicabile nel caso '-module'.

ho ancora trovare un modo documentato per saltare i file per i plugin .la, ma ecco come lo faccio:

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

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

Per essere chiari, nel mio caso d'uso non c'è nessuno di andare a "link" contro il mio plugin .so, quindi i file .la sono davvero inutili.