Re: NS Validate problem

[Sean Murphy <murphys@teltec.dcu.ie>]

On Mon, 13 Sep 1999, Yu Qing wrote:

> Hi:
>    After I download NS-2 , I follow the step(configure, Make, validate) .
>    The first two step are all right, but When I run the validate, I meet the problem which I list below:
>     *** ./test-all-simple
> Tests: tahoe1 tahoe2 tahoe3 tahoe4 no_bug bug reno1 reno renoA reno2 reno3 reno4 reno4a reno5 telnet delayed phase phase1 phase2 timers stats
> ../../ns test-suite-simple.tcl tahoe1 QUIET
> ld.so.1: ../../ns: fatal: libotcl.so: open failed: No such file or directory
> Killed

You have compiled ns such that it is dynamically linked. This means that
it is assumed in the linking process that certain libraries will be able
to be loaded at run time. When you run ns it tries to use one of the
functions defined in the libotcl library file - this causes ns to try to
load the libotcl library. However, it cannot find it, and hence you see
the error.

You have two options - one is to link ns statically - this means that all
the functions required in the executable will be compiled into the
executable - this has the advantage of making the executable slightly more
portable - it should work on any system with the same os and processor as
yours, but the disadvantage of making the executable bigger and possibly
cause inefficent use of memory. I think that this can be done using the
--enable-static flag at the configure stage.

The other (and probably better) option is to tell ns where to find
libotcl. On solaris this can be done using the LD_LIBRARY_PATH environment
variable. Set this (using csh) as follows:
	setenv LD_LIBRARY_PATH name_of_directory_with_libotcl.so
although this could clobber your existing LD_LIBRARY_PATH, so it would
be better to do this
	setenv LD_LIBRARY_PATH "$LD_LIBRARY_PATH:libotcl_directory"
This approach is slightly less portable because ns assumes that the
libotcl library is available on the system that it is running on, but can
increase memory efficiency, since mutliple copies of ns running on one
system would all use the same copies of the libotcl.so library. Hence only
one copy of libotcl.so would need to be loaded into memory. It's the same
idea as DLLs in windows.

Sean.

> Test output differs from reference output
> Diagnose with: diff test-output-simple/tahoe1.test test-output-simple/tahoe1
> Differences due to floating-point formatting are not significant.
> ../../ns test-suite-simple.tcl tahoe2 QUIET
> ld.so.1: ../../ns: fatal: libotcl.so: open failed: No such file or directory
> Killed
> Test output differs from reference output
> Diagnose with: diff test-output-simple/tahoe2.test test-output-simple/tahoe2
> Differences due to floating-point formatting are not significant.
> ../../ns test-suite-simple.tcl tahoe3 QUIET
> ld.so.1: ../../ns: fatal: libotcl.so: open failed: No such file or directory
> Killed
> Test output differs from reference output
> Diagnose with: diff test-output-simple/tahoe3.test test-output-simple/tahoe3
> Differences due to floating-point formatting are not significant.
> ../../ns test-suite-simple.tcl tahoe4 QUIET
> ld.so.1: ../../ns: fatal: libotcl.so: open failed: No such file or directory
> Killed
> Test output differs from reference output
> Diagnose with: diff test-output-simple/tahoe4.test test-output-simple/tahoe4
> Differences due to floating-point formatting are not significant.
> ../../ns test-suite-simple.tcl no_bug QUIET
> ld.so.1: ../../ns: fatal: libotcl.so: open failed: No such file or directory
> Killed
> Test output differs from reference output
> Diagnose with: diff test-output-simple/no_bug.test test-output-simple/no_bug
> Differences due to floating-point formatting are not significant.
>    Thanks in advance.
>    ~qing
> 


-----
Sean Murphy,			Email: sean.murphy@teltec.dcu.ie
Teltec Ireland,			Phone: +353-1-7045080
DCU, Dublin 9,			Fax:   +353-1-7045092
Ireland.