Ich entwickle Python C++ - Erweiterungen für die Verwendung in OSX und Linux. Derzeit kann ich meinen Code mit einem Wrapper-Skript ausführen wrapper.sh:Alternativen zu DYLD_LIBRARY_PATH/LD_LIBRARY_PATH
#!/bin/bash
trunk=`dirname $0`
trunk=`cd $trunk; pwd`
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$trunk/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$trunk/lib/:$trunk/src/hdf5/lib/:$trunk/src/python/lib
$trunk/src/python/bin/python "[email protected]"
der wie folgt meinen Lauf einzurichten ist in der Lage: wrapper.sh app.py
Was möchte ich tun, ist die Notwendigkeit für wrapper.sh zu beseitigen, also brauche ich Alternativen für DYLD_LIBRARY_PATH und LD_LIBRARY_PATH. Ich kann meine Bibliotheken nicht an einem Standardstandort wie /usr/local/lib platzieren, da ich auf meinem Computer mehrere unabhängige Instanzen meiner Bibliotheken verwalte. Das heißt, meine Bibliotheken müssen relativ zu meinem Installationspfad irgendwo aufbewahrt werden. Ich kann diese Umgebungsvariablen aus demselben Grund nicht in mein Anmeldeskript einfügen. Momentan muss ich eines meiner wrapper.sh Skripts aufrufen, um die zugeordneten-Bibliotheken zu verwenden. Mein Ziel ist es, nur app.py ausführen zu können, was, wenn es in meinem Installationspfad lebt, in der Lage sein sollte, die zugehörigen Pythons und Bibliotheken zu finden. Der Zweck besteht darin, die Ausführung für Benutzer zu vereinfachen und die Verwendung von externen Tools wie Nosetests zu vereinfachen.
Eine Alternative scheint mit rpath werden, wenn ich meine Version von Python bauen:
./configure --enable-shared --prefix=$(CURDIR)/$(PYTHON_DIR) LDFLAGS="-Wl,-rpath,$(CURDIR)/lib/ -Wl,-rpath,$(CURDIR)/src/hdf5/lib -Wl,-rpath,$(CURDIR)/src/python/lib"
Dieser Trick scheint auf Linux zu funktionieren, auch wenn einer meiner Bibliotheken benötigen landete direkt in trunk/src/python/lib/python2.6/lib-dynload kopiert werden aus irgendeinem Grund unklar für mich. Dieser Trick funktioniert jedoch nicht unter OSX. es sieht so aus, als müsste ich install_name_tool auf all meinen dylibs-Bibliotheken laufen lassen.
Die andere Alternative kam ich mit war, so etwas zu tun:
ln -s wrapper.sh python
so dass meine Skripte alle #! ../python verwenden könnte, aber ich bin immer Unmatched ". Fehler. Das gleiche gilt, wenn ich #! ../wrapper.sh verwende. Ich bin nicht wirklich ein Experte in Bash ...
Allerdings scheinen diese alle so unnötig kompliziert, und sicherlich ist das etwas, das andere Leute gelöst haben ?? Danke für jeden Hinweis!
Nach dem erneuten Lesen, sehe ich, dass Sie versuchen, ein Wrapper loszuwerden; Am besten ist die Laufzeitmanipulation des Suchpfads des Python-Interpreters. Das andere Ergebnis ist, dass es keinen Root-Zugriff erfordert, und Ihre Anwendung kann dann portabel sein (aus der Perspektive eines Dateisystems; Abhängigkeiten von nativen Codes beschränken offensichtlich Ihre Portabilität). –
Zumindest einige dieser .so/.dylib-Bibliotheken müssen gefunden werden, bevor Python überhaupt gestartet wird (d. H. Zu der Zeit, in der Python sucht, ist es zu spät). Ich verstehe nicht warum, aber dies wurde mit [DY] LD_LIBRARY_PATH in erster Linie gelöst. – amos
Interessant; Das einzige, was ich für nützlich halten kann, ist das Überschreiben aller integrierten Module oder systemerweiterten Erweiterungen mit einer lokalen Kopie. Wenn das der Grund ist, dann nein, du kannst keine Alternative verwenden (und als Nebeneffekt wirst du nicht einmal auf alle UNIX-ähnlichen/POSIX-ähnlichen Systeme portierbar sein, weil nicht alle von ihnen solche Hooks in ihre Dynamik einbinden Linker). –