Frank wrote:
Gerrit P. Haase wrote:
I tracked the segfault down to the function which parses the options to set the correct environment for Cygwin or MinGW, it seems that there is an invalid pointer. (The function mingw_scan() in gcc-3.3.1-2/gcc/config/i386/cygwin1.c). Since it works ok with gcc.exe or g++.exe or g77.exe or gcj.exe, there must be some relevant difference in gpc.exe when it goes to parse the commandline and passes the arguments to mingw_scan().
I don't know about this function (I don't use mingw). When (and from where) is it called? It's true that the gpc executable does some
It is called directly from main, as first before every other action is taken, because we need to know if the compiler modus is MinGW or Cygwin and depending on the flags the environment is initialised with -DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ && -D__MSVCRT__ -D__MINGW32__ && -DWINNT or with -D__CYGWIN__ && -D__CYGWIN32__. This is triggered from the command line with one of -mno-cygwin, -mcygwin, -mwin32 or -mno-win32. Since these are command line switches and the behaviour of the preprocessor, compiler and linker depends on the settings this needs to be done before everything else is done.
modification of the command-line options (see init_gpc_options in gpc.c), and of course it's possible that there's a bug there. (That's partly about the `--amtmpfile' thing with which "ThomasM" reported a problem under mingw recently.)
I just looked through this function. The only suspicious thing I found is that it doesn't terminate the new argument list with a NULL pointer (not to be confused with the char 0 terminator of each single argument string, of course). I'm not sure if this is actually required (since argc is updated correctly), but if so, the attached patch may help.
The patch is good! I was able compile the gpc.exe now and all seems to work. Many thanks for catching this!
Release time, I'll offer a complete GCC-3.3.1 suite for Cygwin 1.5.x, including C, C++, ObjC, Fortran, Ada, Java and now Pascal. I package them in several packages, one for the core/backend and one for every frontend. Is it possible to upload them to gnu-pascal.de too?
Prof A Olowofoyeku (The African Chief) wrote:
On 29 Sep 2003 at 8:28, Gerrit P. Haase wrote:
[...]
It isn't necessary to have it. My understanding (Frank can correct this if I am wrong) is that the RTS build does not require os-hacks.h, but if it is there, it uses it.
Anyway, the build fails for me with or without this file.
Well, GPC has problems with gcc-3.3.1 - and I suspect that this applies to one extent or the other on many platforms. Compiling GPC for Cygwin based on gcc-3.3.1 has proved impossible for me as well (although I haven't tried too hard - I simply use gcc-3.2.3).
This is also true. System conditionals are currently broken with gcc-3.3.1, and they're particularly necessary on Dos/Windows systems. With some information Waldek found, it might be possible to provide a work-around soon, and perhaps a real fix in the next release.
I would like to run some tests witjh the compiler now after it seems to work for me it would be nice to see what works and what doesn't work. Is it sufficient to run make check?
[...]
I have hints files there for several operating systems. Why shouldn't it be possible to have something like this in GPC too?
It is possible. But that is an operational matter, for Frank.
The reason is simple: These contain system features (or emulations), and are not related to GPC (or restricted to it -- they're designed to be usable by any C program). Since mingw is also a free project,
But I need it not to use MinGW or Cygwin, need it only to build GPC (or maybe it is not needed, will need frther investigation on this issue).
Gerrit