Re: mem-trace yet again

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

On Mon, 14 Sep 1998, John Heidemann wrote:
> On Mon, 14 Sep 1998 14:30:45 PDT, John Heidemann wrote: 
> >On Mon, 14 Sep 1998 22:09:55 BST, Lloyd Wood wrote: 
> >>...
> >>In any case for the Sep 13 snapshot, I can only make as far as:
> >>
> >>object.cc: In method `int NsObject::delay_bind_dispatch(const char *,
> >>const char
> >> *)':
> >>object.cc:80: no method `TclObject::delay_bind_dispatch'
> >>object.cc:81: warning: control reaches end of non-void function
> >>`NsObject::delay_bind_dispatch(const char *, const char *)'
> >>
> >>on either 2.5.1 and 2.4.
> 
> Somehow the content got lost...
> I mean to say:
> please check to make sure you're running the current tclcl
> and/or getting the right tclcl.h.
> (object.cc:80: no method `TclObject::delay_bind_dispatch' is very
> suspicious).

Okay, some progress.

I'd looked at Ingela's similar reported problem with a similar error
message in the archives, checked my setup, and dismissed this offhand. 

(for ages I've been consistently starting configure with
--with-tclcl=$HOME/ns/tclcl
where $HOME/ns/tclcl is a symlink to a parallel tcl directory -
in this case $HOME/ns/tclcl-1.0b6
which is the most recent version, while various ns snapshots live
parallel to that and all the other required pieces in
$HOME/ns/ns-<version>-<date>).

There was a parallel tclcl-1.0b5 directory next to the 1.0b6 directory
in case I needed to revert, but since it wasn't symlinked to or
deliberately specified, and 1.0b6 has been required since b3, I didn't
consider it a problem.  On your suggestion I moved it. 

It looks as if the tclcl 1.0b5 directory was being picked up on, even
though it wasn't being specified to configure, and some of the
compiler outputs with the problematic recent daily snapshot confirm
this with -I../tclcl-1.0b5, while ns 2.1b3 just shows -I../tclcl or
even -I/user/ccsrnrpg1/eep1lw/tclcl. 

Odd. Why? A look in configure shows:

TclCL_VERS=1.0b5          <-- odd
TclCL_ALT_VERS=1.0
 
TclCL_H_PLACES="\
                ../tclcl-$TclCL_VERS \
                ../tclcl-$TclCL_ALT_VERS \
                ../tclcl \

...hmmm, so much for my specifying anything, really. I should really
have spent more time learning how configure works... 

I see ns 2.1b3 requires TclCL_VERS=1.0b6, yet the later snapshots I
have from 1 September onwards only require 1.0b5. I don't understand
why the drop back occurred in version; surely anything later than
2.1b3 will also require 1.0b6? As this snapshot seems to?

This recent snapshot's configure also includes such version checks as:

PERL_VERSION=${PERL_VERSION:-5.000}   - ns pages say 5.003 is required;
                                        you'd be nuts to permit earlier.
OTCL_VERS=1.0a2                       - ns pages say 1.0a3 is required;
                                        may as well check for it. (okay,
                                        2.1b3 has a3 - another drop back.)
TCLDEBUG_VERS=5.20                    - eh? This is really the version of
                                        expect, and _that's_ up to 5.26.
                                        Should be 1.7 (or 1.6 if you're
                                        still running Tcl/Tk 7.6), surely?
                                        Try finding tcl-debug-5.2/ ...

in a similar vein, I see the tclcl snapshot configure says 'checking
for libotcl1.0a2' when we're up to a3 ...

I think you'll find that not allowing compiles without the correct
versions eases troubleshooting and will reduce and focus the time you
spend on support, but I'm thinking of end user rather than developer
requirements here. 

My nitpicking of minimum versions required apart, I can now build
Sunday's snapshot. Progress! Hurrah! 

thanks!

L.

alas, expanded addresses, trace-*, etc are still broken, though -
everything I reported holds for ns 2.1b3, which compiled with tclcl
1.0b6.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/>PGP<L.Wood@surrey.ac.uk>