Hi, (note that I'm pretty new to GPC, so my advice isn't official)

On Fri, Feb 12, 2010 at 8:03 AM, Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC robert.hodges.ctr@hill.af.mil wrote:

I downloaded GPC from this web site: http://www.gnu-pascal.de/binary/

I downloaded the binary version of GPC and GCC bundled together in RPM format for Linux.  I specifically need GPC 2.1 with GCC 2.95, the file called gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz.

While I personally like 2.95.3 (from 2001) because of its speed and relatively smaller size vs. newer GCCs, it's definitely obsolete (esp. lacking decent C++ or C99 support). On my "old" computer (which also has old 2.95.3 for comparison) I just recently installed GPC 20070904 with GCC 3.4.4 (DJGPP).

I was greatly relieved to find this web site, and that binaries were available in the versions I needed.

Problem is, when I install the RPM, it looks like the “binary” GCC compiler is incomplete – no actual binaries, compiler not ready to run.

I don't even see any .RPMs there, only .tar.gz.

Since I personally think the most ridiculous thing in the world is a compiler that won’t work until it’s compiled by another compiler, can

Par for the course, I'm afraid, esp. for Linux dudes. I've never tried, but it shouldn't be that hard. You can get the latest patches here:

http://www.math.uni.wroc.pl/~hebisch/gpc/

anybody point me in the right direction to either an installable package of GPC 2.1, GCC 2.95 for Linux or tell me how to get this particular backage to work?

Sorry, I dunno. I'm sure somebody knows, but this mailing list does indeed seem inactive these days.

I guess using DOSEMU + DJGPP is out of the question? ;-)

Major thanks in advance to anyone that can help out.  Not sure what to think, the most recent update I can identify on the above web site was 5 years ago.  Anybody out there?

It's not really that old. The latest patch is "only" two years, which is not bad for software. It even (optionally) works with GCC 4.1.2, so that's pretty good. ;-)

P.S. USAF? What, no Ada? ;-)

Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC a écrit :

I downloaded GPC from this web site: _http://www.gnu-pascal.de/binary/_

I downloaded the binary version of GPC and GCC bundled together in RMP format for Linux. I specifically need GPC 2.1 with GCC 2.95, the file called gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz http://www.gnu-pascal.de/binary/gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz.

I was greatly relieved to find this web site, and that binaries were available in the versions I needed.

Problem is, when I install the RPM, it looks like the “binary” GCC compiler is incomplete – no actual binaries, compiler not ready to run. I could be wrong, so if I am, I need someone to help point me in the right direction. I’m a sysadmin who’s installing this software for a developer, which I am not.

Have you noticed that this is not a RPM but a .tar.gz file ? I suppose so In that case have you untarred it below the root / of your system ? (it will install then in /usr/local) In principle I see all binaries and all files needed to run gpc. One problem may be that this compiler uses the system libc, which depends on the linux version of the system you use. This is why everybody here compiles the compiler: it uses autotools to look at what is contained in the libc installed in your particular system ans adapt gpc accordingly.

Since I personally think the most ridiculous thing in the world is a compiler that won’t work until it’s compiled by another compiler, can anybody point me in the right direction to either an installable package of GPC 2.1, GCC 2.95 for Linux or tell me how to get this particular backage to work?

Oh, I am attempting to install and run this package on SuSE Linux Enterprise Server 11.

Major thanks in advance to anyone that can help out. Not sure what to think, the most recent update I can identify on the above web site was 5 years ago. Anybody out there?

everybody here compiles for linux the latest snapshot (which is much better than the old 2.1 version, but you seem to have very peculiar needs) http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2

Maurice

Hi again,

On Fri, Feb 12, 2010 at 10:59 AM, Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC robert.hodges.ctr@hill.af.mil wrote:

I truly appreciate the answers!

Before I continue, I better ask a basic question first:

Will old Pascal code that would be compiled by GCC 2.95.x and GPC 2.1 be compiled by the latest versions (GPC/GCC) without any problems?

There are some minor things that changed (e.g. stricter compliance to standards: goto), but it shouldn't be anything huge. GPC supports a lot of dialects, and I would assume most standard or extended stuff continues to work as-is (since those are well-defined and have remained static over so many years).

Martin Liddle wrote:

