Bugzilla – Bug 6
library inclusion fragility
Last modified: 2008-07-01 13:32:12 UTC
I have noticed that the current build process is fragile in two ways: i) user clones or moves ns-3 directory somewhere else (e.g. /tmp). LD_LIBRARY_PATH or DYLD_LIBRARY_PATH does not include this new path, and program execution fails. May be vexing for new users and irritating for others. ii) a more subtle problem is when user has library path set from a previous build, builds another directory somewhere, but the new libraries are not picked up-- the old ones are instead. It would be preferable if the libraries picked up in a given bin/ directory were relative to . and not absolute, or something similar.
None of this is not true on linux: on linux, the binaries geenrated by scons link explicitely to the copy built in the build-dir and it still works if you move the whole archive. I suspect you observed this on osx, right ?
Mathieu, you are probably right about Linux; I had thought I had that experience before on Linux, but yesterday Craig was on a FC 6 machine and it did not seem to exhibit the behavior described. I can reproduce on OS X, where it depends on DYLD_LIBRARY_PATH. I will change the OS tag to "Mac OS"
It used to be like this on linux but I fixed it. I do not know how to do the same fix on osX though.
Leaving some notes about fixing this (not fixing it just yet): there seems no equivalent to RPATH for darwin from dyld release notes for os x: Currently, ld(1) has no options for directly embedding @loader_path into LC_LOAD_DYLIB load command. Instead, you must post-process your final linked images with install_name_tool. So for os x, it seems we need to post-process each created binary with something like: install_name_tool -change <libname> @executable_path/<relative_path>/<libname> <executable>
please ignore this comment-- just touching it to see if mail from this server is working correctly
closing since we moved to waf builds: if you use waf --shell, or waf --run, this problem is avoided.