Hallo Frank,
Am Dienstag, 30. September 2003 um 20:59 schriebst du:
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 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.
Sounds great, I'll try to build now with this patch applied.
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.
[...]
Also, I am not sure how the Win32 os-hacks.h can be added to the GPC source distro. It is pretty much OS-specific (hence the name), and it will only cause trouble if added to the general distro. Also, if IIRC, you can have a version of os-hacks.h for any platform, and the RTS build will use it.
Well, take a look into gcc-3.3.1/config.
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, it's unreasonable to put work-arounds for one project into another one. Also, these emulations are "cheap" in that they don't add any library code -- it's all done in macros in the header. So while I could understand (partly) if the mingw developers don't want to "bloat" their library, adding such a header would add nothing to a program that doesn't use it. If they still don't want to include it, that's their problem IMHO.
Perhaps it's possible to do (some of) the things in gcc/config (though I still thing it's the wrong place to do it). But that would be a backend issue, i.e. someone (not me) would have to talk to the GCC people and convince them to include it. If that's done, let me know.
Historically, os-hacks.h was chosen, and, so far, it has only ever been necessary to use that facility under Windows.
Actually I have a small os-hacks.h file for Linux (see contrib/frank), but it only contains a small and optional feature.
Frank