[Fwd: Re: insight/230: `Tcl_WideInt' undeclared, <tcl.h>]

[Fwd: Re: insight/230: `Tcl_WideInt' undeclared, <tcl.h>]

[Keith Seitz]

The following reply was made to PR insight/230; it has been noted by GNATS.

From: Keith Seitz <keiths@redhat.com>
To: insight-gnats@sources.redhat.com
Cc:  
Subject: [Fwd: Re: insight/230: `Tcl_WideInt' undeclared, <tcl.h>]
Date: 18 Jun 2003 14:29:05 -0700

 To archive.
 
 -----Forwarded Message-----
 
 > From: Craig Carey <research@ijs.co.nz>
 > To: insight-prs@sources.redhat.com, kseitz@sources.redhat.com, nobody@sources.redhat.com, gilbert buob <gilbert.buob@sciopta.com>
 > Subject: Re: insight/230: `Tcl_WideInt' undeclared, <tcl.h>
 > Date: 19 Jun 2003 06:39:33 +1200
 > 
 > At 2003-06-18 11:15 +0200 Wednesday, gilbert buob wrote:
 > >Hello
 > >
 > >I have the same compile error  when  building insight. See my original mail,
 > > may be it can help you.
 > >Now I am not able to use latest insight with cygwin , I work with an older
 > >version however I made the following trials ( for [your] information )
 > >
 > >Trial 1:
 > >I modify the source by changing the waddr with long and so on ( I have an older
 > >version of Insight which work and I look in the code ) compile and link errors
 > > are OK and I get an executable which unfortunately crashes at startup.
 > >
 > >Trial 2:
 > >I used "-r gdb_5_2-branch" , so the previous compile errors were OK, but
 > >I get a new one that I fixed so I got an get an executable which
 > >unfortunately crashed at startup.
 > >
 > >[G]ilbert
 > >
 > >
 > 
 > I would use Linux but yet again the OS has auto-trashed itself (something
 > that never seems to happen with real Linuxes). I installed the Debian
 > 2.5.69 kernel and I either the kernel or lilo has upset the boot sector
 > well enough to kill fixing by "chroot ... lilo" and the Debian rescue
 > disk. Here below you have a feature of the core GNU community:
 > unhelpfulness founded on an agreeable intent to be helpful. I spotted
 > that at one of the GNU mailing lists.
 > 
 > After reading selected recent Insight mailing list messages about Cygwin,
 > it became unclear to me whether those special instructions should be
 > followed or ignored for being out of date. Having the instructions lead
 > the person into build-time crashes and more build-time problems than
 > what occurs when the instructions are not followed, is suggestive of the
 > page genuinely being out of date.
 > 
 > >
 > >************* THIS IS THE MAIL I SENT ON 23-05 *******
 > >hi
 > >
 > >I wanted to build insight , host is window2000/cygwin and target is
 > >i386-elf.
 > >I follow the procedure as written on the web
 > >-------> step 1)
 > >First get the sources for the version of Insight you want to use. The
 > >basic CVS command is
 > ...
 > 
 > 
 > I reply to "kseitz@sources.redhat.com"'s reply to my bug report.
 > 
 > 
 > >At 2003-06-18 01:20 +0000 Wednesday,
 > ...
 > > Build failures:
 > > 1. "the very latest mingw was used"
 > > Insight does NOT build with mingw. It is a cygwin
 > ...
 > 
 > I wrote that the "compiled" failed with MinGW and merely the
 > presence of the letter "d" was a mistake. 
 > 
 > 
 > > Note that gettext-devel is NOT required by
 > > Insight.
 > 
 > A custom is to have indirect requirements be requirements.
 > 
 > > It is required by BFD and several other
 > > patckages that Insight relies on. Without any explicit
 > > dependency tracking (like an RPM or something), there
 > > is little that I can do other than help users when
 > > these kinds of problems occur.
 > ...
 > 
 > Haven't you got an argument that greatly reduces the
 > credibility of the assertion you made: i.e. the statement
 > is going under because of the grounds. There is a motive
 > of helpfulness that can overcome a desire to not edit a
 > text file. Also both this bug system and the mailing list
 > record the fact that the maintainers already know that
 > gettext-devel is indirectly required, so your group is
 > in truth already holding the exact and correct results of
 > quite explicit tracking, e.g. from the bug report system.
 > Furthermore, helpfulness is set against the idea that
 > helpful incomplete information should be withheld only
 > on the ill-explained detail that it is incomplete. The
 > people at the mailing list may have been less able to
 > win their argument because the whole argument defending
 > the incompleteness was itself incomplete.
 > 
 > > 4."the older CVS files overwrote, and a Makefile was
 > > not edited to remove this error: 'cd: can't cd to
 > > iwidgets3.0.0/unix"
 > > I haven't a clue what this is right now.
 > 
 > If the instructions for Cygwin are followed then the build
 > did crash when a makefile discovered that that unix
 > directory was empty.
 > 
 > I tried compiling using the latest CVS with -d and with
 >  parts made older as instructed on the 2003-02-05
 >  webpage here:
 > 
 >    http://sources.redhat.com/insight/cygwin.html
 > 
 > That was 'clean' and installed into a new directory.
 > Compiling failed with bugs including the error over the
 > 'unix'directory. Then I deleted all files less than
 > 24 hours old and CVS-ed again, and deleted all files
 > associated with a "?" and CVS-ed again. In Unix/Compat
 > that is not enough since symlinks have to be deleted. One
 > of the files in the Windows 2000 directory was a symlink
 > and the Insight build crashed on it.
 > 
 > I did not try compiling a snapshot.
 > 
 > ...
 > > did you use the cvs option "-P"? Did you use the "-d"
 > > option in the tcl, tk, itcl, gdb directories? Please
 > > explain a little more what you did.
 > 
 > Yes, for one of the cases.
 > 
 > > I have been building insight on cygwin without incident
 > > for several months now (the whole dejagnu thing excepted).
 > 
 > Around 3000 files of the Insight collection had their dates
 > altered in the last 3 days so your comment may be
 > out of date.
 > 
 > 
 > > Please explain a little more about your environment. I
 > > suspect that your mingw environment is getting in the
 > > way...
 > 
 > I had had "/cygdrive" replaced with "/".
 > MinGW was hidden by having the Cygwin "/bin" be the
 > first directory in the Cygwin $PATH variable (it might not
 > have been put in using Cygwin bash's "export" command).
 > It was Cygwin Gcc that foudn the error.
 > 
 > ---
 > 
 > >
 > > What does config.cache say the value of
 > > "tcl_cv_type_64bit" is? What does configure say the
 > > host is?
 > 
 > The "src/config.status" files does not contain the text
 > "tcl_cv_type_64bit".
 > 
 > The lines specifying the host said 'i686-pc-cygwin'.
 >