Hi all,
It seems there are still some people with the misfortune of using Win98,
so I ruined a perfectly good weekend finding why so many people have
trouble running mspgcc on Win98.
I found my children's PC, which I would normally leave strictly alone
for political reasons, seems to display the problem. It runs Win98SE.
mspgcc installs OK. When I run msp430-gcc it gives a segmentation fault
almost immediately. Its easy to find that it is cc1.exe (the first pass
of the compiler) which is actually crashing. It then took me hours of
find that mmap is allocating the same chunk of memory more than once. If
I put in a check for double allocation, and reallocate until I get a
genuinely new block of memory, I can then compile a large project
successfully. This, however, is just a test to prove there are no other
critical problems, and not a real cure.
I think the problem lies in cygwin (although it could be in Win98 itself
for all I know right now). I downloaded the source for cygwin, and tried
to build it, so I could try debugging of the cygwin DLL. However, the
make files build most of the code, and then fail saying there is no rule
to make /usr/lib/w32api/Makefile needed by /lib/. The make dependancies
are a little intertwined, and I got fed up trying to sort them out. If
anyone can help me get cygwin to build, there is a good chance I can
sort the Win98 problem out (and perhaps some other weird stuff people
get with cygwin).
As an alternative, I think gcc can be forced to build without using
mmap. I haven't tried this, but I assume cygwin's own builds of GCC
must do this, or it appears they would fail with the same problem.
As I have said before, some Win98 and WinMe machines run this stuff
without trouble, My Sony Vaio has a small WinMe partition and a large
Linux one. I can run mspgcc there without problems, booted from either
partition. I used a old Win98 machine for a few weeks, while waiting
for a decent new one, when I first started using mspgcc last autumn. I
never had any trouble using my own cygwin builds on that. I guess the
trouble lies in DLL hell, or the patch status of the machine.
Any input to resolve this would be much appreciated.
Regards,
Steve
