[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] fix for problem with ns-allinone-2.1b8a
On Saturday 11 August 2001 10:33 am, Michele C. Weigle wrote:
>
> I had a problem compiling tcl8.3.2 after grabbing
> ns-allinone-2.1b8a. The problem I had was that when compiling tcl,
> the Makefile tried to generate tclStubInit.c which is already in
> tcl8.3.2/generic/. In order to generate tclStubInit.c you need
> tclsh, which is what I was trying to compile, so it didn't work.
>
> Looking into this further, I realized that the problem is the file
>timestamps in the ns-allinone-2.1b8a tarfile. I had an installation
> of ns-allinone-2.1b8 which worked fine -- in it, the timestamps in
> tcl8.3.2/ varied. In ns-allinone-2.1b8a, the file timestamps in
> tcl8.3.2/ are all "June 4 19:53". This causes the Makefile to think
> that tclStubInit.c needs to be generated when it actually doesn't.
>
> Fix: Grab tcl8.3.2 by itself -- the timestamps are retained
> correctly
>
> Can someone either fix ns-allinone-2.1b8a or mention this problem in
> the bugs section?
We've had this problem before with Mash (a set of MBone video/audio
tools that shares a very similar internal configuration with ns).
As you've discovered, Tcl is sensitive to the timestamp of
tclStubInit.c compared to the timestamps of tcl.decls and/or
tclInt.decls. It will try to regenerate the stubs if it thinks it's
necessary (which is the right thing to do for Tcl developers).
As a user, nothing has changed and you don't need to regenerate
anything. To fix the timestamps, just "touch tclStubInit.c" and
everything should compile normally.
Regarding the ns tarball, the ns person who packages it needs to make
sure that tclStubInit.c has a later modification time than tcl.decls
and/or tclInt.decls. When you're compiling Tcl, if you see messages
saying "Emitting blah blah..." then it's regenerating the stubs and the
file modification times have somehow gotten messed up.
+++
Lloyd Lim <[email protected]>
Open Mash <http://www.openmash.org/>