This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Error in building heaps.cxx


>>>>> "cgf" == Christopher Faylor <cgf@redhat.com> writes:

    <snip>

    >> I suspect this is yet another incompatibility with the latest
    >> TCL (8.4)that the cygwin group released recently. It appears
    >> not to understand cygwin paths any more which makes it pretty
    >> useless as a cygwin package. We're working on a workaround. In
    >> the meantime assuming you do indeed have TCL 8.4, try
    >> downgrading to 8.3. Run cygwin's setup.exe again and toggle the
    >> selected package version for the TCL package to try and get an
    >> earlier version.

    cgf> You realize that this is all open source right?

    cgf> I'm sure that a fix submitted to the insight mailing list
    cgf> would be well received.

    cgf> A fix seems like a much better alternative to a workaround to
    cgf> me.

Hang on a second. The 8.4 package has only been out for a few days. It
does take time to figure out exactly what is going and what has
changed, and then decide how best to proceed. In the case of path
handling, it might be appropriate to change the various Tcl scripts
used within eCos. Or it might be better to submit a patch that
switches the behaviour back to what it was, with possible implications
for current Insight and other applications. The typical eCos user
wants to work on eCos, and will have little or no knowledge of Tcl or
cygwin internals. For such a user, temporarily switching back to an
earlier version of Tcl is a perfectly sensible workaround.

Currently there are a number of issues with cygwin-hosted eCos
development, so perhaps it is worthwhile listing them in one place and
avoiding further mailing list traffic.

1) the official Insight release 5.3 will not compile on current cygwin
   using the default gcc 3.2 package. The following patch (already in
   the master sources) addresses the issue.
----------------------------------------------------------------------------
diff -u -r insight-5.3.orig/tcl/win/tclWin32Dll.c insight-5.3/tcl/win/tclWin32Dll.c
--- insight-5.3.orig/tcl/win/tclWin32Dll.c	Mon Sep 10 00:56:10 2001
+++ insight-5.3/tcl/win/tclWin32Dll.c	Sun Feb  2 19:00:05 2003
@@ -118,7 +118,7 @@
 };
 
 TclWinProcs *tclWinProcs;
-static Tcl_Encoding tclWinTCharEncoding;
+Tcl_Encoding tclWinTCharEncoding;
 
 /*
  * The following declaration is for the VC++ DLL entry point.
----------------------------------------------------------------------------

2) if you are using the current cygwin dll 1.3.19-1, it appears
   impossible to build a working gdb or insight (any version). The
   resulting executable will core dump while outputting the banner.
   There appears to be a bug in newlib's vasprintf() code, a use of an
   uninitialized variable. That code was imported into the cygwin dll
   recently. A patch for this is being worked on and will be sent to
   the appropriate mailing list(s), once it has been properly tested
   and we know that there are no other problems.

   Until that patch is ready and an updated cygwin dll has been
   released, there is a workaround. Using cygwin's setup.exe you can
   temporarily uninstall cygwin 1.3.19-1, and switch to cygwin
   1.3.18-1. Then re-run the gdb/insight configure script, and you
   should now be able to build a working executable. Afterwards you
   can switch back to 1.3.19-1.

   It is also worth taking a look at
   http://sources.redhat.com/insight/cygwin.html

3) building a powerpc-eabi toolchain using the current binutils
   release 2.13.1 also causes problems: cygwin's gcc 3.2 raises an
   internal compiler error while building powerpc-eabi-as.
   Unfortunately my knowledge of gcc internals is limited, and I do
   not have time right now to investigate this further. If somebody
   else wants to do so, feel free - of course the problem may have
   been fixed already in anoncvs gcc, or some other change to gcc may
   mean that the bug no longer triggers. A temporary workaround is to
   install the gcc 2.95.3 package and configure powerpc binutils with
   CC=gcc-2

4) new versions of cygwin Tcl have been released recently. This should
   make life easier in the medium and long term, the previous
   cygtclsh80 was badly out of date. Unfortunately the new versions
   have shown some problems, possibly in the eCos code, possibly in
   the new Tcl releases. When it comes to e.g. dealing with cygwin
   vs. native paths, there is no solution which will be right for
   everybody. 

   If you are using tcltk-20021218-1 (Tcl/Tk 8.3) then please make
   sure you are using up to date anoncvs eCos sources. I believe
   most/all problems have now been resolved by tweaking various
   scripts.

   If you are using the latest tcltk-20030128-3 (Tcl/Tk 8.4) then
   there are still some problems and these are being worked on. Some
   of these may be addressed by further changes to the eCos scripts
   (there are check-ins happening as I am writing this), while others
   may require discussion with the insight folks, patches to cygwin
   Tcl, and a respin. Hopefully everything will be resolved in the
   next week or so - there is plenty of eCos work that needs doing as
   well.

Bart

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]