Hi!
just subscribed, so for now it's probably the best solution to send me a direct carbon copy, too.
I downloaded gpc-980511.tar.gz, integrated it into gcc-2.8.1, ran configure and "make LANGUAGES=pascal", as suggested by the docs.
The make run didn't manage to compile the runtime library, because it uses the --automake option. It tries to compile some dependent modules, but fails, because there is no executable on the system called gpc yet:
./../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/scratch/s_kespen/gcc-2.8.1/p/rts/../.. -I/scratch/s_kespen/gcc-2.8.1/p/rts/../../config rts-move.p gpc1: installation problem, cannot exec `gpc': No such file or directory gpc1: gpc exited with status 255 gpi-hash.c:329: failed assertion `rp == 0' xgpc: Internal compiler error: program gpc1 got fatal signal 6 make[1]: *** [rts-move.o] Error 1 make[1]: Leaving directory `/scratch/s_kespen/gcc-2.8.1/p/rts' make: *** [libgpc.a] Error 2
I worked around by just doing a "make install", giving me a half-working installed gpc. I reran the gpc build, this time with success.
So currently if you start from scratch, you need good two runs to get gpc working. This isn't the ideal situation, but changing it would require a few substantial changes all over the place. You need some means of passing the name of the compiler driver down to the compiler. Then it would be easy to change the code in module.c to accommodate for the different location and name of xgpc. Generally it shouldn't be necessary for gpc to be in the PATH. There's no reason why /some/path/to/my/private/gpc should fail, while just gpc works.
There has to be some means of keeping -B and -V options given to gpc initially, too. Otherwise it can be painful to use an different gpc version or a cross-compiler, like in this case a not installed compiler version.
Anyway, to summarise all this - building gpc doesn't work correctly even if you have gpc installed previously. As long as some older gpc version is potentially used to compile some parts of the RTS, it's wrong. Older gpc versions may have bugs that are already fixed in the current release - this way they can pop up once more.
The automake feature is quite useful as it is, but it needs to be polished a bit to make it robust enough for heavy duty work.
Klaus
According to Klaus Espenlaub:
[...] ./../xgpc -B../../ --automake -c -DGPC -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -g -I. -I../.. -I/scratch/s_kespen/gcc-2.8.1/p/rts/../.. -I/scratch/s_kespen/gcc-2.8.1/p/rts/../../config rts-move.p gpc1: installation problem, cannot exec `gpc': No such file or directory [...]
A patch which should solve this problem has recently been posted to this list by Matthias Klose; see the (updated) list archives at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/misc/ .
They will be integrated into the distribution as soon as I have done some tests with them and some "Papierkrieg" (= administrativa) <sigh> have been finished.
The automake feature is quite useful as it is, but it needs to be polished a bit to make it robust enough for heavy duty work.
I agree.
Using `gcclib' should simplify the AutoMake mechanism significantly - and speed it up and make it more robust.
But right now, the most urgent job should be to make the current release of GPC stable enough that it can override the obsolete gpc-2.0 which is still the official version.
Peter
On Thu, 28 May 1998, Peter Gerwinski wrote:
But right now, the most urgent job should be to make the current release of GPC stable enough that it can override the obsolete gpc-2.0 which is still the official version.
Before the official release we should do something about the documentation. It is really poor. Some 160 pages are missing from the language reference. That is definitely too much writing for a single person but with a joint effort it should not be a problem. How about to post the missing sections of the reference to the list?
miklos
-
Klaus Espenlaub -
Miklos Cserzo -
Peter Gerwinski