2012-03-03 16 views
9

Ho due versioni di GCC installate sul mio sistema 4.6.2 e 4.7.0. Sto eseguendo Fedora Core 16.GCC Non collega le librerie corrette

4.6.2 è installato in /usr/bin e 4.7.0 è installato in /home/nerozehl/local/bin. Anche le librerie e il runtime per C++ sono compilati e installati in /home/nerozehl/local/lib e /home/nerozehl/local/lib64.

Ho anche installato due versioni di Boost, con librerie in /usr/lib64 e /home/nerozehl/local/lib. (Boost 1.47.0 e 1.49.0, rispettivamente)

Il problema che sto avendo è che g ++/ld si collegano alle librerie predefinite, e non a quelle più recenti in /home/nerozehl/local. Sto usando configure per generare Makefile, e chiamo in questo modo:

CXX=g++47 CXXFLAGS="-g -O0 -pg" LDFLAGS="-L/home/nerozehl/local/lib" ./configure --prefix=/home/nerozehl/local 

Dove g++47 risiede nel /home/nerozehl/local/bin (nel mio $PATH).

Quando compilo, è tutto a posto, e vengono utilizzati gli header più recenti, ma quando posso controllare quello che era collegato contro:

ldd source/noes 
    linux-vdso.so.1 => (0x00007fffebfff000) 
    libboost_filesystem-mt.so.1.47.0 => /usr/lib64/libboost_filesystem-mt.so.1.47.0 (0x0000003c6a800000) 
    libboost_system-mt.so.1.47.0 => /usr/lib64/libboost_system-mt.so.1.47.0 (0x0000003c6a400000) 
    libboost_program_options-mt.so.1.47.0 => /usr/lib64/libboost_program_options-mt.so.1.47.0 (0x0000003c6ac00000) 
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003c6dc00000) 
    libm.so.6 => /lib64/libm.so.6 (0x0000003c68c00000) 
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c69c00000) 
    libc.so.6 => /lib64/libc.so.6 (0x0000003c68800000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c69000000) 
    librt.so.1 => /lib64/librt.so.1 (0x0000003c69800000) 
    /lib64/ld-linux-x86-64.so.2 (0x0000003c68400000) 

Per la vita di me non riesco a capire come forzare g ++/ld/configure per usare le mie nuove librerie. Qualsiasi aiuto sarebbe apprezzato.

+0

+1 per l'utilizzo di ldd – pyCthon

+0

Si dovrebbe verificare con l'opzione '-V' come l'attuale percorso di ricerca della libreria assomiglia: durante il collegamento g ++ mostrerà quali directory sarà la ricerca e in quale ordine. Per evitare il problema prova a passare il percorso desiderato usando l'opzione '-L'. La mia ipotesi è che cerca i percorsi standard prima del percorso locale nelle directory aggiuntive. –

+0

Sto usando -L/home/nerozehl/local/lib – nerozehl

risposta

9

ldd non ti dice a cosa è collegato l'eseguibile: ti dice quali oggetti condivisi verrà caricato dall'eseguibile durante la sua esecuzione. Se si vuole che si carichi da/home/nerozehl quando viene eseguito, è necessario fare una delle diverse cose:

  • impostato LD_LIBRARY_PATH per contenere/home/nerozehl/local/lib quando si esegue il programma

  • aggiungi/home/nerozehl/local/lib a ld.so.conf in modo che venga utilizzato da tutti. Funziona solo su sistemi (come linux) che usano ld.so.conf, comunque.

  • collegare il programma con -Wl,-rpath,/home/nerozehl/local/lib. Tuttavia, funziona solo su sistemi che utilizzano ELF o un altro formato eseguibile che lo supporta. Inoltre, esegue l'hardcode del percorso nell'eseguibile, che è alquanto fragile: se si sposta l'eseguibile su un'altra macchina o si riorganizza il proprio filesystem, potrebbe interrompersi.

+0

Quale programma mi dirà su quali librerie è collegato il file? – nerozehl

+0

@nerozehl - non c'è modo di dire dopo il completamento del collegamento, in quanto tali informazioni non sono memorizzate nel binario. –

1

Sei sicuro che lo script di configurazione presti attenzione a LDFLAGS? Esegui ./configure --help e vedi le opzioni. Di solito ce n'è uno chiamato --with-boost = e poi si dà la directory in cui si trova il boost. Prova quello invece. Allo stesso modo per qualsiasi altra opzione con cui hai problemi.

Problemi correlati