Re: daily snapshot make note

[Lloyd Wood <eep1lw@surrey.ac.uk>]

On Fri, 26 Jun 1998, John Heidemann wrote:

> On Fri, 26 Jun 1998 16:53:25 BST, Lloyd Wood wrote: 
> >On Fri, 26 Jun 1998, Lloyd Wood wrote:
> >
> >> mem-trace.h: In method `MemTrace::MemTrace()':
> >> In file included from scheduler.cc:47:
> >> mem-trace.h:37: warning: implicit declaration of function `int
> >> getrusage(...)'
> >> [..]
> >> mem-trace.h: In method `MemTrace::MemTrace(...)':
> >> In file included from tclAppInit.cc:78:
> >> mem-trace.h:37: warning: implicit declaration of function `int
> >> getrusage(...)'
> >> 
> >> ...and that's it. Under Solaris rusage is defined in <sys/rusage.h>
> >>...
> >
> >rusage.h (below) is in /usr/ucbinclude/sys on Solaris...
> >
> >...and only includes the rusage struct. Very odd - so
> >-I /usr/ucbinclude/ and
> >#include <sys/rusage.h> don't do the trick by themselves unless the
> >getrusage is defined in mem-trace.h anyway.
> >
> >I'm told getrlimit() is the Portable Way To Go.
> 
> Gee, I followed the includes Solaris and SunOS wanted, but they
> cheated me (as you observed).
> 
> getrlimit does something else.
> 
> I added code that compiles cleanly on SunOS/Linux/Solaris.
> If you want to check tonights snapshot it should work for you.


I grabbed and checked the snapshot at 1am Sunday BST (+100), Sunday
morning. Ultra 30, as before. 

> ls -l mem-trace.h 
 -rw-r--r--   1 eep1lw       2090 Jun 27 02:24 mem-trace.h

[..]
mem-trace.h: In method `MemTrace::MemTrace()':
In file included from scheduler.cc:48:
mem-trace.h:55: warning: implicit declaration of function `int
getrusage(...)'
[..]
mem-trace.h: In method `MemTrace::MemTrace(...)':
In file included from tclAppInit.cc:78:
mem-trace.h:55: warning: implicit declaration of function `int
getrusage(...)'
[..]

The problem appears only to have moved. This warning doesn't appear to
be an important functional problem for the Ultra (test-all still
works); however, on Sparc20s running Solaris 2.4 I get the rather
more serious: 

> uname -a
SunOS 5.4 Generic_101945-38 sun4m sparc
> ns tcl/ex/mcast.tcl
ld.so.1: /user/ccsrnrpg1/eep1lw/ns-2.1b3-current/ns: fatal:
relocation error:
symbol not found: getrusage: referenced in
/user/ccsrnrpg1/eep1lw/ns-2.1b3-current/ns
Killed

annd rebuilding the latest snapshot on 2.4 gives me the slightly more 
explicit:

In file included from scheduler.cc:48:
mem-trace.h:36: field `time' has incomplete type
mem-trace.h: In method `MemTrace::MemTrace()':
mem-trace.h:55: warning: implicit declaration of function `int
getrusage(...)'
mem-trace.h:55: `RUSAGE_SELF' undeclared (first use this function)
mem-trace.h:55: (Each undeclared identifier is reported only once
mem-trace.h:55: for each function it appears in.)
mem-trace.h:55: `struct MemInfo' has no member named `time'
mem-trace.h: In method `void MemTrace::diff(char *)':
mem-trace.h:60: `RUSAGE_SELF' undeclared (first use this function)
mem-trace.h:60: `struct MemInfo' has no member named `time'
mem-trace.h:61: `struct MemInfo' has no member named `time' (multiple times)
mem-trace.h:68: `struct MemInfo' has no member named `time'
*** Error code 1
make: Fatal error: Command failed for target `scheduler.o'

...but then that _is_ with gcc 2.7.0 rather than the 2.7.2.1 present
on the Ultra. Having said that, the 2.1b2 release seems to build
okayish on 2.4 with 2.7.0 - although memtrace.h was rather different
back then. 

Also noted:

a quick test of ./ns tcl/ex/mcast.tcl for the recent snapshots is
generating different .nam results to ns-2.1b2 (tracefile is
identical), and nam 1.0a4 is choking on:

nam: unknown event at offset 21 in `out.nam'
nam: `V -t * -v 1.0b6 -a 0
'
and following A lines

from ns-2.1b3-current/tcl/lib/ns-lib.tcl:
>       $self puts-nam-config "V -t * -v $v -a 0"
etc.

Should I be using a snapshot of nam as well? (haven't been able to
build a current nam snapshot - mark?.xbm isn't present, etc.)

By the way, I've found ns to be using a directory also called 'nam' to
get in the way and be a trifle confusing; I end up simply removing it
and relying on the (optional?[*]) nam 1.0a4.

Given that nam has been spun off as a separate public development, am
I correct in thinking that Steven's nsx/nse ns/nam integration effort
of March '97 is now a legacy dead-end, and that ns-current-2.1b3/nam
could be excised relatively easily to avoid user confusion? I end up
just deleting the directory so that I can put a symlink to the 1.0a4
nam there instead - trying to execute that directory when I run a
script has caught me more than once!

[*] http://www-mash.cs.berkeley.edu/ns/ns-build.html
    nam's not listed as optional under 'Getting the pieces' with a link
    and how-to - well, ns doesn't exactly _depend_ on nam, but then
    it doesn't depend on xgraph etc either.

thanks,

L.

<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641