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: [eCos v1.3.1/net] Old-style path convention results in Run Tests error


On Sat, Mar 01, 2003 at 11:36:22AM +0000, Bart Veer wrote:
>>>>>> "cgf" == Christopher Faylor <cgf at redhat dot com> writes:
>
>    <snip>
>    >> It isn't any more. Cygwin unfortunately only releases the last
>    >> two versions of the DLL. This is causing us problems right now
>    >> as both cygwin 1.3.19 and 1.3.20 have significant problems (in
>    >> fact two in 1.3.20, one of which is easily corrected and has
>    >> already been reported on the cygwin lists, and the other is
>    >> still being investigated).
>
>    cgf> I don't see any problem reports from you in the cygwin
>    cgf> mailing list wrt 1.3.20.
>
>    cgf> What are these issues you are referring to?
>
>The problem was only detected a day ago, and it is not clear yet
>whether it is a cygwin or a gcc problem. If you are interested, the
>details are as follows:
>
>1) you build a target toolchain, based around gcc 3.2.1, on XP using
>   cygwin 1.3.18. (1.3.19 should not be used for this because gdb will
>   use the cygwin version of vasprintf() rather than the libiberty
>   one, and the resulting gdb will fail on any system that still uses
>   1.3.19).
>
>2) that toolchain appears to work fine on XP and W2K using cygwin
>   1.3.19 or 1.3.20, i.e. the two versions currently readily
>   available.
>
>3) it also works fine on W98 using cygwin 1.3.19
>
>4) but on W98 with cygwin 1.3.20, xyz-gcc seems to suffer memory
>   corruption problems.

Sounds like it could be mmap issues.  mmap on Windows 95 is only
partially implemented.  We did some work on mmap to solve other problems
for 1.3.20.  Maybe we broke something on Windows 95.  There has been
some additional work recently.  Does the latest Cygwin snapshot work any
better?  I don't think the work that was done relates to the problem
that you mention but maybe we'll get lucky.

>For example i386-elf-gcc will generate an ICE.  arm-elf-gcc will start
>complaining that #define is an invalid preprocessor directive halfway
>through a header file.

I've seen this kind of thing when building gcc/libiberty with an invalid
resource.h file.  There is one in newlib and one in
winsup/cygwin/include.  The one in the cygwin directory is larger and
has more fields but, in certain situations, the one in newlib gets used
instead of the correct one from the cygwin directory.

This is probably a red herring and has nothing to do with your problem
but I just thought I'd mention it since it is something that could
be checked quickly.  Basically, you can just delete the header in the
newlib directory and make sure that the one in /usr/include/sys
is ~2250 bytes.

Like I say, since this only seems to occur on Windows 9x, it seems like
the best guess would be that mmap wasn't working right but since the
symptoms sound similar to the resource.h problem, I thought I'd
mention it.

cgf

-- 
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]