In message <E41C0EAA432BCC4882FAA451BBFBA72D0171062D@VFUTMLAO11.Enterprise.afmc.ds.a f.mil>, "Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC" robert.hodges.ctr@hill.af.mil writes

...

I truly appreciate the answers!

Before I continue, I better ask a basic question first:

Will old Pascal code that would be compiled by GCC 2.95.x and GPC 2.1 be compiled by the latest versions (GPC/GCC) without any problems?

I have just gone through a similar exercise. There were a few compilation problems (due to stricter checks and some compiler changes) but also more run time problems due to value range errors which were previously being ignored. It will of course depend on the code but it shouldn't be too big a job.

You can disable the run-time checks (--no-range-checking), but of course, these might indicate actual bugs in the code ... :-)

Frank

Rugxulo wrote:

Okay, now that we have your attention:

1). Why is "--executable-file-name" such a long option to type? Wouldn't "--exe" be more convenient?

Well, we also have "--executable-path". ;-)

Besides, particularly this option (as you state yourself below) is rarely useful to enter by hand (since then "-o foo" does just as well), rather to be put in Makefiles, IDE settings, scripts/bat files, shell aliases, etc., so you (or at least I ;-) don't have to type it very often, even when compiling directly from the command line:

alias gpc="gpc --executable-file-name"

2). DJGPP has a habit of making both "blah" and "blah.exe" when you type "gpc blah.pas -o blah". This also affects your GP program. It's really only useful with *nix makefiles (so the target and file will be recognized), but it's pretty useless and annoying otherwise.

AFAIR, "blah" is the COFF executable which can be called from other DJGPP programs, and "blah.exe" is prefixed with a DOS loader (which is done by the "stubify" program), so it can be called from plain DOS programs as well. So depending on your needs, either or both may be useful.

But it's been long since I've used DJGPP, so in case this was inaccurate or incomplete, Maurice will correct me, I hope.

Frank

Hi,

On Mon, Feb 15, 2010 at 4:11 PM, Frank Heckenbach ih8mj@fjf.gnu.de wrote:

Rugxulo wrote:

...

1). Why is "--executable-file-name" such a long option to type? Wouldn't "--exe" be more convenient?

Well, we also have "--executable-path". ;-)

Doh! ;-)

...

2). DJGPP has a habit of making both "blah" and "blah.exe" when you type "gpc blah.pas -o blah". This also affects your GP program. It's really only useful with *nix makefiles (so the target and file will be recognized), but it's pretty useless and annoying otherwise.

AFAIR, "blah" is the COFF executable which can be called from other DJGPP programs,

Honestly, nobody uses plain COFF files anymore. That's a relic from when a separate GO32.EXE was needed (DJGPP v1). But DJGPP can "call" (run) either plain COFF or .EXEs anyways.

and "blah.exe" is prefixed with a DOS loader (which is done by the "stubify" program), so it can be called from plain DOS programs as well. So depending on your needs, either or both may be useful.

But it's been long since I've used DJGPP, so in case this was inaccurate or incomplete, Maurice will correct me, I hope.

You're right in that it used to be that way. But somewhere along the line it changed. I'm not sure if it's correct, but I *think* BinUtils (e.g. LD) handles it differently now. At least, using DJGPP 2.04, GCC 4.4.2, LD 2.19.1, 'gcc -s -O blah.c -o blah" (simple "Hello, World!" example) produces "blah" and "blah.exe" that are 100% identical (with stub, i.e. both in .EXE format).

Hi,

On Tue, Feb 16, 2010 at 11:45 AM, Maurice Lombardi Maurice.Lombardi@ujf-grenoble.fr wrote:

In fact for that reason, in my personal works I always use the option -o blah.exe. This causes no extra typing because I work in an editor able to launch a compiler with a single click through a script like

#! /bin/sh echo $MSYSTEM gp $(basename "$1" | tr [A-Z] [a-z]) \        -o $(basename "$1" | sed -e 's/(.*).[^.]*$/\1.exe/') \        $2 -march=prescott \        --unit-path=. --unit-path=c:/lombardi/$MSYSTEM/gpc/pascal_u \        --unit-path=c:/$MSYSTEM/units \        --unit-destination-path=c:/lombardi/$MSYSTEM/o \        `head -n 1 "$1" | sed -e '/^[^"]*$/d;s/^[^"]*"//;s/"[^"]*$//'` \        2>&1 | sed ':1;s,/[^/.][^/]*/../,/,;t 1'

