Prof A Olowofoyeku (The African Chief) wrote:
This is the platform that the Mingw gcc maintainers declare and they have been using it for a while (probably as far back as gcc-2.95.3.x). I believe however that some people who build their own gpc for Mingw use things such as "i486-pc-mingw32". This is not "standard", and I guess they can edit the gp sources themselves, unless there is a way of supporting all the various permutations (i[3456]86-pc-mingw32).
I'll just add them.
Under Mingw, some programs compile without problem, using gp. With others I get this error:
"gp example1 d:\mingw\lib\gcc-lib\mingw32\3.2.3\units\dosunix.pas:400:5: internal erro r: parser position mismatch"
I can't reproduce it. Do you have an example where it occurs? Is it CR/LF related?
Can you add the line:
fprintf (stderr, "BufPos: %i, BufCount: %i\n", BufPos, BufCount);
before:
if (BufPos != BufCount) ParseError ("internal error: parser position mismatch");
in gp-parse.c and note the output when running?
Msys throws up some complaints ("gpc -print-file-name=units installation problem: cannot get default unit path"), but seems to be okay in the end, in the sense that the compiled program is there, and runs okay. I have attached a tarball containing logs of the output of the three Win32 platforms. I have ascertained that the complaints by the MSYS binary arise because "DirectoryExists (Res)" returns False when it should return true (in "GetUnitPath"). I have been unable to locate the actual body of the DirectoryExists function to ascertain why this is happening.
It's in the RTS. You reported a problem with it on 2003-11-22 (`Cygwin and "Stat"'), but according to the thread it was related to mingw and/or gcc versions. Anyway it's hard for me to debug. So if you have any suggestions (for a generic fix in the RTS), let me know.
Frank