Please sign in to comment.
Fix library install_name on Mac OS X
On Mac OS X, each shared library has an “install_name” property that should be set to the absolute path of the library's installation location, since this is how OS X find libraries at launch time. In waf, this is easy enough — just include the “osx” tool into your wscript. Unfortunately, this breaks waf unit testing , since you can longer run the test executables directly from the build directory. Normally, the test framework sets DYLD_LIBRARY_PATH so that the test executables find the newly compiled libraries in the build directory. However, the install path includes the full three-digit vnum of the shared library, while the file produced in the build directory doesn't. (At install time, the no-vnum file is renamed into the with-vnum file.) In the waf bug , we've submitted a patch that fixes this, which is included in a new waf script in this project template. It creates an additional symlink in the build directory that contains the three-digit vnum, so that the test executables can find their libraries.  http://code.google.com/p/waf/issues/detail?id=721
- Loading branch information...
|@@ -0,0 +1,46 @@|
|+# Usage: run.sh [debug|release] program arguments|
|+# Runs a program from one of the build directories, with|
|+# LD_LIBRARY_PATH set correctly so that it can find all of the shared|
|+# libraries before they're installed.|
|+# Check that there are enough command-line parameters.|
|+if [ $# -lt 1 ]; then|
|+ echo "Usage: run.sh [debug|release] program arguments"|
|+ exit 1|
|+# Verify that the user chose a valid build type.|
|+case "$BUILD" in|
|+ echo "Unknown build type $BUILD"|
|+ exit 1|
|+# Find all of the src subdirectories in the build directory, and use|
|+# those as the LD_LIBRARY_PATH.|
|+SRC_DIRS=$(find build/$BUILD -name src)|
|+JOINED=$(echo $SRC_DIRS | perl -ne 'print join(":", split)')|
|+# Run the desired program, and pass on any command-line arguments|
Binary file not shown.