Whew! Perl, where are you when we need you? :-) Anyways, you could probably also use sed instead of tr and head; that would be cleaner, IMHO. But I'm not very *nix savvy, so who cares. ;-)

$2 is --autobuild or nothing

--autobuild even when using GP? Or was that meant to be "gpc"?

As editor I have used in DOS/Windows TextPad, FPE, Context, in Linux gedit, SCite .... These editors (at least those I use now) generate an error buffer and are able to open directly the proper file and put the carret at proper place when clicking on an error message. Very probably there are many others (I never tried OS X for example), and many are free.

For the record, I was unable to figure out compilation from within PENG. Besides, it (DOS version) whines upon startup in NT (Vista), something about printer or something silly like that.

Normally I just use TDE, which isn't really good at capturing error messages, but it does have a quasi-method for supporting such (execute "redir -eo gpc ...", capture output into window, press Ctrl-F7).

Another better option is GNU Emacs 23.1, which indeed compiles and works fine for DJGPP again, so "M-x compile" and " C-x ` " both work as expected (or mouse). Both have Pascal syntax highlighting (although Emacs actually has separate pascal.el and delphi.el). Of course, there is still no standard .ZIP package for 23.1 yet (I have to make one for them!), so that's annoying (180 MB sources unpacked, even the main .EXE is 8 or 9 MB, heh. I made a slim install for myself using "only" 12 MB, woot!).

Rugxulo wrote:

On Tue, Feb 16, 2010 at 11:45 AM, Maurice Lombardi Maurice.Lombardi@ujf-grenoble.fr wrote:

...

In fact for that reason, in my personal works I always use the option -o blah.exe.

Well, GPC actually appends TARGET_EXECUTABLE_SUFFIX which can be set by the backend target specification. I assume it's not set in the DJGPP backend, but I don't know why. Historically it was because there was reason for the COFF file; if that's no more the case, it could have been set by default, AFAICS. (That would be a matter for the GCC developers, in particular for the DJGPP backend.)

If you want to hack it yourself, you can probably just insert something like

#ifdef __DJGPP__ #define TARGET_EXECUTABLE_SUFFIX ".exe" #endif

near the start of p/module.c and rebuild GPC (untested).

...

This causes no extra typing because I work in an editor able to launch a compiler with a single click through a script like

#! /bin/sh echo $MSYSTEM gp $(basename "$1" | tr [A-Z] [a-z]) \        -o $(basename "$1" | sed -e 's/(.*).[^.]*$/\1.exe/') \        $2 -march=prescott \        --unit-path=. --unit-path=c:/lombardi/$MSYSTEM/gpc/pascal_u \        --unit-path=c:/$MSYSTEM/units \        --unit-destination-path=c:/lombardi/$MSYSTEM/o \        `head -n 1 "$1" | sed -e '/^[^"]*$/d;s/^[^"]*"//;s/"[^"]*$//'` \        2>&1 | sed ':1;s,/[^/.][^/]*/../,/,;t 1'

Whew! Perl, where are you when we need you? :-) Anyways, you could probably also use sed instead of tr and head; that would be cleaner, IMHO. But I'm not very *nix savvy, so who cares. ;-)

Unix says, the right tool for the job.

Why use perl when awk will do, or awk when sed will do, or sed when tr or grep will do (at least that's my principle) ...

For the record, I was unable to figure out compilation from within PENG. Besides, it (DOS version) whines upon startup in NT (Vista), something about printer or something silly like that.

Since PENG is slightly OT here, I'll keep my answer short. For more discussion, please PM (f.heckenbach@fh-soft.de) or the PENG mailing list (see http://fjf.gnu.de/peng/ under "Contact").

PENG should support GPC compilation, ideally simply by pressing F9. Options can be set under "Options/Pascal". "Options/Pascal/Show sample GPC command line" will show what it will actually use. If you don't get along with this, you can also enter a command under "Options/Try a tool" (using the current file name as "$EDNAME", appyling file name functions etc., see the online help), and if it works for you, you can permanently define it as a tool under "Options/Tools".

About the printer, do you get: "file 'prn' cannot be opened for writing"? (And yes, I agree that accessing the printer via a device file is silly, but that's the way it is/was under Dos.) After pressing Esc, will it work normally? (If that's all, I could probabably get rid of this somehow.)

Frank