Hallo,
what is the status of GPC? Is it possible to build it with GCC 3.3.1? i would like to provide a precompiled version of GPC for Cygwin with the latest GCC. Are there still some patches which I need to apply (i.e. regarding the use on Cygwin)?
Gerrit
On 16 Sep 2003 at 8:08, Gerrit P. Haase wrote:
Hallo,
what is the status of GPC? Is it possible to build it with GCC 3.3.1? i would like to provide a precompiled version of GPC for Cygwin with the latest GCC. Are there still some patches which I need to apply (i.e. regarding the use on Cygwin)?
There is are Cygwin binaries on the GPC website (/contrib/chief/). The latest GPC binary there is based on gcc-3.2.3. I was not successful in building it on gcc-3.3.1 (indeed, I don't think there are any official gcc 3.3.1 releases for Cygwin - which might be quite revealing in itself).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Hallo Prof,
Am Dienstag, 16. September 2003 um 09:01 schriebst du:
On 16 Sep 2003 at 8:08, Gerrit P. Haase wrote:
what is the status of GPC? Is it possible to build it with GCC 3.3.1? i would like to provide a precompiled version of GPC for Cygwin with the latest GCC. Are there still some patches which I need to apply (i.e. regarding the use on Cygwin)?
There is are Cygwin binaries on the GPC website (/contrib/chief/). The latest GPC binary there is based on gcc-3.2.3. I was not successful in building it on gcc-3.3.1 (indeed, I don't think there are any official gcc 3.3.1 releases for Cygwin - which might be quite revealing in itself).
There is a test release on the mirrors a few days now (go figure) and I have already a working gcc-3.3.1 with Ada and all other 'standard' languages for cygwin 1.5 (http://anfaenger.de/cygwin-1.5/gcc/), I want to rebuild now with Pascal as additional language and with the same options than CGF used for the Cygwin test release, now I have my version and Cygwin has another version and these are not compatible (because of SjLj exceptions which I disabled).
Gerrit
Hallo,
Sorry for my bad english...
There is a test release on the mirrors a few days now (go figure) and
^^^ cygwin-gcc-3.3.1
I have already a working gcc-3.3.1 with Ada and all other 'standard' languages for cygwin 1.5 (http://anfaenger.de/cygwin-1.5/gcc/), I want to rebuild now with Pascal as additional language and with the same options than CGF used for the Cygwin test release, now I have my
^^^currently
version and Cygwin has another version and these are not compatible (because of SjLj exceptions which I disabled).
^^^ in my build, so it is a good day to rebuild all and probably also to include one more backend.
G.
Gerrit P. Haase wrote:
what is the status of GPC? Is it possible to build it with GCC 3.3.1? i would like to provide a precompiled version of GPC for Cygwin with the latest GCC. Are there still some patches which I need to apply (i.e. regarding the use on Cygwin)?
GPC should build out of the box with GCC 3.3.1 on most platforms. However:
1) There were bugs in gpc-20030830. Most problems should be fixed now but you must fetch the latest version (the patched tarball replaced the broken one without change of filename) or apply patches posted to this list. Also, we still wait for build reports -- more problems may show up.
2) IMHO Cygwin always required extra patches (see mailing list archive for recent posts about Cygwin).
On Tue, 16 Sep 2003, Waldek Hebisch wrote:
Gerrit P. Haase wrote:
what is the status of GPC? Is it possible to build it with GCC 3.3.1? i would like to provide a precompiled version of GPC for Cygwin with the latest GCC. Are there still some patches which I need to apply (i.e. regarding the use on Cygwin)?
GPC should build out of the box with GCC 3.3.1 on most platforms. However:
- There were bugs in gpc-20030830. Most problems should be fixed now but you must fetch the latest version (the patched tarball replaced the broken one without change of filename) or apply patches posted to this list. Also, we still wait for build reports -- more problems may show up.
fetched latest full tarball; used 3.3.1; got to here:
parse.y:100: unrecognized: %glr-parser parse.y:100: Skipping to next % parse.y:744: type clash (`' `itype') on default action parse.y:2861: type clash (`' `ttype') on default action make[2]: *** [../../gcc-3.3.1/gcc/p/parse.h] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2
meanwhile. a suggestion: when changing the tarball without a name change add a revision letter to the tarball itself.
perhaps thus: gpc-20030830.tar.gz becomes gpc-20030830a.tar.gz (the untared gpc is still gpc-20030830/ )
Russ
Russell Whitaker wrote
On Tue, 16 Sep 2003, Waldek Hebisch wrote:
Gerrit P. Haase wrote:
what is the status of GPC? Is it possible to build it with GCC 3.3.1? i would like to provide a precompiled version of GPC for Cygwin with the latest GCC. Are there still some patches which I need to apply (i.e. regarding the use on Cygwin)?
GPC should build out of the box with GCC 3.3.1 on most platforms. However:
- There were bugs in gpc-20030830. Most problems should be fixed now but you must fetch the latest version (the patched tarball replaced the broken one without change of filename) or apply patches posted to this list. Also, we still wait for build reports -- more problems may show up.
fetched latest full tarball; used 3.3.1; got to here:
parse.y:100: unrecognized: %glr-parser parse.y:100: Skipping to next % parse.y:744: type clash (`' `itype') on default action parse.y:2861: type clash (`' `ttype') on default action make[2]: *** [../../gcc-3.3.1/gcc/p/parse.h] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2
That is easy: after unpackig the tarball do 'touch parse.h'. Otherwise make tries to re-make parse.c and parse.h, and that requires very new version of bison. In fact only Frank has the correct version (I have one which works after I hand-edit the output).
meanwhile. a suggestion: when changing the tarball without a name change add a revision letter to the tarball itself.
perhaps thus: gpc-20030830.tar.gz becomes gpc-20030830a.tar.gz (the untared gpc is still gpc-20030830/ )
I agree. However, it is probably better to bump version number even on really small change (easier on auto-build scripts).
Waldek Hebisch wrote:
That is easy: after unpackig the tarball do 'touch parse.h'. Otherwise make tries to re-make parse.c and parse.h, and that requires very new version of bison. In fact only Frank has the correct version (I have one which works after I hand-edit the output).
I've done this now in the archive.
meanwhile. a suggestion: when changing the tarball without a name change add a revision letter to the tarball itself.
perhaps thus: gpc-20030830.tar.gz becomes gpc-20030830a.tar.gz (the untared gpc is still gpc-20030830/ )
I agree. However, it is probably better to bump version number even on really small change (easier on auto-build scripts).
OK, I'll try to remember it next time (not too soon, hopefully ;-).
Frank
Hallo Waldek,
GPC should build out of the box with GCC 3.3.1 on most platforms.
[...]
fetched latest full tarball; used 3.3.1; got to here:
parse.y:100: unrecognized: %glr-parser parse.y:100: Skipping to next % parse.y:744: type clash (`' `itype') on default action parse.y:2861: type clash (`' `ttype') on default action make[2]: *** [../../gcc-3.3.1/gcc/p/parse.h] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2
That is easy: after unpackig the tarball do 'touch parse.h'. Otherwise make tries to re-make parse.c and parse.h, and that requires very new version of bison. In fact only Frank has the correct version (I have one which works after I hand-edit the output).
What is very new in this case or better , which is the correct versin? I have `bison (GNU Bison) 1.875b'.
With this it fails: cd /tmp/gcc/gcc-3.3.1/gcc/p && bison -o parse.c parse.y stage1/xgcc.exe -Bstage1/ -B/usr/i686-pc-cygwin/bin/ -o p/parse.o -c -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -Ip -I/tmp/gcc/gcc-3.3.1/gcc -I/tmp/gcc/gcc-3.3.1/gcc/p -I/tmp/gcc/gcc-3.3.1/gcc/config -I/tmp/gcc/gcc-3.3.1/gcc/../include -DGPC -I/tmp/gcc/gcc-3.3.1/gcc/p /tmp/gcc/gcc-3.3.1/gcc/p/parse.c parse.c: In function `yysymprint': parse.c:4324: warning: traditional C rejects ISO C style function definitions parse.c: In function `yytokenName': parse.c:4499: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyfill': parse.c:4510: warning: traditional C rejects ISO C style function definitions parse.c:4517: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:4517: error: (Each undeclared identifier is reported only once parse.c:4517: error: for each function it appears in.) parse.c: In function `yyuserAction': parse.c:4535: warning: traditional C rejects ISO C style function definitions parse.y:250: warning: operation on `yylow' may be undefined [...more `yylow' ...] parse.y:2848: warning: operation on `yylow' may be undefined parse.c: In function `yyuserMerge': parse.c:7777: warning: traditional C rejects ISO C style function definitions parse.c:7778: warning: traditional C rejects automatic aggregate initialization parse.c: In function `yydestruct': parse.c:7798: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyrhsLength': parse.c:7814: warning: traditional C rejects ISO C style function definitions parse.c: In function `yylhsNonterm': parse.c:7821: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyisDefaultedState': parse.c:7832: warning: traditional C rejects ISO C style function definitions parse.c: In function `yydefaultAction': parse.c:7839: warning: traditional C rejects ISO C style function definitions parse.c: In function `yygetLRActions': parse.c:7857: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyLRgotoState': parse.c:7878: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyisShiftAction': parse.c:7889: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyisErrorAction': parse.c:7895: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyaddDeferredAction': parse.c:7904: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyinitStateSet': parse.c:7923: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyfreeStateSet': parse.c:7931: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyinitGLRStack': parse.c:7939: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyexpandGLRStack': parse.c:7961: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyfreeGLRStack': parse.c:8022: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyupdateSplit': parse.c:8032: warning: traditional C rejects ISO C style function definitions parse.c: In function `yymarkStackDeleted': parse.c:8040: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyundeleteLastStack': parse.c:8051: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyremoveDeletes': parse.c:8062: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyglrShift': parse.c:8093: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyglrShiftDefer': parse.c:8117: warning: traditional C rejects ISO C style function definitions parse.c: In function `yydoAction': parse.c:8142: warning: traditional C rejects ISO C style function definitions parse.c:8150: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yy_reduce_print': parse.c:8211: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyglrReduce': parse.c:8237: warning: traditional C rejects ISO C style function definitions parse.c:8264: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:8271: warning: traditional C rejects string concatenation parse.c: In function `yysplitStack': parse.c:8298: warning: traditional C rejects ISO C style function definitions parse.c:8302: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyidenticalOptions': parse.c:8324: warning: traditional C rejects ISO C style function definitions parse.c: In function `yymergeOptionSets': parse.c:8346: warning: traditional C rejects ISO C style function definitions parse.c: In function `yypreference': parse.c:8370: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyresolveStates': parse.c:8396: warning: traditional C rejects ISO C style function definitions parse.c:8401: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveAction': parse.c:8421: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyreportTree': parse.c:8435: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyreportAmbiguity': parse.c:8481: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyresolveValue': parse.c:8503: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyresolveStack': parse.c:8554: warning: traditional C rejects ISO C style function definitions parse.c: In function `yycompressStack': parse.c:8572: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyprocessOneStack': parse.c:8604: warning: traditional C rejects ISO C style function definitions parse.c:8616: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyreportSyntaxError': parse.c:8677: warning: traditional C rejects ISO C style function definitions parse.c: In function `yyrecoverSyntaxError': parse.c:8756: warning: traditional C rejects ISO C style function definitions parse.c: In function `main_yyparse': parse.c:8873: warning: traditional C rejects ISO C style function definitions parse.c: In function `yy_yypstack': parse.c:9000: warning: traditional C rejects ISO C style function definitions parse.c: In function `yypstates': parse.c:9011: warning: traditional C rejects ISO C style function definitions parse.c: In function `yypstack': parse.c:9021: warning: traditional C rejects ISO C style function definitions parse.c: In function `yypdumpstack': parse.c:9031: warning: traditional C rejects ISO C style function definitions parse.y: At top level: parse.y:2957: warning: `locations' defined but not used make[2]: *** [p/parse.o] Error 1 make[2]: Leaving directory `/tmp/gcc/gcc-build/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/tmp/gcc/gcc-build/gcc' make: *** [bootstrap] Error 2
Gerrit
Gerrit P. Haase wrote:
What is very new in this case or better , which is the correct versin? I have `bison (GNU Bison) 1.875b'.
With this it fails:
<snip> I get the same errors (in fact most of the messages are warnings). If I apply the patch below to 'parse.y' the build goes OK for me. Frank have bison with the same version number but which makes slightly different output.
I have succesfully compiled cross-compiler from linux to Cygwin and then cross-compiled Cygwin gpc on Linux box. I had errors in the build process since I first incorrectly installed Cygwin header files, also I have not checked if the binaries produced by the compiler work. In fact some problems are expected as with gcc-3.3.x gpc have no preprocessor predefines (as Maurice Lombardi noticed) and Cygwin uses some predefines.
Your error may be caused by faulty hardware -- usually I am able to reproduce errors using cross-compiler. It may also be another memory management problem. I will try if I can build gpc on Cygwin, but I have limited access to Windows machines so it will take some time.
diff -ru gpc-20030830.orig/p/parse.y gpc-20030830/p/parse.y --- gpc-20030830.orig/p/parse.y Sun Sep 14 02:15:08 2003 +++ gpc-20030830/p/parse.y Tue Sep 23 01:14:19 2003 @@ -65,7 +65,7 @@
%{ #include "gpc.h" - +#undef abort /* A few keywords of some dialects can be parsed as regular identifiers and checked from the parser actions => fewer special tokens. */ #define ASSERT_ID(id, location, pseudo_keyword) \
Hallo Waldek,
Am Dienstag, 23. September 2003 um 02:23 schriebst du:
Gerrit P. Haase wrote:
What is very new in this case or better , which is the correct versin? I have `bison (GNU Bison) 1.875b'.
With this it fails:
<snip> I get the same errors (in fact most of the messages are warnings). If I apply the patch below to 'parse.y' the build goes OK for me. Frank have bison with the same version number but which makes slightly different output.
It should be exactly the same output if he uses bison with the same version number... sigh.
[...]
Your error may be caused by faulty hardware -- usually I am able to
Nah, I'm the Cygwin Perl maintainer, I usually use my own compiled GCC, I can compile and use GCC with Ada, Java, ObjC, C++ and of course C, if my hardware would be a problem, I would see more difficulties than just one error when building GPC?
reproduce errors using cross-compiler. It may also be another memory management problem. I will try if I can build gpc on Cygwin, but I have limited access to Windows machines so it will take some time.
More likely the latter. I found also that there is a file missing from the GPC source package, os-hacks.h, why isn't it included in the tarball if it is necessary to have it when compiling under Cygwin or MinGW?
diff -ru gpc-20030830.orig/p/parse.y gpc-20030830/p/parse.y --- gpc-20030830.orig/p/parse.y Sun Sep 14 02:15:08 2003 +++ gpc-20030830/p/parse.y Tue Sep 23 01:14:19 2003 @@ -65,7 +65,7 @@
%{ #include "gpc.h"
+#undef abort /* A few keywords of some dialects can be parsed as regular identifiers and checked from the parser actions => fewer special tokens. */ #define ASSERT_ID(id, location, pseudo_keyword) \
I'll try that if needed, many thanks.
Gerrit
On 28 Sep 2003 at 20:14, Gerrit P. Haase wrote:
[...]
More likely the latter. I found also that there is a file missing from the GPC source package, os-hacks.h, why isn't it included in the tarball if it is necessary to have it when compiling under Cygwin or MinGW?
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.
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.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Hallo Prof,
Am Sonntag, 28. September 2003 um 20:41 schriebst du:
On 28 Sep 2003 at 20:14, Gerrit P. Haase wrote:
[...]
More likely the latter. I found also that there is a file missing from the GPC source package, os-hacks.h, why isn't it included in the tarball if it is necessary to have it when compiling under Cygwin or MinGW?
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.
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 haven't debugged it completely yet, though.
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?
We have a perl/hints directory in the Perl distribution where for every system which needs some special configuration there is a file which gets included if you are on that specific platform.
I don't think that a general purpose os-hacks.h file for all platforms needs to be not available, but to implement a neat mechanism which pulls in OS specific definitions whenever they are there should be no problem.
Gerrit
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).
[...]
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. Historically, os-hacks.h was chosen, and, so far, it has only ever been necessary to use that facility under Windows.
We have a perl/hints directory in the Perl distribution where for every system which needs some special configuration there is a file which gets included if you are on that specific platform.
I don't think that a general purpose os-hacks.h file for all platforms needs to be not available,
I am not sure that I understand this statement.
but to implement a neat mechanism which pulls in OS specific definitions whenever they are there should be no problem.
That is what os-hacks.h is for - and it is built into the RTS configure scripts to search for this file. Perhaps there are other ways to do this, "neat" or not. But that is a matter for Frank's judgment, I believe.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
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.
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
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
Hallo,
sorry for the fullquote, finger was too fast on the send key...
Gerrit
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
Gerrit P. Haase wrote:
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.
So it's called before init_gpc_options, so init_gpc_options can't be the problem ...
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!
... but apparently it is. I don't quite understand why. If you can find it out, please do, otherwise it'd seem a bit like Voodoo to me. (Anyway, what the patch does is certainly not wrong.) Or is mingw_scan actually called after init_gpc_options?
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?
You can use the upload page http://gnu-pascal.de/www/upload.html or send it by mail to me. If you plan to do this regularly, you can get an account on the server (send me an ssh public key by PM). If you haven't done, you might want to coordinate with the Chief. AFAIK, he's more interested in Mingw, but still has also Cygwin binaries on his pages.
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?
If you want to run only the GPC tests, you can do `make pascal.check' in the gcc subdirectory.
[...]
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).
You'll need it when compiling other C programs that use certain features. Perhaps noone has tried to compile such programs, or they've made their own work-arounds, but since these are generic improvements (at "no cost" as I explained), I still think it's better to fix them centrally (i.e., in the Mingw headers).
Frank
Hallo Frank,
Am Sonntag, 5. Oktober 2003 um 07:09 schriebst du:
[...]
The patch is good! I was able compile the gpc.exe now and all seems to work. Many thanks for catching this!
... but apparently it is. I don't quite understand why. If you can find it out, please do, otherwise it'd seem a bit like Voodoo to me. (Anyway, what the patch does is certainly not wrong.) Or is mingw_scan actually called after init_gpc_options?
Hmmm, gdb shows in the bt that it crashes in mingw_scan because the invalid pointer which was called from main, however this was with a non debugging version, maybe there was some information lost.
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?
You can use the upload page http://gnu-pascal.de/www/upload.html or send it by mail to me. If you plan to do this regularly, you can get an account on the server (send me an ssh public key by PM). If you haven't done, you might want to coordinate with the Chief. AFAIK, he's more interested in Mingw, but still has also Cygwin binaries on his pages.
Many thanks. But it turns out that I'll maintain the complete GCC suite for Cygwin now and I can uppload it directly to cygwin.com which will distribute it to the Cygwin mirrors worldwide.
So we'll talk more often in future if I include the Pascal frontend in the release;-)
May I redirect Pascal specific questions, success reports and bugreports to this list then?
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.
Where can I find some more infos about this?
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?
If you want to run only the GPC tests, you can do `make pascal.check' in the gcc subdirectory.
Great, I'll try that now.
[...]
Gerrit
Gerrit P. Haase wrote:
Many thanks. But it turns out that I'll maintain the complete GCC suite for Cygwin now and I can uppload it directly to cygwin.com which will distribute it to the Cygwin mirrors worldwide.
If there's a download page (suited for a novice to Cygwin and GPC) that I can link from binaries/cygwin instead of the Chief's page, let me know.
May I redirect Pascal specific questions, success reports and bugreports to this list then?
Of course.
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.
Where can I find some more infos about this?
You can try searching for `DMSDOS' in the archive (the mails seem to scattered over several threads).
Attached is an experimental patch to work around the problem. It uses the `--print-needed-options' mechanism, i.e. gpc --print-needed-options <your other options> somefile.pas will output to standard error(!) the options that must be given to the actual compilations.
The same mechanism is currently needed on MIPS (with any GCC version). The GPC makefiles and test scripts know about it, so they just should just work with this patch. In your own projects, you must take care of it yourself.
The issue can be solved without this kludge when the preprocessor is integrated. Since the issue has become more urgent now, I might try to do this until the next release.
Frank
Hallo Frank,
Am Sonntag, 5. Oktober 2003 um 17:23 schriebst du:
Gerrit P. Haase wrote:
Many thanks. But it turns out that I'll maintain the complete GCC suite for Cygwin now and I can uppload it directly to cygwin.com which will distribute it to the Cygwin mirrors worldwide.
If there's a download page (suited for a novice to Cygwin and GPC) that I can link from binaries/cygwin instead of the Chief's page, let me know.
To install Cygwin and all Cygwin packages a tool named setup.exe is used, it is available at the main Cygwin website http://cygwin.com/setup.exe
May I redirect Pascal specific questions, success reports and bugreports to this list then?
Of course.
Thanks.
[...]
Gerrit
On 5 Oct 2003 at 17:23, Frank Heckenbach wrote:
[...]
Where can I find some more infos about this?
You can try searching for `DMSDOS' in the archive (the mails seem to scattered over several threads).
Attached is an experimental patch to work around the problem. It uses the `--print-needed-options' mechanism, i.e. gpc --print-needed-options <your other options> somefile.pas will output to standard error(!) the options that must be given to the actual compilations.
[...]
After applying the patch, I get this error:
../../gcc/p/lang.c: In function `lang_init': ../../gcc/p/lang.c:487: error: `flag_iso' undeclared (first use in this function) ../../gcc/p/lang.c:487: error: (Each undeclared identifier is reported only once ../../gcc/p/lang.c:487: error: for each function it appears in.) make[1]: *** [p/lang.o] Error 1 make[1]: Leaving directory `/src/mingw/gcc-3.3.1-20030804-1/build/gcc' make: *** [all-gcc] Error 2
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Attached is an experimental patch to work around the problem. It uses the `--print-needed-options' mechanism, i.e. gpc --print-needed-options <your other options> somefile.pas will output to standard error(!) the options that must be given to the actual compilations.
[...]
After applying the patch, I get this error:
../../gcc/p/lang.c: In function `lang_init': ../../gcc/p/lang.c:487: error: `flag_iso' undeclared (first use in this function)
I see that flag_iso is declared in c-common.h which is specific to C and similar language frontends.
Unfortunately many targets' conditionals seem to depend on it, so we might have to provide a more or less dummy value for it. Neither one really makes sense in a non-C language, but since generally ISO C is quite a bit saner than K&R C, I'd rather try this. But I haven't checked exactly what kind of effects it has on various targets. So try inserting:
#define flag_iso 1
I see that in mingw32.h it affects the `_stdcall' and `_cdecl' macros (with one underscore, the ones with two underscores are always defined). Are they needed?
Frank
On 14 Oct 2003 at 7:00, Frank Heckenbach wrote:
Attached is an experimental patch to work around the problem. It uses the `--print-needed-options' mechanism, i.e. gpc --print-needed-options <your other options> somefile.pas will output to standard error(!) the options that must be given to the actual compilations.
[...]
After applying the patch, I get this error:
../../gcc/p/lang.c: In function `lang_init': ../../gcc/p/lang.c:487: error: `flag_iso' undeclared (first use in this function)
I see that flag_iso is declared in c-common.h which is specific to C and similar language frontends.
[...]
Well, after I removed the files in <build>/p/rts and amended the rts configure (for timezone - see my other post) and rebuilt stuff, the error seems to have disappeared.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 14 Oct 2003 at 7:00, Frank Heckenbach wrote:
Attached is an experimental patch to work around the problem. It uses the `--print-needed-options' mechanism, i.e. gpc --print-needed-options <your other options> somefile.pas will output to standard error(!) the options that must be given to the actual compilations.
[...]
After applying the patch, I get this error:
../../gcc/p/lang.c: In function `lang_init': ../../gcc/p/lang.c:487: error: `flag_iso' undeclared (first use in this function)
I see that flag_iso is declared in c-common.h which is specific to C and similar language frontends.
[...]
Well, after I removed the files in <build>/p/rts and amended the rts configure (for timezone - see my other post) and rebuilt stuff, the error seems to have disappeared.
You mean without the addition of `#define flag_iso ...'? That would be strange again, since I can actually see the cause of the problem (on affected targets).
Frank
On 19 Oct 2003 at 23:48, Frank Heckenbach wrote:
[...]
After applying the patch, I get this error:
../../gcc/p/lang.c: In function `lang_init': ../../gcc/p/lang.c:487: error: `flag_iso' undeclared (first use in this function)
I see that flag_iso is declared in c-common.h which is specific to C and similar language frontends.
[...]
Well, after I removed the files in <build>/p/rts and amended the rts configure (for timezone - see my other post) and rebuilt stuff, the error seems to have disappeared.
You mean without the addition of `#define flag_iso ...'? That would be strange again, since I can actually see the cause of the problem (on affected targets).
IIRC, yes - without adding anything. Indeed, I don't seem to be able to find flag_iso anywhere now ("grep -i -w -R flag_iso *" revealed nothing, starting from the gcc directory).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 19 Oct 2003 at 23:48, Frank Heckenbach wrote:
[...]
After applying the patch, I get this error:
../../gcc/p/lang.c: In function `lang_init': ../../gcc/p/lang.c:487: error: `flag_iso' undeclared (first use in this function)
I see that flag_iso is declared in c-common.h which is specific to C and similar language frontends.
[...]
Well, after I removed the files in <build>/p/rts and amended the rts configure (for timezone - see my other post) and rebuilt stuff, the error seems to have disappeared.
You mean without the addition of `#define flag_iso ...'? That would be strange again, since I can actually see the cause of the problem (on affected targets).
IIRC, yes - without adding anything. Indeed, I don't seem to be able to find flag_iso anywhere now ("grep -i -w -R flag_iso *" revealed nothing, starting from the gcc directory).
I suppose you used another GCC version then. This issue was about gcc-3.3.1 (haven't tried 3.3.2 yet, but gcc<=3.2.x don't have it).
Frank
Gerrit P. Haase wrote:
Am Dienstag, 23. September 2003 um 02:23 schriebst du:
Gerrit P. Haase wrote:
What is very new in this case or better , which is the correct versin? I have `bison (GNU Bison) 1.875b'.
With this it fails:
<snip> I get the same errors (in fact most of the messages are warnings). If I apply the patch below to 'parse.y' the build goes OK for me. Frank have bison with the same version number but which makes slightly different output.
It should be exactly the same output if he uses bison with the same version number... sigh.
I have applied some patches to bison. I know it's an unfortunate situation. I have sent some patches and reported some issues on the bison lists, but not all of them have been integrated yet (some have been in the CVS version I suppose. I didn't check this in detail -- it would just be extra work for me since that version wouldn't be usable for me until the remaining issues are fixed).
I will stay in touch with the bison developers, and hopefully the issues are solved until the next GPC release. (This last release was a bit hurried due to a Debian deadline, perhaps it wasn't such a good idea after all ...)
Frank
Hallo Frank,
Am Sonntag, 28. September 2003 um 22:29 schriebst du:
Gerrit P. Haase wrote:
Am Dienstag, 23. September 2003 um 02:23 schriebst du:
Gerrit P. Haase wrote:
What is very new in this case or better , which is the correct versin? I have `bison (GNU Bison) 1.875b'.
With this it fails:
<snip> I get the same errors (in fact most of the messages are warnings). If I apply the patch below to 'parse.y' the build goes OK for me. Frank have bison with the same version number but which makes slightly different output.
It should be exactly the same output if he uses bison with the same version number... sigh.
I have applied some patches to bison. I know it's an unfortunate situation. I have sent some patches and reported some issues on the bison lists, but not all of them have been integrated yet (some have been in the CVS version I suppose. I didn't check this in detail -- it would just be extra work for me since that version wouldn't be usable for me until the remaining issues are fixed).
I will stay in touch with the bison developers, and hopefully the issues are solved until the next GPC release. (This last release was a bit hurried due to a Debian deadline, perhaps it wasn't such a good idea after all ...)
More general comments about the GPC project:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
How should I know if the gpc-20030830.tar.gz I fetched is really the latest available? There are no timestamps at the website which would tell me the real last modified date.
Gerrit
Gerrit P. Haase wrote:
It should be exactly the same output if he uses bison with the same version number... sigh.
I have applied some patches to bison. I know it's an unfortunate situation. I have sent some patches and reported some issues on the bison lists, but not all of them have been integrated yet (some have been in the CVS version I suppose. I didn't check this in detail -- it would just be extra work for me since that version wouldn't be usable for me until the remaining issues are fixed).
I will stay in touch with the bison developers, and hopefully the issues are solved until the next GPC release. (This last release was a bit hurried due to a Debian deadline, perhaps it wasn't such a good idea after all ...)
More general comments about the GPC project:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
For all I can tell, this would cause even more confusion because such snapshots most of the time are even less stable to unusable. (Especially these years, when we're fixing a lot of fundamental problems which involve bigger changes. Perhaps it will be different a few years from now when things will roll along nicely with small, localized and independent changes, but that's always a nice dream, and I don't know if/when we'll ever get there.)
E.g., just now I've replaced the lexer with a new, flex based one. Even though I had prepared and unit-tested the new lexer for some time, after putting it in and fixing the most obvious problems I found immediately, I got about 450 test suite failures (which was actually better than I'd expected :-). The next day, there were only 40 failures and one basic problem left -- which still means unusable for practical work. Today I got the test suite running ok, but I expect some more subtle, hidden bugs. (And there are entanglements with upcoming changes in the parser and preprocessor which I've just worked around now, but it may be better to do them right before a new release.)
Now if these intermediate versions were available to the public, I'd expect a lot of bug reports, and I'd probably be busy for the next few weeks reading through them, suggesting partial fixes or work-arounds, and not getting to fix the real problems since my time is also limited.
As I said, such a fundamental change is not rare in GPC currently. Changes involving the parser, preprocessor, automake system, qualified identifiers etc. etc. will be at least so wide-reaching, as well as about 10-20 other changes I did in the last two years.
And when I'm working on smaller changes, I usually do several of them in a row (because running the test suite each time would take too long -- often it finds a small problem or five, so it takes several runs to get it right), so also then the intermediate versions are not so stable. In fact it's rather rare for me to have error-free test suite runs except shortly before a release.
Also, before a release I run the tests on some other systems (since target-specific bugs are not so rare, unfortunately) -- though for alpha releases I don't necessarily fix all the bugs I find there if they're tricky and uncommon enough --, and run some scripts that prepare the download files, web pages etc.
Besides, it's of course much easier to fix a bug I find myself than I'm reported. Even if the bug-report is well-written (which, unfortunately, is not always the case), it often takes some asking back until I can reproduce the problem (of course, each time with some delay, so I have to get back to the context of the problem (mentally) again). So it really, measurably, saves me time if I keep the changes to myself for a while until I find the bug myself. Of course, I can't find all bugs myself, so the bug reports I get after a release are also necessary and helpful. But if I can find 95% (roughly) of the bugs myself, this seems to be much more efficient with my time.
I know that other projects make daily snapshots. But (a) they usually have more developers (we're currently bascially two developers, Waldek and me, and some occasional contributors) and (b) IME they often have a "slightly different" attitude to bug reports (i.e., if they can't reproduce it immediately, or they think it's not important they just ignore it -- or let it gather dust in a bug database which to me often appears like "Ablage P" in German ...)
(And they often have several branches. Of course, this can help against the above-mentioned stability problems, and in some cases (like Linux) this is absolutely essential. But it takes even more work (testing, porting changes between versions and branches, etc.), and we simply don't have the resources to do that -- or rather, all resources we'd allocate to that would be taken away from the actual development.)
Sorry for this little rant, but to make it short: If you mean why I don't make daily snapshots: I don't have the time and I don't like to. If you mean anyone else: Just go ahead and tell us the name of your download server (you can write to gpc-announce, of course) ...
How should I know if the gpc-20030830.tar.gz I fetched is really the latest available? There are no timestamps at the website which would tell me the real last modified date.
Usually, the version number corresponds to the date of last change. This time was an (unfortunate) exception because (at least) two serious bugs had crept into the (over-hurried) release and I wanted to fix the files on the server without going through the regular release preparation (I had almost no time for GPC recently, so otherwise it would have delayed the bug-fixing until this week or so) or change things manually (which surely would have resulted in more problems, especially when done in a hurry).
Frank
Frank Heckenbach wrote:
Gerrit P. Haase wrote:
More general comments about the GPC project:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
For all I can tell, this would cause even more confusion because such snapshots most of the time are even less stable to unusable.
Sorry for this little rant, but to make it short: If you mean why I don't make daily snapshots: I don't have the time and I don't like to. If you mean anyone else: Just go ahead and tell us the name of your download server (you can write to gpc-announce, of course) ...
I think it would be useful to release alphas more frequently (say about one a month). On the other hand I fully agree that released version should have no problems which can be found by routine testing (unless the problem is very hard to fix). It saves a lot of time both for developers and for users.
By the way, if anybody wants to hack gpc (or just is curious) I can show all what I am working on -- but I think that nobody here is interested in buggy code (even if the code passes the test suite).
Frank Heckenbach wrote:
Also, before a release I run the tests on some other systems (since target-specific bugs are not so rare, unfortunately) -- though for alpha releases I don't necessarily fix all the bugs I find there if they're tricky and uncommon enough --, and run some scripts that prepare the download files, web pages etc.
If it is helpful, I would be pleased to test a soon-to-be-released pre-alpha version on Mac OS X. I guess Maurice Lombardi and Prof A Olowofoyeku would be prepared to do the same on their respective platforms also. Another possibility is to release an alpha version like we do now and then, say three weeks later, a beta version with the necessary fixes of reported problems. However, these are just ideas, I don't want to generate extra work for Frank.
Regards,
Adriaan van Os
Hallo Frank,
You wrote:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
For all I can tell, this would cause even more confusion because such snapshots most of the time are even less stable to unusable. (Especially these years, when we're fixing a lot of fundamental problems which involve bigger changes. Perhaps it will be different a few years from now when things will roll along nicely with small, localized and independent changes, but that's always a nice dream, and I don't know if/when we'll ever get there.)
[...]
That is what CVS is good for, you checkout the source, modify it, test it and make it usable and when all work is done, you check your changes in, I don't need a repository where broken code is archived, it should be possible to build sources from CVS every time one checks it out of course. Unstable code does not belong in a repository.
Now if these intermediate versions were available to the public, I'd expect a lot of bug reports, and I'd probably be busy for the next few weeks reading through them, suggesting partial fixes or work-arounds, and not getting to fix the real problems since my time is also limited.
CVS is not thought as working directory, you work in your sand-box and if it runs ok. there, you'll update the CVS tree on the server to get more feedback.
[...]
I know that other projects make daily snapshots. But (a) they usually have more developers (we're currently bascially two developers, Waldek and me, and some occasional contributors) and (b) IME they often have a "slightly different" attitude to bug reports (i.e., if they can't reproduce it immediately, or they think it's not important they just ignore it -- or let it gather dust in a bug database which to me often appears like "Ablage P" in German ...)
If you would make a working CVS repo available then probably more developers will join in? Hopefully you'll find some volunteer who will host a CVS repository and makes it available to the public (I'm sorry, I cannot do this).
Sorry for this little rant, but to make it short: If you mean why I don't make daily snapshots: I don't have the time and I don't like to. If you mean anyone else: Just go ahead and tell us the name of your download server (you can write to gpc-announce, of course) ...
No problem here.
You only need to setup a cron job which does all the work once, all the snapshots are generated automatically then;-)
Gerrit
"Gerrit P. Haase" wrote:
... all content snipped ...
Now that my ISP has the SWEN storm under control, maillist items seem to be arriving again. However I noticed that there is no "reply-to: gpc@gnu.de" field on these recent arrivals, and I had myself configured to have such a field.
This is sent as a reply so you can follow references to a message that arrived here without the field.
Hallo CBFalconer,
Now that my ISP has the SWEN storm under control, maillist items seem to be arriving again. However I noticed that there is no "reply-to: gpc@gnu.de" field on these recent arrivals, and I had myself configured to have such a field.
What is a Reply-To: good for if the mailinglist would overwrite it?
And why don't you start a new thread with this topic (not to say that I consider this as off topic here and on every other list I'm on)?
Gerrit
"Gerrit P. Haase" wrote:
Now that my ISP has the SWEN storm under control, maillist items seem to be arriving again. However I noticed that there is no "reply-to: gpc@gnu.de" field on these recent arrivals, and I had myself configured to have such a field.
What is a Reply-To: good for if the mailinglist would overwrite it?
And why don't you start a new thread with this topic (not to say that I consider this as off topic here and on every other list I'm on)?
I suspect Frank just fixed it, because your reply came with the reply-to field filled in.
I put it in the thread because I did not know if it was something due to your messages alone or was a general problem. I said as much in my message, but you snipped it.
The purpose of setting the reply-to on delivery from the list is so that replies go to the list, and not just to the originator.
To add some context, Chuck wrote in 3F771998.851C2C9@yahoo.com in comp.lang.pascal.misc (not bounced to this list AFAIK, so I'm quoting it here):
This beast [SWEN worm] is playing havoc with my e-mail. As a result I have been getting nothing from the GPC list. Most of the junk I receive goes to a spam filter setup on my ISP, but I suspect I have transmitted things from the GPC list.
Would it be possible to annotate the subject lines to indicate the source? Something like "[GPC] <original subject>". This will make them easy to recognize (and possibly remove from the spam filter).
The only data I have available to me when selecting from the mess is the sender and the subject.
I suppose you mean the `From:' header. Whereas the `Sender:' header should always be `gpc-owner@gnu.de', and the `From ' envelope should contain `gpc-owner+M3054@gnu.de' (with varying numbers), so if you have those available, you should be able to filter on them.
Here he wrote:
"Gerrit P. Haase" wrote:
Now that my ISP has the SWEN storm under control, maillist items seem to be arriving again. However I noticed that there is no "reply-to: gpc@gnu.de" field on these recent arrivals, and I had myself configured to have such a field.
What is a Reply-To: good for if the mailinglist would overwrite it?
And why don't you start a new thread with this topic (not to say that I consider this as off topic here and on every other list I'm on)?
I agree that you should have started a new thread. Off-topic ... well, any lists needs to be concerned with its administration now and then I suppose ...
I suspect Frank just fixed it, because your reply came with the reply-to field filled in.
I didn't change anything.
I put it in the thread because I did not know if it was something due to your messages alone or was a general problem. I said as much in my message, but you snipped it.
The purpose of setting the reply-to on delivery from the list is so that replies go to the list, and not just to the originator.
I've talked with Anja (the list administrator) about it. The two issues (adding `Reply-To:' and subject prefixes) are both FAQs on many mailing lists, and both controversial. I don't want to go into the details here -- the arguments can be found elsewhere on the net, e.g. http://www.unicom.com/pw/reply-to-harmful.html.
Anyway, the list manager (majordomo 2) allows setting them per user. To change them, send a mail to majordomo@gnu.de containing the line for the respective command (with your subscription address substituted, of course):
set gpc replyto my@address.foo
set gpc prefix my@address.foo
set gpc noreplyto my@address.foo
set gpc noprefix my@address.foo
So anyone of you can set them as you prefer. The only thing to decide is what the default for new subscribers should be. Since this issue has come up a few times, I'd prefer to settle it finally now. So I suggest the following:
- Vote now what the default should be.
- Set these defaults for future subscribers. Anja has indicated that she's willing to do that if there's a clear majority. In any case, this will *not* change the settings for all who are subscribed already (because we can't tell who explicitly wants them off). So you have to change them yourself, using the commands above, anyway.
- Add a note about the default and how to change it in the welcome mails and on the web site.
To vote, send one or two of the following lines to gpc-vote@gnu.de within two weeks (i.e., until 19 October 2003, 05:30 UTC). Only one vote per person!
VOTE REPLYTO or VOTE NOREPLYTO
VOTE PREFIX or VOTE NOPREFIX
Frank
On 5 Oct 2003 at 7:28, Frank Heckenbach wrote:
To add some context, Chuck wrote in 3F771998.851C2C9@yahoo.com in comp.lang.pascal.misc (not bounced to this list AFAIK, so I'm quoting it here):
Would it be possible to annotate the subject lines to indicate the source? Something like "[GPC] <original subject>".
I suppose you mean the `From:' header. Whereas the `Sender:' header should always be `gpc-owner@gnu.de'....
Indeed, filtering on:
Sender: gpc-owner@gnu.de
...reliably indicates GPC list mail.
In any case, this will *not* change the settings for all who are subscribed already (because we can't tell who explicitly wants them off).
Given that posts from current subscribers will not be prefixed, unless each subscriber changes his or her preference, prefix filtering will always be unreliable. Even electing to have prefixes added for new subscribers would seem to result in some posts having prefix characters and some posts not, again making prefix filtering unreliable.
Unless prefixing is forced on all subscribers -- new and current -- it will simply add "noise" to the subject lines of some list messages. For a workable solution, I'd recommend filtering on "Sender" and forgetting about prefixes.
-- Dave
"J. David Bryan" wrote:
On 5 Oct 2003 at 7:28, Frank Heckenbach wrote:
To add some context, Chuck wrote in
Would it be possible to annotate the subject lines to indicate the source? Something like "[GPC] <original subject>".
I suppose you mean the `From:' header. Whereas the `Sender:' header should always be `gpc-owner@gnu.de'....
Indeed, filtering on:
Sender: gpc-owner@gnu.de
...reliably indicates GPC list mail.
In any case, this will *not* change the settings for all who are subscribed already (because we can't tell who explicitly wants them off).
Given that posts from current subscribers will not be prefixed, unless each subscriber changes his or her preference, prefix filtering will always be unreliable. Even electing to have prefixes added for new subscribers would seem to result in some posts having prefix characters and some posts not, again making prefix filtering unreliable.
Unless prefixing is forced on all subscribers -- new and current -- it will simply add "noise" to the subject lines of some list messages. For a workable solution, I'd recommend filtering on "Sender" and forgetting about prefixes.
You mistake my purpose.
First, I assume that the set prefix only applies to mail delivered to me from the list.
The reason is that my ISP is delivering caught spam to a different directory, where I have three days to check it. All I see is the from: and the subject: data, without laboriously reading each spam message.
Since I was delivering large quantities of mail to the ISPs spam detection system recently, it is quite possible something from various mailing lists got in. The only way to fix that, if it has occured, is to examine the stuff caught, via from: and subject: and I have to do that over their web based mail server. This avoids ever transmitting it back and forth to my machine over slow links.
I did not realize that the sender: field universally marked the list. That is much simpler than the filters I now use.
On 6 Oct 2003 at 17:29, CBFalconer wrote:
You mistake my purpose.
Perhaps I did. I assumed that your purpose was to unambiguously identify messages from the list.
All I see is the from: and the subject: data, without laboriously reading each spam message.
I did not realize that you were "filtering" visually. I can see where a prefix on the "Subject" line would help in this case.
Related to this: per Frank's note, I had altered my settings to have the reply-to set to the list. However, in responding to this message, the reply-to was automatically set to Chuck's address. I gather that the list manager defers to the message originator's choice (i.e., a "Reply-To" header in the original message) rather than mine (i.e., I want all replies from me to go to the list, unless explicitly overridden). That's rather unfortunate, as it means that I still have to check the response address carefully to avoid misdirecting my mail.
-- Dave
J. David Bryan wrote:
In any case, this will *not* change the settings for all who are subscribed already (because we can't tell who explicitly wants them off).
Given that posts from current subscribers will not be prefixed, unless each subscriber changes his or her preference, prefix filtering will always be unreliable.
No, the settings go by recipient, not sender. (Of course, quotes from a user who's set the prefix will have the prefix as well, so those who haven't set the prefix will get such quoted prefixes as well, but those who have set the prefix option should always get one.)
Frank
On 7 Oct 2003 at 0:18, Frank Heckenbach wrote:
No, the settings go by recipient, not sender.
I misunderstood that. Yes, that would allow reliable filtering on the recipient's end.
(Of course, quotes from a user who's set the prefix will have the prefix as well, so those who haven't set the prefix will get such quoted prefixes as well, but those who have set the prefix option should always get one.)
Is the mailing list software smart enough to detect a prefix after "Re:", or would a couple of replies back and forth yield "[GPC] Re: [GPC] Re: [GPC] Re: [GPC] Problem"?
-- Dave
J. David Bryan wrote:
Is the mailing list software smart enough to detect a prefix after "Re:", or would a couple of replies back and forth yield "[GPC] Re: [GPC] Re: [GPC] Re: [GPC] Problem"?
I suppose it's smart enough, but I haven't tested this.
Related to this: per Frank's note, I had altered my settings to have the reply-to set to the list. However, in responding to this message, the reply-to was automatically set to Chuck's address. I gather that the list manager defers to the message originator's choice (i.e., a "Reply-To" header in the original message) rather than mine (i.e., I want all replies from me to go to the list, unless explicitly overridden). That's rather unfortunate, as it means that I still have to check the response address carefully to avoid misdirecting my mail.
Also here I'm not sure. What I'd prefer personally in this case is to put both addresses, the given Reply-To and the list address, in the final Reply-To header, but I don't know if/how this can be achieved.
I'm copying this mail to Anja, perhaps she can tell more.
Frank
Frank Heckenbach wrote:
... snip ...
Also here I'm not sure. What I'd prefer personally in this case is to put both addresses, the given Reply-To and the list address, in the final Reply-To header, but I don't know if/how this can be achieved.
I'm copying this mail to Anja, perhaps she can tell more.
I don't think this would be wise. The people who want the reply-to munged don't want to reply directly to the writer, in general. On the rare occasion when they do, they can extract a suitable address from the from: header, or possibly a sig line.
Hello,
Is the mailing list software smart enough to detect a prefix after "Re:", or would a couple of replies back and forth yield "[GPC] Re: [GPC] Re: [GPC] Re: [GPC] Problem"?
I suppose it's smart enough, but I haven't tested this.
Majordomo understands a "Re: [GPC]" and removes it. It does not understand "AW: [GPC]".
Also here I'm not sure. What I'd prefer personally in this case is to put both addresses, the given Reply-To and the list address, in the final Reply-To header, but I don't know if/how this can be achieved.
MJ2 leaves a reply-to set by the sender intact. It will only add the reply-to header if none is provided.
I'm copying this mail to Anja, perhaps she can tell more.
HTH,
Anja
Anja Gerwinski wrote:
... snip ...
MJ2 leaves a reply-to set by the sender intact. It will only add the reply-to header if none is provided.
I can see why you do so, but that rather defeats the purpose (to me) of having the reply-to set in the first place. I still have to be alert enough to detect that my reply is NOT going to gpc@gnu.de, which I often am not.
Hi Chuck,
CBFalconer wrote on Oct 07, 2003 at 04:42PM -0400:
Anja Gerwinski wrote:
... snip ...
MJ2 leaves a reply-to set by the sender intact. It will only add the reply-to header if none is provided.
I can see why you do so, but that rather defeats the purpose (to me) of having the reply-to set in the first place.
There is also an option that you want to reply-to header always set. However, I don't have time to look it up. I can send you all the help files for Majordomo if you want to look it up yourself. (It is not in the same category as "set replyto" and "set prefix". It is a setting available to the list maintainer only, but I suppose it would be possible to allow users to set it themselves.)
I still have to be alert enough to detect that my reply is NOT going to gpc@gnu.de, which I often am not.
In mutt, I use "list reply" for that purpose. Then I can be sure my reply goes to the (predefined) list address.
Best wishes,
Anja
I wrote:
: To vote, send one or two of the following lines to gpc-vote@gnu.de : within two weeks (i.e., until 19 October 2003, 05:30 UTC). Only one : vote per person!
Here are the results of the vote:
REPLYTO 0 NOREPLYTO 3 PREFIX 1 NOPREFIX 2
Well, thanks for the overwhelming particpation.
Frank
Hallo CBFalconer,
What is a Reply-To: good for if the mailinglist would overwrite it?
The purpose of setting the reply-to on delivery from the list is so that replies go to the list, and not just to the originator.
FWIW, that is exactly what I dislike, but this is just my private opinion.
I am hosting some lists too and the consensus on the list was to use the Reply-To: to point back to the list, but I dislike this feature, and I dislike democratic decisions.
The most mafor lists I'm reading like gcc, perl5-porters, cygwin and other high volume lists don't set a Reply-To:, so why should gpc do it?
Gerrit
Gerrit P. Haase wrote:
You wrote:
Why isn't it possible to have a recent download via CVS or snapshots on a daily basis? Why is it that difficult with GPC?
For all I can tell, this would cause even more confusion because such snapshots most of the time are even less stable to unusable. (Especially these years, when we're fixing a lot of fundamental problems which involve bigger changes. Perhaps it will be different a few years from now when things will roll along nicely with small, localized and independent changes, but that's always a nice dream, and I don't know if/when we'll ever get there.)
[...]
That is what CVS is good for, you checkout the source, modify it, test it and make it usable and when all work is done, you check your changes in,
Well, that's just what I do before an alpha release now. As I said, this testing etc. takes some extra time, so I can't do it too often. I.e., with CVS I'd just do a checking every 1-2 months or so, so it would be the same (except for the up-/download method).
I don't need a repository where broken code is archived, it should be possible to build sources from CVS every time one checks it out of course. Unstable code does not belong in a repository.
Agreed. (Unfortunaly, my working code is (more or less) broken most of the time ...)
Adriaan van Os wrote:
Frank Heckenbach wrote:
Also, before a release I run the tests on some other systems (since target-specific bugs are not so rare, unfortunately) -- though for alpha releases I don't necessarily fix all the bugs I find there if they're tricky and uncommon enough --, and run some scripts that prepare the download files, web pages etc.
If it is helpful, I would be pleased to test a soon-to-be-released pre-alpha version on Mac OS X. I guess Maurice Lombardi and Prof A Olowofoyeku would be prepared to do the same on their respective platforms also.
Might be a good idea.
BTW, I do test under DJGPP, though with a cross-built (native DJGPP compiler) GPC and under Linux DosEmu -- occasionally that makes a difference, but usually not too big. That I didn't catch the gcc-3.3 defines problem is just because I didn't test with gcc-3.3 at all before the last release.
Another possibility is to release an alpha version like we do now and then, say three weeks later, a beta version with the necessary fixes of reported problems. However, these are just ideas, I don't want to generate extra work for Frank.
This is a bit extra work, especially when I want to start major changes after an alpha (which I'm doing right now, so for this release, it's too late), but perhaps we should try this after the next release. Since I want to slowly move towards a 2.2 release, we'll need a beta version sometime, anyway.
Perhaps you do the testing on your systems after the alpha release (mostly as you do now), so I won't have to make a pre-alpha, alpha and later beta version, just an alpha and a beta then.
If this works out, I figure we can have some alpha/beta pairs, then a few release candidates and a 2.2 sometime next year.
Frank
On 5 Oct 2003 at 6:31, Frank Heckenbach wrote:
[...]
This is a bit extra work, especially when I want to start major changes after an alpha (which I'm doing right now, so for this release, it's too late), but perhaps we should try this after the next release. Since I want to slowly move towards a 2.2 release, we'll need a beta version sometime, anyway.
Perhaps you do the testing on your systems after the alpha release (mostly as you do now), so I won't have to make a pre-alpha, alpha and later beta version, just an alpha and a beta then.
If this works out, I figure we can have some alpha/beta pairs, then a few release candidates and a 2.2 sometime next year.
That seems like a good idea. If Gerrit wants to take over the Cygwin binaries, then that is fine too - in which case I can stop putting new Cygwin stuff in my contrib directory and I can concentrate on Mingw ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Hallo Prof,
That seems like a good idea. If Gerrit wants to take over the Cygwin binaries, then that is fine too - in which case I can stop putting new Cygwin stuff in my contrib directory and I can concentrate on Mingw ...
Alright, I am also the new maintainer of Cygwin GCC and I'll probably include the Pascal frontend in the distribution.
Gerrit
Hi Gerrit
That seems like a good idea. If Gerrit wants to take over the Cygwin binaries, then that is fine too - in which case I can stop putting new Cygwin stuff in my contrib directory and I can concentrate on Mingw ...
Alright, I am also the new maintainer of Cygwin GCC and I'll probably include the Pascal frontend in the distribution.
That is good news. If the main distro includes Pascal, that would make life easier for everyone else.
PS: perhaps you can look at os-hacks.h and the Cygwin sections of it. It would be wonderful if those things could be sorted out in the main distro so that the os-hacks stuff would be unnecessary (but I wish you luck in trying to get the stuff accepted).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Hallo Waldek,
Am Mittwoch, 17. September 2003 um 01:46 schriebst du:
[...]
That is easy: after unpackig the tarball do 'touch parse.h'. Otherwise make tries to re-make parse.c and parse.h, and that requires very new version of bison. In fact only Frank has the correct version (I have one which works after I hand-edit the output).
After doing this I get stackdumps now in rts:
make[3]: Entering directory `/tmp/gcc/gcc-build/gcc/p/rts' echo '{ rts-config.inc. Generated automatically from rts-config.h. }' > rts-config.inc sed -e 's,/*,{,g;s,*/,},g;s,^[ \t]*#(.*),{$\1},' rts-config.h >> rts-config.inc ../.././xgpc -B../.././ -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 --unit-path=/tmp/gcc/gcc-3.3.1/gcc/p/rts --automake --print-needed-options "/tmp/gcc/gcc-3.3.1/gcc/p/rts/endian.pas" 2> "needed-options" || true Signal 11 if grep -v '^--' "needed-options" > /dev/null; then echo "needed-options: `cat "needed-options"`" >&2; rm -f "needed-options"; false; else true; fi ../.././xgcc -B../.././ -B/usr/i686-pc-cygwin/bin/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 /tmp/gcc/gcc-3.3.1/gcc/p/rts/rts.c ../.././xgcc -B../.././ -B/usr/i686-pc-cygwin/bin/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 /tmp/gcc/gcc-3.3.1/gcc/p/rts/file.c ../.././xgcc -B../.././ -B/usr/i686-pc-cygwin/bin/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 /tmp/gcc/gcc-3.3.1/gcc/p/rts/rts-va.c ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 --unit-path=/tmp/gcc/gcc-3.3.1/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /tmp/gcc/gcc-3.3.1/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /tmp/gcc/gcc-3.3.1/gcc/p/rts/rtsc.pas ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 --unit-path=/tmp/gcc/gcc-3.3.1/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /tmp/gcc/gcc-3.3.1/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /tmp/gcc/gcc-3.3.1/gcc/p/rts/string.pas Signal 11 make[3]: *** [string.o] Error 139 make[3]: Leaving directory `/tmp/gcc/gcc-build/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/tmp/gcc/gcc-build/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/tmp/gcc/gcc-build/gcc' make: *** [bootstrap] Error 2
Gerrit
-
Adriaan van Os -
Anja Gerwinski -
CBFalconer -
Frank Heckenbach -
Frank Heckenbach -
Gerrit P. Haase -
J. David Bryan -
Prof A Olowofoyeku (The African Chief) -
Russell Whitaker -
Waldek Hebisch