Is GPC dead?

Paul Isaacs paul at
Fri Dec 30 08:11:25 CET 2016

On 29/12/16 07:15 PM, John L. Ries wrote:
> In my humble opinion, GPC should continue to be a native Pascal compiler,
> not a translator.  It should be updated to use the current GCC back ends
> (Waldek has done some of this in the past and I accept his
> characterization of the process; but I think it's necessary if GPC is to
> continue to be viable); and the goal should still be to get that aspect of
> the code completely up to date so that GPC can be added to GCC.  And I
> think it highly important that it be made easy to create binary packages
> (I can probably devote some time to this, starting with a SlackBuild
> script, but it will go quicker if more than one person is doing it,
> especially since for me it would be a learning experience) and do whatever
> else can be reasonably done to get GPC into people's hands (to including
> making Linux, Windows, and OSX builds available for download from the
> website), remembering that it appears to have completely disappeared from
> Linux distros, and extant collections of UNIX toys.
I probably qualify as the least competent person here to comment. But I 
am too old to worry about embarrassing myself.

Reading the comments I am left with the impression that GPC is being 
left behind by ongoing changes to GCC. If that is so can a case be made 
for bringing it "up to date" if it is only going to fall behind again 
without constant maintenance?

Would it make sense to aim to reduce GPC's external dependencies in 
order to reduce the level of maintenance required?

How much of the maintenance problem is related to trying to make GPC run 
on multiple platforms? Is it worth considering reducing it to an 
elf/intel only output?

Are ifdefs enemy number 1? I have just built gcc-3.4.4 and gpc20060325 
on Q4OS linux. Various includes had to be found , ifdefs in rts.c dealt 
with and the usual missing ctr.o files moved to get a build.

Would it be profitable to rework the code base to get rid if as many 
ifdefs as possible and put all the required includes in the source 

It seems that the GCC backend is also a source of considerable grief. 
Could a gpc specific rtl backend be produced that was stable and didn't 
require never ending maintenance?

Is it even possible to build GPC so that it would be both stable and 
useful over time?

I have a libusb binding and a P2104 ( usb->serial chip ) binding, a usb 
mic stereo recording pgm and a microchip pic18f programmer written in GPC.

I like the language. It is a shame it isn't used more.

Would making it a project on SourceForge make sense?


Paul Isaacs

More information about the Gpc mailing list