durante il caricamento delle librerie condivise: libgomp.so.1:, versione GCC errata?

Question

Durante l'esecuzione di un 3rd party C++ programma ottengo il seguente errore:

errore durante il caricamento delle librerie condivise: libgomp.so.1: non può aprire il file oggetto condiviso: Nessun file o directory

Il libgomp.so .1 library è la libreria di runtime OpenMP della raccolta del compilatore GNU.

Questa parte del pacchetto GCC? Posso eseguire il programma su un sistema con gcc-4.5, ma non con gcc-4.3 o gcc-4.6.

Oppure devo installare un altro pacchetto?

Ho provato a sistemarlo manualmente sul sistema con gcc-4.3 scaricando la libreria e inserendola in LD_LIBRARY_PATH, ma poi ho un'altra libreria mancante: /usr/lib/libstdc++.so.6: versione `GLIBCXX_3 .4.11 'non trovato. libstdc è la libreria GNU standard C++ quindi questo indica anche una versione errata di GCC?

io non sono uno sviluppatore C++ quindi non pienamente so che queste librerie sono e come funzionano le biblioteche in generale, con il codice C++.

L'os è Linux 64 bit.

gcc-4.3 macchina: openSUSE 11.1

gcc-4.5 macchina: openSUSE 11.4 (su questa macchina funziona il programma)

gcc-4.6 macchina: openSUSE 12.1

Answer 1

Il programma è stato collegato a una versione specifica di libgomp (libgomp.so.1) e può essere utilizzato solo da quello. Quindi devi uno:

1. Ottenere il codice sorgente dell'applicazione e compilarlo da soli per il sistema,
2. ottenere una un'altra versione della applicazione compilata con la versione più recente di gcc,
3. Ottenere un staticamente versione legata dell'applicazione,
4. Se la vostra distribuzione sostiene che, installare la versione precedente di libgomp in parallelo,
5. in caso contrario, si può ancora afferrare il più vecchio libgomp binario e metterlo nel vostro /usr/lib (preferibilmente, /usr/local/lib invece se quel percorso è nel tuo /etc/ld.so.conf),
6. E infine, se è possibile, puoi eseguire il downgrade di gcc alla versione precedente per farlo funzionare. Ma è una brutta soluzione a breve termine.

Answer 2

Sembra che il tuo programma è stato compilato e collegato usando gcc-4.5, che quindi implica un mal di testa che lo porta alle versioni precedenti alla 4.5. Le dipendenze all'interno di una distribuzione (assumendo Linux) non sono facilmente portate avanti alle prossime versioni principali delle librerie core come clib e C++ lib. Molto più semplice fare un aggiornamento standard della tua casella gcc-4.3 alla prossima versione di distro di Linux.

Per la macchina gcc-4.6 potrebbe essere necessario cercare un pacchetto compat contenente libgomp.so.1. questo è distro dipendente e non conosco i dettagli qui.

Ci potrebbero essere gli strumenti per l'estrazione di informazioni così dipendenza sulla propria macchina, provare

man ldd

Answer 3

è possibile vedere tutta la libreria condivisa dipendenze collegate di un programma utilizzando comamnd ldd. Per esempio:

$ ldd /bin/ls 
    linux-gate.so.1 => (0xb76fe000) 
    libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb76be000) 
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb76b5000) 
    libacl.so.1 => /lib/i386-linux-gnu/libacl.so.1 (0xb76ab000) 
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7506000) 
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7501000) 
    /lib/ld-linux.so.2 (0xb76ff000) 
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb74e6000) 
    libattr.so.1 => /lib/i386-linux-gnu/libattr.so.1 (0xb74e0000) 

Ora, se si desidera eseguire questo programma in un'altra macchina e hanno problemi con la versione delle librerie condivise è possibile provare a copiare il sacco in una directory e quindi utilizzare il LD_LIBRARY_PATH trucco. Ma nota che alcune librerie devono non essere copiati:

• linux-gate.so: Non è un vero file, ma un gateway per kernel terreno.
• /lib/ld-linux-so.2: Il caricatore dinamico, (o interprete ELF, come alcuni lo chiamano). C'è un riferimento statico ad esso nell'header di ogni eseguibile collegato dinamicamente. Non copiarlo.
• [/usr]/lib/i386-linux-gnu/*: Tutto in questa directory è specifico per l'architettura. Potrebbe funzionare se entrambe le macchine hanno la stessa architettura.In caso contrario, è necessario cercare una biblioteca con lo stesso nome sotto [/usr]/lib/<your-real-arch>/*.

Nella macchina di destinazione, è anche possibile utilizzare lo strumento ldd dopo export LD_LIBRARY_PATH=... per vedere se si sta risolvendo le librerie come previsto.