1
我正在開發用於OSX和Linux的python C++擴展。目前，我可以用一個包裝腳本wrapper.sh我的代碼運行：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]"
這是能夠建立我像這樣運行：wrapper.sh app.py
我想這樣做是爲了消除需要wrapper.sh，所以我需要替代DYLD_LIBRARY_PATH和LD_LIBRARY_PATH。我無法將我的庫放在一些標準位置，如/usr/local/lib，因爲在我的機器上，我維護了幾個獨立的庫實例。也就是說，我的庫需要保存在相對於我的安裝路徑的某個地方。出於同樣的原因，我無法將這些環境變量放入我的登錄腳本中。目前，我需要撥打我的wrapper.sh腳本中的一個來使用關聯的庫。我的目標是隻能運行app.py，如果它位於我的安裝路徑中，應該能夠找到其關聯的python和庫。其目的是簡化用戶的執行過程，並簡化外部工具（如鼻子測試）的使用。
一種選擇似乎是使用rpath的，當我建立我的Python版本：
./configure --enable-shared --prefix=$(CURDIR)/$(PYTHON_DIR) LDFLAGS="-Wl,-rpath,$(CURDIR)/lib/ -Wl,-rpath,$(CURDIR)/src/hdf5/lib -Wl,-rpath,$(CURDIR)/src/python/lib"
這一招似乎在Linux上工作得很好，即使我的圖書館之一最終需要被直接複製到trunk/src/python/lib/python2.6/lib-dynload由於某種原因我不清楚。但是，這個技巧在OSX上不起作用;它看起來像我需要在我所有的dylib庫上運行install_name_tool。
我想出了另一種選擇是做這樣的事情：
ln -s wrapper.sh python
讓我的腳本可以全部使用#! ../python，但我得到Unmatched ".錯誤。同樣的事情，如果我使用#! ../wrapper.sh。我不是一個真正的專家... ...
但是，這些都似乎是如此不必要的複雜，肯定這是其他人已經解決了？感謝您的任何建議！
在重新閱讀，我看到你試圖擺脫包裝;你最好的選擇是對Python解釋器搜索路徑的運行時操作。另一個結果是它不需要任何root權限，並且你的應用程序可以是可移植的（從文件系統的角度來看，本地代碼依賴關係顯然限制了你的可移植性）。 – 2010-12-16 20:26:14
至少有一些.so/.dylib庫需要在Python甚至啓動之前找到（即python搜索的時間太晚了）。我不明白爲什麼，但這是通過首先使用[DY] LD_LIBRARY_PATH解決的。 – amos 2010-12-17 01:04:10
有趣;我認爲唯一有用的是用本地副本覆蓋任何內置模塊或系統提供的擴展。如果這就是原因，那麼不能，你不能使用替代方案（並且作爲副作用，你甚至不能移植到所有類UNIX /類POSIX系統，因爲它們並不是全部都將這些鉤子賦予它們的動態接頭）。 – 2010-12-17 01:33:07