2017-06-05 5 views
0

Ich habe zwei Versionen von Boost auf Cluster installiert. Der alte ist in Standard-Standort, während der neue in meinem Home-Verzeichnis. Da ich kein su-Privileg habe, kann ich das alte nicht löschen. Ich exportierte Umgebungsvariablen für Boost (und für andere Bibliotheken) wie folgt:Konflikt zwischen zwei Boost-Versionen

export PATH=/truba/home/osibliyev/boost/bin:$PATH 
export LD_LIBRARY_PATH=/truba/home/osibliyev/boost/lib:$LD_LIBRARY_PATH 
export LIBRARY_PATH=/truba/home/osibliyev/boost/lib:$LIBRARY_PATH 
export CPLUS_INCLUDE_PATH=/truba/home/osibliyev/boost/include:$CPLUS_INCLUDE_PATH 

Nachdem mit make Kompilieren ich die folgende Fehlermeldung bei Verknüpfungsstufe erhalten:

/usr/bin/ld: Warnung : libboost_serialization.so.1.64.0, benötigt von /truba/home/osibliyev/boost/lib/libboost_mpi.so, kann einen Konflikt mit libboost_serialization.so.1.53.0/usr/bin/ld: loadmap.o: undefiniert verursachen Referenz auf Symbol '_ZN5boost7archive17archive_exceptionC2ERKS1_' /truba/home/osibliyev/boost/lib/l ibboost_serialization.so.1.64.0: Fehler Hinzufügen von Symbolen: DSO fehlt von der Kommandozeile

lboost_serialization bereits LDADD hinzugefügt:

LDADD = -lmetis -lmpi -lboost_mpi -lboost_serialization -lboost_log -lboost_log_setup -lboost_thread -lpthread -lboost_date_time -lboost_filesystem -lboost_system -lboost_timer 

Ich bin irgendwie sicher, dass der Fehler aufgrund von Konflikten ist weil andere Bibliotheken problemlos verlinkt sind und nur Boost beschweren. Dies passiert nicht auf meiner Maschine, wo es nur eine Boost-Version gibt. Was kann ich tun, um diesen Fehler zu beheben?

+0

Wenn Sie _DSO suchen, fehlt in der Befehlszeile_ auf SO, erhalten Sie eine Reihe von möglichen Antworten. Hast du sie schon gelesen? Das sieht sehr nach einer doppelten Frage aus. [Hier] (https://stackoverflow.com/q/15634114/4987285) ist eine, die Ihnen wahrscheinlich helfen kann. – skypjack

+0

@skypjack Ja, ich habe nach ähnlichen Fragen gesucht, aber keine löst mein Problem. Außerdem tritt das Problem nur im Cluster nicht auf meinem PC auf. Das lässt mich glauben, dass das Problem die Existenz von zwei Boost-Versionen ist, aber ich weiß nicht, wie ich die alte Version loswerden soll. – Shibli

+0

Das Problem wird nicht von der alten Version, sondern von der neueren Version. Soweit mir bekannt ist, wird keine der von Ihnen beschriebenen Umgebungsvariablen diesen Effekt haben. Stattdessen möchten Sie eine Option "-L/truba/home/osibliyev/boost/lib" zu "LDADD" hinzufügen, bevor eine der Optionen "-l" Boost-Bibliotheken angibt. Sie werden jedoch den 'LD_LIBRARY_PATH' zum * run * Zeitpunkt benötigen. –

Antwort

1

Wie die Header- und Bibliothekssuchpfade Ihrer Toolchain ermittelt werden, ist implementierungsspezifisch. Es gibt keine universelle Regel dafür, welche Umgebungsvariablen diese überhaupt beeinflussen oder wie.

Die spezifischen Umgebungsvariablen, die Sie verwenden möchten, und die Werte, die Sie für sie festlegen, weisen auf ein UNIX-System hin. Sie sollten sich bewusst sein, dass

  • auf einem solchen System die PATH Variable den Suchpfad für ausführbare Dateien, nicht Bibliotheken oder Header setzt.
  • auf den Systemen, die es erkennen, LD_LIBRARY_PATH bezeichnet zusätzliche Verzeichnisse für die dynamische Linkers Suchpfad - diese sind relevant zur Laufzeit, nicht bauen Zeit.
  • CPLUS_INCLUDE_PATH wird vom GNU C++ - Compiler erkannt, und möglicherweise auch von anderen, um zusätzliche Verzeichnisse für die Suche nach Include-Dateien zu bestimmen. Dies ist relevant für das Auffinden der Boost-Header, nicht aber für die Bibliotheken. Bei GNU-Compilern werden die in dieser Variablen aufgeführten Verzeichnisse vor den Standardverzeichnissen gesucht.
  • LIBRARY_PATH wird vom GNU-Linker und möglicherweise anderen als zusätzliche Verzeichnisse zur Suche nach Bibliotheken erkannt. Wie CPLUS_INCLUDE_PATH, ist dies für Sie relevant, aber es erlaubt Ihnen nicht, Ihre Bibliotheken für gleichnamige andere in einem der Standard-Standorte zu ersetzen, weil die Standardverzeichnisse vor diese durchsucht werden.
  • Ihre Fehlermeldungen deuten darauf hin, dass der Linker eine Mischung aus Boost v1.53- und v1.64-Bibliotheken findet. Wahrscheinlich bedeutet das, dass sich die erste in einem Verzeichnis befindet, das zuerst gesucht wird - wahrscheinlich ein Systemverzeichnis wie /usr/lib - aber nicht alle Boost-Bibliotheken, die Sie verknüpfen möchten, werden dort gefunden; Einige finden Sie in Ihrer v1.64-Installation. Da das, was Sie bereits versucht haben, nicht funktioniert, ist es unwahrscheinlich, dass Sie eine Umgebungsvariable haben, die Sie einstellen können, um das zu beheben.Wie gesagt, es ist jedoch implementierungsabhängig, und obwohl ich vermute, dass Sie die GNU-Toolchain verwenden, haben Sie nicht angegeben.

    Wenn Sie möchten, dass der Linker Ihre persönliche Boost-Installation nach Bibliotheken durchsucht, bevor er die Standardverzeichnisse durchsucht, müssen Sie ihn mit der GNU-Toolchain über die Befehlszeilenoption anweisen. Wie in den Kommentaren erläutert, können Sie dies erreichen, indem Sie -L/truba/home/osibliyev/boost/lib zu Ihrer Automake LDADD Variable hinzufügen.

    Verwandte Themen