2012-08-14 4 views
5

Während ein 3rd-Party-C++ Programm ausführt, erhalte ich folgende Fehlermeldung:Fehler beim Laden von gemeinsam genutzten Bibliotheken: libgomp.so.1:, falsche GCC-Version?

Fehler beim Shared Libraries Laden: libgomp.so.1: kann nicht mit anderen geteilt Objektdatei öffnen: Keine solche Datei oder das Verzeichnis

Die libgomp.so .1-Bibliothek ist die OpenMP-Laufzeitbibliothek der GNU-Compiler-Sammlung.

Ist dieser Teil des GCC-Pakets? Ich kann das Programm auf einem System mit gcc-4.5 ausführen, aber nicht mit gcc-4.3 oder gcc-4.6.

Oder muss ich ein anderes Paket installieren?

Ich habe versucht, dies manuell auf dem System mit gcc-4.3 zu beheben, indem Sie die Bibliothek herunterladen und auf den LD_LIBRARY_PATH setzen, aber dann bekomme ich eine weitere fehlende Bibliothek: /usr/lib/libstdc++.so.6: Version `GLIBCXX_3 .4.11 'nicht gefunden. libstdc ist die GNU Standard C++ - Bibliothek, so dass dies auch eine falsche Version von GCC anzeigt?

Ich bin kein C++ - Entwickler, daher weiß ich nicht genau, was diese Bibliotheken sind und wie Bibliotheken im Allgemeinen mit C++ - Code funktionieren.

Das Betriebssystem ist Linux 64 Bit.

gcc-4.3-Maschine: openSUSE 11.1

gcc-4.5-Maschine: openSUSE 11.4 (auf dieser Maschine das Programm funktioniert)

gcc-4.6-Maschine: openSUSE 12.1

+0

Ich nehme an, Linux auf diesem System. Was ist die tatsächliche Verteilung? – unkulunkulu

+0

Ist das Programm auch 64-Bit? –

Antwort

3

Das Programm wurde mit einer bestimmten Version von libgomp (libgomp.so.1) verknüpft und kann nur von diesem verwendet werden. So müssen Sie entweder:

  1. den Quellcode der Anwendung erhalten und es sich für Ihr System zu kompilieren,
  2. eine andere Version der Anwendung gegen neuere Version von gcc erhalten,
  3. erhalten eine statisch verknüpfte Version der Anwendung,
  4. Wenn Ihre Distribution unterstützt, dass die ältere Version von libgomp parallel installieren,
  5. Wenn nicht, können Sie immer noch die ältere libgomp binäre greifen und sie in Ihrem /usr/lib (vorzugsweise /usr/local/lib, wenn dieser Pfad in Ihrem ist /etc/ld.so.conf),
  6. Und schließlich, wenn das möglich ist, können Sie gcc auf die ältere Version herunterstufen, damit es funktioniert. Aber es ist eine schlechte, kurzfristige Lösung.
1

Scheint Ihr Programm kompiliert wurde und mit gcc-4.5 verbunden, was dann bedeutet, dass Sie Kopfschmerzen haben werden, die es auf Versionen vor 4.5 portieren. Die Abhängigkeiten innerhalb einer Distribution (unter der Annahme von Linux) werden nicht einfach auf die nächsten Hauptversionen der Core-Bibliotheken wie clib und C++ lib übertragen. Viel einfacher, ein Standard-Upgrade Ihrer gcc-4.3-Box auf die nächste Linux-Distribution zu machen.

Für die gcc-4.6-Maschine müssen Sie möglicherweise nach einem compat-Paket mit libgomp.so.1 suchen. das ist Distro abhängig und ich kenne die Details hier nicht.

könnten Es Tools sein, so Abhängigkeit Informationen auf Ihrem System zum Extrahieren, versuchen

man ldd

+0

Es gibt RPM-Pakete, die Ihnen bei der gcc-4.6-Version helfen können, zum Beispiel hat diese rpm-Seite eine Seite [rpm.pbone.net ...] (http://rpm.pbone.net/index) .php3/stat/3/srodzaj/1/suche/libgomp.so.1() (64bit)). (Oder kann Probleme verursachen) – Jojje

2

Sie können alle gemeinsam genutzte Bibliothek verknüpft Abhängigkeiten eines Programms sehen comamnd mit ldd. Zum Beispiel:

$ 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) 

Nun, wenn Sie möchten, dieses Programm in einer anderen Maschine laufen zu lassen und Probleme mit der Version der gemeinsam genutzten Bibliotheken haben, können Sie versuchen, die Menge in ein Verzeichnis zu kopieren und dann den LD_LIBRARY_PATH Trick verwenden. Aber beachten Sie, dass einige Bibliotheken müssen nicht kopiert werden:

  • linux-gate.so: keine richtige Datei, sondern eine Gateway-Land zu den Kernel.
  • /lib/ld-linux-so.2: Der dynamische Lader, (oder ELF-Interpreter, wie einige es nennen). In der Kopfzeile jeder dynamisch verknüpften ausführbaren Datei befindet sich eine statische Referenz. Kopiere es nicht.
  • [/usr]/lib/i386-linux-gnu/*: Alles in diesem Verzeichnis ist architekturspezifisch. Es funktioniert möglicherweise, wenn beide Maschinen die gleiche Architektur haben.Wenn nicht, müssen Sie unter [/usr]/lib/<your-real-arch>/* nach einer Bibliothek mit demselben Namen suchen.

In der Zielmaschine, können Sie auch das ldd Werkzeug nach export LD_LIBRARY_PATH=... verwenden, um festzustellen, ob es den Bibliotheken auflöst, wie erwartet.

Verwandte Themen