2010-02-09 7 views
7

Sto classificando i file C e C++ per una classe e questo compito utilizza la libreria GSL. Poiché non ho il permesso di root sul mio computer, la mia libreria GSL è installata nella mia home directory, e quindi devo dire a compilatori e linker dove trovarla.Dire a ld dove cercare le directory tramite una variabile di ambiente

Questo non è un problema quando scrivo un programma da solo, perché aggiungo semplicemente i flag -L e -I appropriati a gcc.

Ma quando compilo i file degli studenti, non voglio modificare tutti i loro makefile. Invece, voglio mettere le directory appropriate in una variabile d'ambiente, in modo che avvenga senza problemi.

A tal fine, ho esportato le seguenti variabili con la biblioteca o includono posizioni: C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, LIBRARY_PATH e LD_LIBRARY_PATH

Ma quando compilo il progetto di uno studente, con

gcc -Wall -o MC_thread MC_thread.c -lgsl -lgslcblas -lpthread -lm 

Viene visualizzato il seguente errore:

/usr/bin/ld: cannot find -lgsl 
collect2: ld returned 1 exit status 
make: *** [all] Error 1 

Sto utilizzando gcc v 4.1.2. In realtà non ottengo l'errore se uso gcc v 4.4, ma non ne ho idea. Il mio linker è:

ld -V 
GNU ld version 2.17.50.0.6-12.el5 20061020. 
+1

Prova man ld e man ld.so per i vars ambientali che usano. LD_LIBRARY_PATH potrebbe funzionare. – Eugene

+2

Penso che LD_LIBRARY_PATH sia usato solo da ld.so, non da ld. Poiché si tratta di un errore in fase di compilazione, non di un errore in fase di esecuzione, vorrei concentrarsi sul motivo per cui LIBRARY_PATH non funziona. Due cose che verificherei, , il file della libreria ha il nome corretto ed è LIBRARY_PATH in realtà definito nell'ambiente di esecuzione gcc? –

+0

Prova a eseguire gcc con l'opzione '-v' e pubblica il richiamo completo di ld dall'output. –

risposta

11

Si potrebbe provare a utilizzare l'ambiente LIBRARY_PATH variabile

Da man gcc (almeno la versione 4,4)

 
     LIBRARY_PATH 
      The value of LIBRARY_PATH is a colon-separated list of directories, 
      much like PATH. When configured as a native compiler, GCC tries 
      the directories thus specified when searching for special linker 
      files, if it can't find them using GCC_EXEC_PREFIX. Linking using 
      GCC also uses these directories when searching for ordinary 
      libraries for the -l option (but directories specified with -L come 
      first). 

E poi poi usare LD_LIBRARY_PATH quando si eseguono i loro programmi per a lasciare che il linker di runtime trovi le librerie.

+0

OP ha detto che stava usando LIBRARY_PATH (e non sembra una modifica dal tuo post.) – jtniehof

0

Il mio consiglio è di richiedere agli studenti di supportare una variabile di ambiente CFLAGS nei loro makefile, altrimenti falliscono. :) Quindi è possibile esportare CFLAGS = "- Lwhatever".

Oppure è possibile utilizzare LD_LIBRARY_PATH.

+0

Probabilmente stai parlando di LDFLAGS, poiché -l e -L sono parametri di linker, non parametri di fase del compilatore. Ma sì, sono d'accordo. I makefile senza queste variabili sono inutili. –

2

Molte delle risposte precedenti suggeriscono l'uso di LD_LIBRARY_PATH. Ma questo non è corretto poiché si tratta di una variabile ambientale per il linker dinamico (runtime), non per il linker di compilazione ld.

Il modo corretto per farlo è quello di richiedere agli studenti di aggiungere qualcosa di simile:

-L$(EXTRA_LINK_DIRECTORY) 

nella loro Makefile in corrispondenza del punto in cui essi definiscono la regola build. Poi, quando si compilare, fare qualcosa di simile:

EXTRA_LINK_DIRECORY export =/home/...

1

Se siete su un computer a 64 bit, che è probabilmente il problema. OMM, gcc 4.1 non ricerca i percorsi specificati in LIBRARY_PATH, ma piuttosto path /../ lib64. Dovrai specificare -L direttamente, o collegare simbolicamente la directory a lib64 allo stesso livello, o pasticciare con le specifiche di gcc.

Vedi http://gcc.gnu.org/ml/gcc-help/2010-11/msg00360.html e Why does g++ look in LIBRARY_PATH/../lib64 and where is this documented?

(OMM, questo funziona con gcc 4.5 senza alcun problema, quindi suppongo che l'abbiano risolto in seguito.)

+0

Anche giocare con il file spec non aiuta molto, dato che fare ricerche solo in lib significa che gcc non trova i suoi bit interni, e facendolo cercare sia lib che lib64 significa che gcc sputa un sacco di avvertimenti per il 32 incompatibile versioni bit che trova. – jtniehof

+0

probabilmente lo era! Dal momento che ho installato GSL da solo, non avevo entrambe le librerie lib/e lib64 /, piuttosto una sola posizione con le librerie (64-bit) ma senza il lib4/nome previsto. Questa è una caratteristica piuttosto fastidiosa. Immagino che gcc 4.4 e 4.5 abbiano un comportamento migliore – Stephen

Problemi correlati