2010-05-01 22 views
14

Sto provando a migrare la mia applicazione da build manuale ad autoconf, che sta funzionando molto bene finora. Ma ho una libreria statica che non riesco a capire come integrare. Quella libreria NON si troverà nelle solite posizioni di libreria: la posizione del file binario (.a) e l'intestazione (file .h) saranno fornite come argomento configure. (In particolare, anche se sposto il file .a in/usr/lib o in qualsiasi altro luogo a cui riesco a pensare, non funzionerà ancora.) Non è anche chiamato tradizionalmente (non inizia con "lib" o "l ").Autoconf - inclusa una libreria statica (newbie)

compilazione manuale sta lavorando con questi (directory non è prevedibile - questo è solo un esempio):

gcc ... -I/home/john/mystuff /home/john/mystuff/helper.a 

(Uh, io in realtà non capisco perché il file .a viene fatto riferimento direttamente, non con -L o qualsiasi altra cosa.Sì, ho una mezza comprensione della costruzione di programmi C.)

Quindi, nel mio configure.ac, posso usare l'argomento configure relativo per trovare con successo l'intestazione (file .h) usando AC_CHECK_HEADER. All'interno di AC_CHECK_HEADER, quindi, aggiungo il percorso a CPFLAGS e l'inclusione # del file di intestazione nel codice C attuale lo preleva bene.

dato un argomento di configurazione che è stato messo in $ percorso e il nome dei file necessari sono helper.h e helper.a (che sono entrambi nella stessa directory), qui è ciò che funziona finora:

AC_CHECK_HEADER([$location/helper.h], 
    [AC_DEFINE([HAVE_HELPER_H], [1], [found helper.h]) 
    CFLAGS="$CFLAGS -I$location"]) 

Dove mi imbatto in difficoltà è ottenere il file binario (.a) collegato. Non importa quello che provo, ottengo sempre un errore sui riferimenti non definiti alle chiamate di funzione per quella libreria. Sono abbastanza sicuro che si tratti di un problema di collegamento, perché posso agitarti con il codice C e fare un errore intenzionale nelle chiamate di funzione a quella libreria che produce errori precedenti che indicano che i prototipi di funzione sono stati caricati e utilizzati per la compilazione.

Ho provato ad aggiungere il percorso che contiene il file .a in LDFLAGS e quindi a fare un AC_CHECK_LIB ma non è stato trovato.

Forse la mia sintassi è sbagliata, o forse mi manca qualcosa di più fondamentale, che non sarebbe sorprendente dato che sono un principiante e non so davvero cosa sto facendo.

Ecco che cosa ho provato:

AC_CHECK_HEADER([$location/helper.h], 
    [AC_DEFINE([HAVE_HELPER_H], [1], [found helper.h]) 
    CFLAGS="$CFLAGS -I$location"; 
    LDFLAGS="$LDFLAGS -L$location"; 
    AC_CHECK_LIB(helper)]) 

Nessun dadi. AC_CHECK_LIB sta cercando -lhelper credo (o libhelper?) Quindi non sono sicuro se questo è un problema, quindi ho provato anche questo (ometto AC_CHECK_LIB e includo il .a direttamente in LDFLAGS), senza fortuna:

AC_CHECK_HEADER([$location/helper.h], 
    [AC_DEFINE([HAVE_HELPER_H], [1], [found helper.h]) 
    CFLAGS="$CFLAGS -I$location"; 
    LDFLAGS="$LDFLAGS -L$location/helper.a"]) 

di emulare la compilazione manuale, ho provato a rimuovere il -L, ma che non aiuta:

AC_CHECK_HEADER([$location/helper.h], 
    [AC_DEFINE([HAVE_HELPER_H], [1], [found helper.h]) 
    CFLAGS="$CFLAGS -I$location"; 
    LDFLAGS="$LDFLAGS $location/helper.a"]) 

ho provato altre combinazioni e permutazioni, ma penso che potrei mancare qualcosa di più fondamentale ....

================ AGGIORNAMENTO

ho preso a lavorare con un percorso hard-coded nel file .a in Makefile.am utilizzando _LDADD come questo:

myprog_LDADD=/home/john/mystuff/helper.a 

Ma non può prevedere la posizione del file .a. Per qualche motivo, definendo myprog_LDADD in configure.ac non funziona (vorrei farlo, quindi posso usare la mia variabile di posizione dinamica) e nessuna combinazione di modifiche a LDFLAGS, myprog_LDFLAGS, AM_LDFLAGS sembra funzionare.

Se, in Makefile.am, cerco di utilizzare la posizione variabile definita in configure.ac, non funziona

myprog_LDADD=($location)helper.a 

============ ==== UPDATE

Penso di aver capito, ma dato che non ho idea di quello che sto facendo, apprezzerei VERAMENTE qualche feedback. Ho usato AC_SUBST() per ottenere myprog_LDADD lavorare da configure.ac, per cui la soluzione finale si presenta così:

AC_CHECK_HEADER([$location/helper.h], 
    [AC_DEFINE([HAVE_HELPER_H], [1], [found helper.h]) 
    CFLAGS="$CFLAGS -I$location" 
    myprog_LDADD="$location/helper.a" 
    AC_SUBST(myprog_LDADD)]) 
+0

È molto per rispondere a tutti in una volta. Potresti ottenere più risposte se hai posto una domanda alla volta, e sarebbe più facile leggere se hai formattato correttamente gli estratti del codice, anteponendo a ciascuna riga quattro spazi. – ptomato

risposta

8

È possibile impostare la posizione in configure.ac:

LOCATION=/home/john/mystuff 
AC_SUBST(LOCATION) 

AC_SUBST definisce la variabile $LOCATION in tutti i tuoi Makefile.am s e sostituisce anche tutte le occorrenze di @[email protected] con il contenuto di $LOCATION. Quindi nel tuo Makefile.am puoi fare

myprog_CPPFLAGS="-I$LOCATION" 
myprog_LDADD="$LOCATION/helper.a" 

PS. Il motivo per cui è necessario fare riferimento alla libreria direttamente è perché -l cerca una libreria con nome corretto (ad esempio libhelper.a) nelle directory della libreria di sistema. Tuttavia, poiché non c'è molta differenza tra una libreria statica e un file oggetto, non è necessario ricorrere magicamente al riferimento usando -l; puoi semplicemente compilarlo nel tuo programma come lo stai facendo ora.

+0

OK, grazie. Vedendo quello che hai suggerito, sembra che abbia fatto praticamente la stessa cosa, usando AC_SUBST() per propagare myprog_LDADD ai Makefile. C'è qualcosa di sbagliato nel mio metodo rispetto al tuo? GRAZIE PER L'AIUTO !!!!!! – EBM

+0

Inoltre, c'è qualche ragione per mettere helper.a in LDFLAGS non funziona, ma aggiungerlo a myprog_LDADD? Ovviamente non capisco la differenza tra i due. Grazie ancora. – EBM

+0

Il metodo definisce myprog_LDADD in tutti i makefile, non solo in quello in cui è necessario. Ciò potrebbe causare problemi. – ptomato

Problemi correlati