Nick Cremelie wrote:
Hi all,
Apparently I'm on the list now (right, administrator?)...
If you receive this mail twice, then you're on.
Klaus suggested:
So here you go, abort! Who messed around with the language_string recently? This should be rather trivial to fix for Peter. The actual bug is in p/parse.c and is even documented. Just take the language_string hack for _IBMR2 out and your compiler should work. The "bug" is around line 360 in p/parse.c. Of course, to fix this, we need to change p/parse.y, being the source for parse.c. Nick, do you have bison installed on your machine? If not, you have to change p/parse.c by hand for a quick fix, and don't apply the p/parse.y patch below.
Yes I have bison. I changed p/parse.y the way you suggested (I can't use `patch', on aix `patch' doesn't seems to behave the way it should. BTW, the gpc patches that needed to be applied in GPC: configure didn't apply them because of this problem. This in turn caused my first linking problem that Peter related to a VPATH problem, but which was not. I was eventually able to apply the patches by moving the files to a linux machine, using `patch' and then moving back the fixed files to the aix machine. So in future releases of gpc this patch problem with aix should be fixed -- but this all aside and between brackets :-)
Well, it is possible that it was due to my crappy patch. I should have passed -c to diff, and even AIX patch should understand the patch then. Another option is to install GNU patch, which is (at least the current, fairly stable version) heaps better than any proprietary patch program.
Anyway, I've just looked at the gpc diffs, and they seem to be in unified diff format, which isn't uderstood by all patch programs. Maybe Peter should change this back to normal context diffs. They're larger but more portable.
To continue: I resumed gmake and now the rts part of p has been built! I got a few errors which did not cause s stop of gmake, I'm not sure if they are a problem (should I worry about them?):
I would worry about them. But it's possible that they go away after you installed gpc and re-do the gpc compilation. You can check if something is wrong with the gpc driver program if you start it with option -v for the program issuing the errors. There should be either a "-D__BYTES_BIG_ENDIAN__" or a "-D__BYTES_LITTLE_ENDIAN__" in the command line for the preprocessor. Similarly for BITS and WORD.
I wouldn't trust gpc until there are no #error lines left. Part of the problem seems to be that the automake feature doesn't pass the error code of a failed sub-compile command back to the calling make program.
Peter: can you put this on the automake todo list?
[...]
Anyway, at this very moment gmake has finished the build and I will now make the stage2 compiler, install and run some tests (fingers crossed...). I'll keep you all informed on how this evolves.
Well, there is no real stage2 for gpc, as it's written in C. The code *generated* by gcc (in this case gpc) shouldn't change at all for any stage. The code of gcc of course changes, as it's built with different compilers and options.
There are some build process problems with the gpc rts currently, which can be resolved by ignoring the build errors in the first build, and installing the compiler anyway (which may not be fully functional in this state). Then do a "make clean" on the gcc source tree and rebuild gpc. There should be no error messages in the second build (apart from some "error code xx ignored" messages from make).
I should start testing gpc a bit more thoroughly, as we're going to use some version of it in the upcoming ACM South West European Programming Contest this year. It's just that I'm short on time and drive space, as our uni "only" gives us 24 megs space. Doing work in some /tmp dir isn't much fun.
Klaus