Bug 6

Summary:	library inclusion fragility
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	build system	Assignee:	Tom Henderson <tomh>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	P3
Version:	pre-release
Hardware:	All
OS:	Mac OS

Description Tom Henderson 2007-02-01 02:15:57 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.

Comment 1 Mathieu Lacage 2007-02-01 05:53:04 UTC

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 ?

Comment 2 Tom Henderson 2007-02-01 11:34:54 UTC

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"

Comment 3 Mathieu Lacage 2007-02-01 13:16:33 UTC

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.

Comment 4 Tom Henderson 2007-02-03 20:49:35 UTC

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>

Comment 5 Tom Henderson 2007-04-30 18:34:47 UTC

please ignore this comment-- just touching it to see if mail from this server is working correctly

Comment 6 Mathieu Lacage 2007-07-23 08:17:44 UTC

closing since we moved to waf builds: if you use waf --shell, or waf --run, this problem is avoided.