Bug 3 - wrong RPATH in build.py
wrong RPATH in build.py
Status: RESOLVED INVALID
Product: ns-3
Classification: Unclassified
Component: build system
pre-release
PC Linux
: P1 critical
Assigned To: ns-bugs
: bug
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-21 09:15 UTC by Nicola Baldo
Modified: 2008-07-01 13:32 UTC (History)
0 users

See Also:


Attachments
patch implementing solution proposed in comment #2 (1.08 KB, patch)
2006-10-23 08:20 UTC, Nicola Baldo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nicola Baldo 2006-10-21 09:15:13 UTC
In build.py the RPATH for executable is determined by the following:

lib_path = os.path.join (build_root, 'lib')
...
module_builder = env.Program (target = filename, source = objects,
                  LIBPATH=lib_path, LIBS=libs,
                  RPATH=lib_path)

this result in all built executables being unable to find the needed shared libraries:

$ ./sample-simulator
./sample-simulator: error while loading shared libraries: libsimulator.so: cannot open shared object file: No such file or directory

which of course can be fixed by setting LD_LIBRARY_PATH, but I think this was not the original intention of the developers.

The problem is that the RPATH is wrong:

$ objdump -p sample-packet | grep RPATH
  RPATH       build-dir/dbg-shared/lib


A possible fix is to change build.py this way:

module_builder = env.Program (target = filename, source = objects,
                  LIBPATH=lib_path, LIBS=libs,
                  RPATH='../lib')

which obtains this effect:

$ objdump -p sample-packet | grep RPATH
  RPATH       ../lib

and (at least on linux) it works:

$ ./sample-packet
send data=2
received data=2


Using a relative path has the benefits that binaries and libraries can be installed in whatever prefix and keep on working.

A slightly more complex approach is described here:
http://www.scons.org/wiki/UsingOrigin
which if I understood correctly should have the additional benefit of working on SUN systems, too. Anyway, I didn't try it.


Regards,

Nicola
Comment 1 Mathieu Lacage 2006-10-23 04:25:30 UTC
You are supposed to invoke binaries from the top-level directory and not from the 'bin' directory: 

The following will work:
./build-dir/opt-shared/bin/run-tests

It was done that way to save you from having to cd to the correct directory.

I could be convinced to change the current way of doing this to use absolute paths which would allow you to invoke the binary from any directory but this would break the build if you move around the source tree.
Comment 2 Nicola Baldo 2006-10-23 08:14:05 UTC
A better solution is then to use $ORIGIN symbol (the "slightly more complex approach" I mentioned above) which has the benefits of being independent of the working directory:

baldo@pcsignet08:/locale/baldo/src/ns-3/build-dir/dbg-shared/bin$ objdump -p sample-packet | grep RPATH
  RPATH       $ORIGIN/../lib

baldo@pcsignet08:/locale/baldo/src/ns-3/build-dir/dbg-shared/bin$ ./sample-test
PASS Callback
PASS ReferenceList
PASS My

baldo@pcsignet08:/locale/baldo/src/ns-3$ ./build-dir/dbg-shared/bin/sample-test
PASS Callback
PASS ReferenceList
PASS My
Comment 3 Nicola Baldo 2006-10-23 08:20:21 UTC
Created attachment 1 [details]
patch implementing solution proposed in comment  #2
Comment 4 Mathieu Lacage 2006-10-23 09:23:55 UTC
I applied a patch similar to the one you suggested. Do you have any idea whether or not your approach will work also on OSX ? (I don't have a system to test it on)

thanks !
Comment 5 Mathieu Lacage 2006-10-23 09:41:57 UTC
For reference, I found the following:
http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63919

which seems to imply that ORIGIN will not work but that something else will.
Comment 6 Mathieu Lacage 2007-07-23 08:16:16 UTC
we use waf to build the code so, the scons scripts are dead.