- Gpc - gnu.de

Re: Bug in UNIT definitions
by Frank Heckenbach 02 Mar '00

02 Mar '00

Jose Oliver Gil wrote: > Hello again, > > Now, I have updated to gpc version 19990118, based > on egcs-2.91.60 19981201 (egcs-1.1.1 release). > > I have found out another bug with this version, > when I define two local variables, with the same > name, in two different units but in the same file, > e.g. > > UNIT TEST1; > INTERFACE > IMPLEMENTATION > var Repeated:integer; > END. > > UNIT TEST2; > INTERFACE > IMPLEMENTATION > var Repeated:integer; > END. > > the following error is displayed > > /tmp/cca09330.s: Assembler messages: > /tmp/cca09330.s:31: Error: Ignoring attempt to re-define symbol > /tmp/cca09330.s:31: Error: Rest of line ignored. First ignored character > is `,'. > > If I am defining the variable Repeated in the implementation zone, > why does the assembler think that it's a re-definition? > Is it a compiler bug? Yes. Multiple units/modules/programs in one source file are not supported perfectly. It will be fixed sometime, but don't hold your breath... For now, it's best to split your sources into separate files. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

install gpc
by Ronald Bianchin 01 Mar '00

01 Mar '00

Hallo! I've a problem with install gpc. After unpack gpc-19990118 I've move the files to /opt/gpc, copy /p/* to gcc/p/* and execute patch -s -p1 < p/diffs/gcc-2.8.1.diff. Now I get the message: -------------------------- |Changes for GCC version 2.8.1 for GNU Pascal 2.1 | |Before applying these diffs, go to the directory gcc-2.8.1 |and use the command | | patch -p1 | |feeding it the following diffs as input. | |*** gcc-2.8.1/Makefile.in.orig Tue Mar 3 02:54:31 1998 |--- gcc-2.8.1/Makefile.in Mon Jan 18 04:14:16 1999 -------------------------- File to patch: What is the problem? Is my path correct? Thank you for your help Ronald -- --------------------------------------- Technisches BÃŒro Bianchin Dipl.Ing.(FH) Ronald Bianchin Am KrÃ¶nerstolln 38, 09599 Freiberg Tel.: 03731/696946, Fax.: 03731/696947 ---------------------------------------

1 0

Bug in UNIT definitions
by Jose Oliver Gil 01 Mar '00

01 Mar '00

Hello again, Now, I have updated to gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release). I have found out another bug with this version, when I define two local variables, with the same name, in two different units but in the same file, e.g. UNIT TEST1; INTERFACE IMPLEMENTATION var Repeated:integer; END. UNIT TEST2; INTERFACE IMPLEMENTATION var Repeated:integer; END. the following error is displayed /tmp/cca09330.s: Assembler messages: /tmp/cca09330.s:31: Error: Ignoring attempt to re-define symbol /tmp/cca09330.s:31: Error: Rest of line ignored. First ignored character is `,'. If I am defining the variable Repeated in the implementation zone, why does the assembler think that it's a re-definition? Is it a compiler bug? Thank you Jose Oliver Gil - mailto: joliver(a)gap.upv.es Grupo de Arquitecturas Paralelas - DISCA Universidad Politecnica de Valencia - Spain

1 0

gpc mistake
by Jose Oliver Gil 29 Feb '00

29 Feb '00

Hello! I am using gpc version 970624(2.7.2.3) and I think there is something wrong. I have one Borland Pascal style unit, with the following text: def.p file: UNIT modul; INTERFACE TYPE CARDINAL = 0..65535; LONGBITSET = SET OF 0..63; IMPLEMENTATION END. and I use it in the following program as I show: test.p file: program test; USES modul; var i:CARDINAL; c:LONGBITSET; begin c:=[1]; i:=1; if (i in c) then writeln('yes'); end. I compile them (gpc -c def.p, gpc test.p) and the following error is displayed: gpc: Internal compiler error: program gpc1 got fatal signal 11 when everything should work fine! what's wrong? Thank you Jose Oliver Gil - mailto: joliver(a)gap.upv.es Grupo de Arquitecturas Paralelas - DISCA Universidad PolitÃ©cnica de Valencia - Spain UNIT modul; INTERFACE TYPE CARDINAL = 0..65535; LONGBITSET = SET OF 0..63; IMPLEMENTATION END. program test; USES modul; var i:CARDINAL; c:LONGBITSET; begin c:=[1]; i:=1; if (i in c) then writeln('yes'); end.

2 1

Re: faq - 2nd version
by Frank Heckenbach 29 Feb '00

29 Feb '00

Andreas Jaeger wrote: > I'm currently beta testing gpc for the next SuSE release. Since I'm > not really using gpc myself, could you help me what I should test, so > that SuSE 6.4 will have a working gpc? > > We're planning to use gpc 19991030 with gcc 2.95.2. > > I just did the following tests with some of the demos: > gromit:/usr/doc/packages/gpc/demos:[0]$ gpc --automake crtdemo.pas > gromit:/usr/doc/packages/gpc/demos:[0]$ ./a.out > > And the output looks fine. I think if this works, the installation is alright, and `make install' should be all that's required, but perhaps Peter can make a definitive statement. > I also run the test suite (installed in /usr/doc/packages/gpc/test) > and got only a few failures: > > TEST constovfl.pas: failed: failed: 0 > TEST fjf149.pas: Failed: 64 > TEST fjf83.pas: failed: Failed > /tmp/cc6RgcsV.s: Assembler messages: > /tmp/cc6RgcsV.s:115: Error: operands given don't match any known 386 instruction > TEST goto4.pas: failed > > > All other tests had an OK printed. I don't think that those failures > are serious, especially since I don't have libgmp installed on my system. Yes. AFAIK, libgmp is an optional package in SuSE, so you might want to specify it as a dependency... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: gpc
by Frank Heckenbach 29 Feb '00

29 Feb '00

Larry Poorman wrote: > I am using S.u.S.E 6.2 but wanted to try the Regular Expresions in > Pascal. So I de-installed the S.u.S.E version and downloaded a binary > and installed it. However when I enter: gpc -v > I get the following message: > > bash-2.03# gpc -v > GPC wrapper script, created by install-gpc-binary > Reading specs from > /usr/local/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.91.60/sp > gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 > release) > ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.1 /usr/lib/crt1.o > /usr/lib/crti > 6-pc-linux-gnulibc1/egcs-2.91.60/crtbegin.o -L > /usr/local/lib/gcc-lib/i586-pc-li > usr/local/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.91.60 > -L/usr/local/lib/gcc-l > s-2.91.60 -L/usr/local/lib -lgpc -lm -lgcc -lc -lgcc > /usr/local/lib/gcc-lib/i586 > 60/crtend.o /usr/lib/crtn.o > /usr/lib/crt1.o(.text+0x36): undefined reference to `main' > > Any suggestion as to what I could do to eliminate the "undefinded > reference to main" message? > > I have been using Borland Pascal for the last ten years (mostly > maintenance work as opposed to development) and therefore am curious as > to how GPC functions as compared to Borland, i.e. what are the TPU, TPP, > TPW equivalents in GPC and how are they linked in? If this is explained > in some part to the documentation just point me in that direction. Several things: - You use the install-gpc-binary script which is needed when installing a binary in a directory other than which it was compiled. This is not usually necessary under Linux (since we offer several binaries suited for different distributions and it's easy to compile GPC yourself under Linux), but it's not necessarily wrong... - The "undefined reference to `main'" problem when calling gpc with `-v' and some more parameters (which are implicitly passed by the install-gpc-binary script here) will be fixed in the next release, but it's not very serious, anyway. As soon as you actually compile a program (i.e., give a file name), it does not occur. - The equivalent of BP's tp[upw] files in GPC are object files (.o) plus interface files (.gpi) (and in the case of EP modules rather than BP units, also .gpm files). The object files are completely compatible with GCC and (at least under Unix systems) just about any other compiler and assembler, so they are linked with the default linker (ld) which is called automatically by GPC when compiling a program. (OTOH, if you just want to compile a unit alone, and not link it, you have to give the `-c' switch.) The .gpi and .gpm files are used by GPC only and are read when compiling a program, unit or module that uses another unit or module. - When compiling a program that uses units, give the `--automake' switch to make GPC compile the units automatically. - For regular expressions you need the rx library. If it isn't installed on your system, you can get it from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: faq - 2nd version
by Andreas Jaeger 29 Feb '00

29 Feb '00

>>>>> Frank Heckenbach writes: Frank> Khimenko Victor wrote: >> 23-Feb-00 15:45 you wrote: >> > Khimenko Victor wrote: >> >> > please mention this is not necessary for Debian GNU/Linux and >> >> > Debian GNU/Hurd. The current gpc can be fetched from www.debian.org >> >> > for the architectures alpha, arm, i386, m68k, sparc and powerpc. >> >> >> >> This is true for KSI-Linux & SuSE as well AFAIK. So IMO to write something >> >> "if you are plan to use version of GPC not included in your distribution then >> >> vetter to build GPC yourself because..." >> >> > Nope. The GPC distribution that comes with SuSE-6.3 is >> > misinstalled. It does not find the standard units (such as >> > CRT). I am getting complaints from users about this regularly. >> >> Hmm. Looks like two-ended sword to me :-) SuSE-6.3 DOES NOT install CRT. >> But 'make install' does not install CRT as well (AFAIK). So I'm not sure if >> only SuSE must be blamed here... >> >> P.S. I mean 'does not install CRT in usable state' of course. You can not just >> 'use CRT;' fire gpc and get working program after `make install'... Frank> Yes, you can if you compile with `--automake' (and have ncurses Frank> installed which shouldn't be a problem under Linux). Frank> The CRT unit (as well as the other units) are installed in source Frank> form which I think is fine for a free compiler, and will be compiled Frank> when needed (using `--automake') with your favourite options Frank> (optimization, debugging, etc.). The problem with SuSE, AFAIUI Frank> (can't check myself) is that either the unit sources are not Frank> installed, or there is some path problem so the installed GPC does Frank> not find them. I'm currently beta testing gpc for the next SuSE release. Since I'm not really using gpc myself, could you help me what I should test, so that SuSE 6.4 will have a working gpc? We're planning to use gpc 19991030 with gcc 2.95.2. I just did the following tests with some of the demos: gromit:/usr/doc/packages/gpc/demos:[0]$ gpc --automake crtdemo.pas gromit:/usr/doc/packages/gpc/demos:[0]$ ./a.out And the output looks fine. I also run the test suite (installed in /usr/doc/packages/gpc/test) and got only a few failures: TEST constovfl.pas: failed: failed: 0 /usr/bin/ld: cannot open -lgmp: Datei oder Verzeichnis nicht gefunden collect2: ld returned 1 exit status TEST dialec3.pas: failed TEST dialec4.pas: OK /usr/bin/ld: cannot open -lgmp: Datei oder Verzeichnis nicht gefunden collect2: ld returned 1 exit status TEST dialec5.pas: failed /usr/bin/ld: cannot open -lgmp: Datei oder Verzeichnis nicht gefunden collect2: ld returned 1 exit status TEST dialec6.pas: failed TEST fjf149.pas: Failed: 64 TEST fjf83.pas: failed: Failed /tmp/cc6RgcsV.s: Assembler messages: /tmp/cc6RgcsV.s:115: Error: operands given don't match any known 386 instruction TEST goto4.pas: failed All other tests had an OK printed. I don't think that those failures are serious, especially since I don't have libgmp installed on my system. Looking over the discussion again, Khimenko mentioned: > Hmm. Looks like two-ended sword to me :-) SuSE-6.3 DOES NOT install CRT. > But 'make install' does not install CRT as well (AFAIK). So I'm not sure if > only SuSE must be blamed here... > > P.S. I mean 'does not install CRT in usable state' of course. You can not just > 'use CRT;' fire gpc and get working program after `make install'... Is there any other command (beside 'make install'[1]) that should be issued? I'm now checking the sources myself Btw. I double checked that the units are installed: /usr/lib/gcc-lib/i386-suse-linux/2.95.2/units /usr/lib/gcc-lib/i386-suse-linux/2.95.2/units/crt.inc /usr/lib/gcc-lib/i386-suse-linux/2.95.2/units/crt.pas /usr/lib/gcc-lib/i386-suse-linux/2.95.2/units/crtc.c /usr/lib/gcc-lib/i386-suse-linux/2.95.2/units/crtc.h [...] Thanks for your help and a great work! Andreas Footnotes: [1] I didn't found anything while RTFMing. -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 0

gpc
by Larry Poorman 28 Feb '00

28 Feb '00

Hello, I am using S.u.S.E 6.2 but wanted to try the Regular Expresions in Pascal. So I de-installed the S.u.S.E version and downloaded a binary and installed it. However when I enter: gpc -v I get the following message: bash-2.03# gpc -v GPC wrapper script, created by install-gpc-binary Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.91.60/sp gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.1 /usr/lib/crt1.o /usr/lib/crti 6-pc-linux-gnulibc1/egcs-2.91.60/crtbegin.o -L /usr/local/lib/gcc-lib/i586-pc-li usr/local/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.91.60 -L/usr/local/lib/gcc-l s-2.91.60 -L/usr/local/lib -lgpc -lm -lgcc -lc -lgcc /usr/local/lib/gcc-lib/i586 60/crtend.o /usr/lib/crtn.o /usr/lib/crt1.o(.text+0x36): undefined reference to `main' Any suggestion as to what I could do to eliminate the "undefinded reference to main" message? I have been using Borland Pascal for the last ten years (mostly maintenance work as opposed to development) and therefore am curious as to how GPC functions as compared to Borland, i.e. what are the TPU, TPP, TPW equivalents in GPC and how are they linked in? If this is explained in some part to the documentation just point me in that direction. mfG, Larry

1 0

Svgalib-GPC-20000216 - Graphics library for GPC
by Nicola Girardi 26 Feb '00

26 Feb '00

Svgalib-GPC is a set of graphics units for GNU-Pascal. The units are the rewriting of data contained in the header include files included in the Svgalib distribution, in a manner which make it easy for Pascal programmers to use Svgalib without needing to rewrite prototypes. Most units just contain the prototypes for using Svgalib functions, with some adjustments regarding Boolean return values and CString stuff. The keyboard units (raw and normal mode) yet are rewritten using TFDD capabilities (and thanks to Frank for the explanation) and they seem to work well. I think the package is alright but I haven't tested it out much. So current status is neither of alpha, beta, gamma, delta, YOU have to tell me :-) The full library is distributed under the GNU LGPL. For details read the file COPYING.LIB contained in the tarball. Svgalib-GPC needs the latest alpha version of GPC, because of the TFDD stuff, and it's not that portable, in fact I think it's useable for Linux/x86 only, but it might work under other systems with svgalib4ggi. If you're going to test it for me, please tell me about the results. There are not good demos in the tarball to show you the capabilities of this all, and I'm not spending much time coding new features or demos. I think I'll improve this just if I get feedback and requests :-) Just because I enjoy only if people use what I code :-) If you have to report bugs, suggestions, requests, write to me at this address girardi(a)keycomm.it The site where you can find a bit more details about the units and download the current tarball is: http://agnes.dida.physik.uni-essen.de/~nicola/ Thanks to: Frank Heckenbach for help with TFDD stuff and for getting me to release this and Peter Gerwinski for the account on agnes. Have fun :) -- Nicola Girardi <girardi(a)keycomm.it> Key fingerprint = 5D9E ED36 C2E9 EF8F C4B6 25C2 3FF4 E5A2 27A7 83B9 GnuPG Key at http://agnes.dida.physik.uni-essen.de/~nicola/gpg-plan

1 0

Re: faq - 2nd version
by Frank Heckenbach 24 Feb '00

24 Feb '00

Khimenko Victor wrote: > 23-Feb-00 15:45 you wrote: > > Khimenko Victor wrote: > >> > please mention this is not necessary for Debian GNU/Linux and > >> > Debian GNU/Hurd. The current gpc can be fetched from www.debian.org > >> > for the architectures alpha, arm, i386, m68k, sparc and powerpc. > >> > >> This is true for KSI-Linux & SuSE as well AFAIK. So IMO to write something > >> "if you are plan to use version of GPC not included in your distribution then > >> vetter to build GPC yourself because..." > > > Nope. The GPC distribution that comes with SuSE-6.3 is > > misinstalled. It does not find the standard units (such as > > CRT). I am getting complaints from users about this regularly. > > Hmm. Looks like two-ended sword to me :-) SuSE-6.3 DOES NOT install CRT. > But 'make install' does not install CRT as well (AFAIK). So I'm not sure if > only SuSE must be blamed here... > > P.S. I mean 'does not install CRT in usable state' of course. You can not just > 'use CRT;' fire gpc and get working program after `make install'... Yes, you can if you compile with `--automake' (and have ncurses installed which shouldn't be a problem under Linux). The CRT unit (as well as the other units) are installed in source form which I think is fine for a free compiler, and will be compiled when needed (using `--automake') with your favourite options (optimization, debugging, etc.). The problem with SuSE, AFAIUI (can't check myself) is that either the unit sources are not installed, or there is some path problem so the installed GPC does not find them. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: faq - 2nd version
by Frank Heckenbach 24 Feb '00

24 Feb '00

I found the following request on Usenet: : From: "Rodrigo de Salvo Braz" <Rodrigo_Braz(a)brown.edu.nospam> : Newsgroups: comp.lang.pascal.misc : Subject: *Overview* documentation for GNU Pascal?!? : Date: Mon, 14 Feb 2000 11:49:26 -0500 : Organization: Brown University : Lines: 14 : Message-ID: <889bj7$ks5(a)cocoa.brown.edu> : NNTP-Posting-Host: 128.148.208.188 : : Hi, : : I have been trying to use GNU Pascal but found surprinsingly hard to find : instructions on the most basic things. Everywhere it seems to be assumed : that I know what libraries to use, what kind of file I want to generate. All : I get is detailed descriptions of options that do things I don't know about. : : So, does anyone know where to get overview documentation? : : Thanks, : : Rodrigo Since this seems to be a typical problem, i.e., getting started seems to be the most difficult thing about GPC, I suggest to write more about this in the FAQ, as detailed as possibled -- starting from zero, covering different platforms, when (and how) to get a GPC binary or rather the source distribution, etc. E.g., on Linux you better build GPC yourself because of glibc incompatibilities, but you can assume gcc, binutils, libc, ncurses etc. to be present, while under Dos, you better get a GPC binary for the first try and you need other files (that's already in the FAQ). The Chief is just writing a FAQ about building under MS-Windows which could be included or referenced. Another thing to mention is the libraries needed by some Pascal units, see ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/README (you can copy the text if you want). This is to say that it would be good to have the most important information for starters (what, where, how) available in one place. Perhaps it's also a good idea to copy some (not all!) information useful for starters from the GPC web pages. Then, of course, you might want to answer the request in the newsgroup with a pointer to the FAQ... :-) Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

4 4

RE: faq - 2nd version - gpc binaries dos
by Klaus Friis Østergaard 21 Feb '00

21 Feb '00

.... Since this seems to be a typical problem, i.e., getting started seems to be the most difficult thing about GPC, I suggest to write more about this in the FAQ, as detailed as possibled -- starting from zero, covering different platforms, when (and how) to get a GPC binary or rather the source distribution, etc. E.g., on Linux you better build GPC yourself because of glibc incompatibilities, but you can assume gcc, binutils, libc, ncurses etc. to be present, while under Dos, you better get a GPC binary for the first try and you need other files (that's already in the FAQ). The Chief is just writing a FAQ about building under MS-Windows which could be included or referenced. Another thing to mention is the libraries needed by some Pascal units, see ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/README (you can copy the text if you want). ...... Frank With the binary distribution of gpc for djgpp - what is the problem with archieving all that is need in one file. I think this would help alot, also avoids problems with mismatch between the gpb binary and the compiler version of the C compiler.

1 0

Unifying error messages
by Peter Gerwinski 20 Feb '00

20 Feb '00

Hello, we are considering to unify error messages concerning parameters. Currently, there are (at least) two types: error with parameter of procedure `Foo' error with parameter to procedure `Foo' Native speakers: Which one shall we use in the future? Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

3 2

Problem with sets
by Martin Liddle 18 Feb '00

18 Feb '00

I'm using GPC 19991030. I'm having a problem with the following code fragment: shared_data^.compr[J].awel:=[]; which does not result in awel becoming the null set (it retains its existing values). If I change this to: shared_data^.compr[J].awel:=[1]-[1]; then awel does become the null set. shared_data is a large complicated record. compr is an array of a fairly simple packed record and awel is a set of 1..120. I have tried hard to produce a simple test problem to demonstrate the problem but sadly all my test cases work perfectly. Anybody seen anything similar or any suggestions as to anything else I should investigate? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324.

1 0

GPC 19991030 on a DEC Alpha OSF machine
by Olivier Lecarme 18 Feb '00

18 Feb '00

I installed GPC 19991030 on top of gcc-2.95.2 on a DEC Alpha machine vith OSF-4.0e. I followed the instructions in the recent FAQ, but I had to comment out lines in gcc/explow.c and gcc/expr.Ã§ as suggested in a previous message by Mason Ip <MasonIp(a)Attachmate.com>. Compiling and installing GPC worked fine, but on trying to compile arrayslicedemo.pas in the demos directory, I get the following error message : arrayslicedemo.pas: In function `program_Arrayslicedemo': arrayslicedemo.pas:82: internal error--unrecognizable insn: (insn 287 285 288 (set (reg:SI 134) (reg:DI 133)) -1 (nil) (nil)) Olivier Lecarme

1 0

RE: gpc 19991030 and gcc 2.95.2
by JMBlakeney 17 Feb '00

17 Feb '00

Our system manager had to use gmake rather than make on our DEC OSF before the compiler would compile. John B -----Original Message----- From: Nicola Girardi [SMTP:girardi@keycomm.it] Sent: 13 February 2000 18:09 To: gpc(a)gnu.de Subject: Re: gpc 19991030 and gcc 2.95.2 << File: ATT00001.att >> On Sun, Feb 13, 2000 at 04:57:32PM +0100, Olivier Lecarme wrote: | I have been suggested to try building the last alpha version of gpc | instead of 19990118, called the current one on the official site. I | tried to build on top of gcc-2.95.2 on a DEC Alpha computer. | | "configure" runs without any warning, and without requiring any to aply | any patch. | | "make LANGUAGES=pascal" terminates prematurely with the following error | message : | | make[1]: *** No rule to make target `pascal', needed by `native'. Stop. | make[1]: Leaving directory `/net2/ciceron2/ol/src/Install/gcc-2.95.2/gcc' | make: *** [all-gcc] Error 2 | | Am I missing something ? Yes. The information supplied with the GPC tarball is outdated, so I get into this trouble once. This is more or less what you have to do: cd /usr/src tar xvfz gcc-2.95.2.tar.gz tar xvfz gpc-19991030.tar.gz mv gpc/p gcc-2.95.2/gcc/ mkdir gcc-2.95.2/gpc cd !$ ../configure And this last command ask you for a patch to apply; just hit enter and that should work. Then: make && make install Have fun!! -- Nicola Girardi <girardi(a)keycomm.it> Key fingerprint = 5D9E ED36 C2E9 EF8F C4B6 25C2 3FF4 E5A2 27A7 83B9 GnuPG Key at http://agnes.dida.physik.uni-essen.de/~nicola/gpg-plan

1 0

RE: GPC on a DEC Alpha
by Mason Ip 16 Feb '00

16 Feb '00

The quote was for Linux 4.1 or 5.0; it was properly not applicable to Dec-UX. I tried to compile GNU Assembler for DEC-UX but GNU binutilsÂ’s configure script said No Go. binutils-2.9.1> ./configure --prefix=/usr/opt/binutils-2.9.1 Configuring for a alpha-dec-osf4.0b host. *** This configuration is not supported in the following subdirectories: gas ld (Any other directories should still work fine.) Created "Makefile" in /usr/users/masonip/tmp/binutils-2.9.1 [snip] So, gas is not available as an alternative assembler on DEC-UX :-( ---------- From: Russ Whitaker [SMTP:russwhit@mind.net] Sent: Wednesday, February 16, 2000 2:35 AM To: gpc(a)gnu.de Subject: Re: GPC on a DEC Alpha Mason Ip wrote: I got the same error : Â“heap.pas:30: module/unit `error' could not be compile.Â” ---------- The following is an exerpt from gcc-2.95.2/install/SPECIFIC " GNU/Linux Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may see errors of this sort: Error: Unknown pseudo-op: `.arch' This is a signal that a new assembler is needed if you want to generate BWX insns for your machine.

1 0

GPC woes on ultrasparc II Solaris 2.6
by minnrp01＠holmes.ipfw.edu 16 Feb '00

16 Feb '00

Hello all. I have been having some severe problems with compiling Pascal files on an Ultrasparc II box running Solaris 2.6. The compiler has crashed several times and generated cores. The crashes ranged from seg violations and bus errors, to SIGIOT (signal 6). Some of the crashes seem to result from syntax errors, while other seem to mysteriously vanish. These crashes have occurred with the stable version of GPC(beta? it's dated early 1999) using gcc 2.8.1. I have made sure that this version has been compiled for 32 bit mode. I also have had the signal 10s and 11s occur with gpc-19991030 using gcc 2.95.2. These problems seem to bve specific to this box/OS. I can compile the same code at home on a AMD K6-3 running Linux with a 2.2.13 kernel and the compiler will not crash. Is there something peculiar about setting up or compiling GPC for an Ultrasparc using Solaris 2.6 that I may be missing? Should I submit bug reports since the platform is not listed on the web site? Thanks Russell Minnich minnrp01(a)holmes.ipfw.edu

2 1

RE: GPC on a DEC Alpha
by Mason Ip 16 Feb '00

16 Feb '00

Olivier Lecarme wrote ... > /net/packages/GNU/gcc-2.95.2/gcc/p/rts/error.pas: In function `Geterrormessage': > /net/packages/GNU/gcc-2.95.2/gcc/p/rts/error.pas:365: Internal compiler error in > `copy_to_mode_reg', at gcc-2.95.2/gcc/explow.c:669 > In what direction should I try to understand what occurs, or to repair > it? If you take a look at explow.c:669, you'll see the "offending" line. I made the following changes and managed to compile gpc. Note that these changes were properly not the right ways to fix the code. They were just bypassing the real problems. Please use these changes with your own risk. A) changes to explow.c gcc-2.95.2/gcc> DIFF explow.c.orig explow.c --- explow.c.orig Tue Feb 15 10:30:22 2000 +++ explow.c Tue Feb 15 13:28:02 2000 @@ -662,12 +662,14 @@ /* If not an operand, must be an address with PLUS and MULT so do the computation. */ if (! general_operand (x, VOIDmode)) x = force_operand (x, temp); +/* if (GET_MODE (x) != mode && GET_MODE (x) != VOIDmode) abort (); +*/ if (x != temp) emit_move_insn (temp, x); return temp; } B) changes to expr.c gcc-2.95.2/gcc> DIFF expr.c.orig expr.c --- expr.c.orig Tue Feb 15 17:06:54 2000 +++ expr.c Tue Feb 15 17:09:31 2000 @@ -2587,12 +2587,14 @@ enum machine_mode mode = GET_MODE (x); x = protect_from_queue (x, 1); y = protect_from_queue (y, 0); +/* if (mode == BLKmode || (GET_MODE (y) != mode && GET_MODE (y) != VOIDmode)) abort (); +*/ /* Never force constant_p_rtx to memory. */ if (GET_CODE (y) == CONSTANT_P_RTX) ; else if (CONSTANT_P (y) && ! LEGITIMATE_CONSTANT_P (y))

2 1

Re: sockets, clients and servers
by Clyde Meli 16 Feb '00

16 Feb '00

> I am new to GPC, never used it before, just downloaded it. Pascal is my "old > love", and I would like to use it again. > > I would like to use GPC instead of C++ for a new project. It is a > client-server application, where clients communicate via TCP with the > server. How can I access the sockets library from GPC? Any wrapper libraries > yet? > > Any suggestions,especially examples, welcome. > > Horst > It's been done, but the code would need some 'brushing up' before I send the code to Peter. But I can send you a copy if you want, let me know. Regards, Clyde

1 0

Re: GPC on a DEC Alpha
by Russ Whitaker 16 Feb '00

16 Feb '00

Mason Ip wrote: I got the same error : heap.pas:30: module/unit `error' could not be compile. ---------- The following is an exerpt from gcc-2.95.2/install/SPECIFIC " GNU/Linux Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may see errors of this sort: Error: Unknown pseudo-op: `.arch' This is a signal that a new assembler is needed if you want to generate BWX insns for your machine. The version of GCC shipped with Red Hat 4.2 (2.7.0.2) has a fault wherein it will silently generate incorrect code. The version shipped with Red Hat 5.0 (2.8.0.1) is not broken, but required an extra -m21164a argument on the command-line. In order to visibly trap 2.7.0.2, I now issue DEC's .arch pseudo into the assembly. Relieving the problem of mucking with command-line arguments for 2.8.0.1 is a pleasant side effect. If you've got Red Hat 5.0 installed, you may grab binutils 2.9.1 and be happy. If you've got Red Hat 4.2, bugs make it much harder to upgrade pieces on your own, and you are better off upgrading the entire system. In either case, your problem may be bypassed by not emitting BWX code by default. Do this by using configure alphaev5-unknown-linux-gnulibc1 if you have RH 4.2, or configure alphaev5-unknown-linux-gnu if you have RH 5.0. The following error: Error: macro requires $at register while noat in effect also indicates that you should upgrade to a newer version of the assembler, 2.9 or later. If you can not upgrade the assembler, the compiler option "-Wa,-m21164a" may work around this problem. " ---------------------------------------------------------------------------- ----------- Please let me know if this helps - I'll add a paragraph to the faq Thanks Russ <russwhit(a)mind.net>

1 0

sockets, clients and servers
by Horst Herb 16 Feb '00

16 Feb '00

I am new to GPC, never used it before, just downloaded it. Pascal is my "old love", and I would like to use it again. I would like to use GPC instead of C++ for a new project. It is a client-server application, where clients communicate via TCP with the server. How can I access the sockets library from GPC? Any wrapper libraries yet? Any suggestions,especially examples, welcome. Horst

1 0

GPC on a DEC Alpha
by Olivier Lecarme 16 Feb '00

16 Feb '00

I just applied, from scratch, the instructions given in the new FAQ we just got. The command "make bootstrap-lean" terminates with the following error messages : ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissi ng-prototypes -Wmissing-declarations -O2 -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS _VERSION_`cat /net/packages/GNU/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS= 0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/net/packages /GNU/gcc-2.95.2/gcc/p/rts --automake /net/packages/GNU/gcc-2.95.2/gcc/p/rts/heap .pas /net/packages/GNU/gcc-2.95.2/gcc/p/rts/error.pas: In function `Geterrormessage': /net/packages/GNU/gcc-2.95.2/gcc/p/rts/error.pas:365: Internal compiler error in `copy_to_mode_reg', at gcc-2.95.2/gcc/explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../.././xgpc exited with status 1 /net/packages/GNU/gcc-2.95.2/gcc/p/rts/heap.pas:30: module/unit `error' could no t be compiled make[3]: *** [heap.o] Error 1 make[3]: Leaving directory `/net/packages/GNU/gcc-build/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/net/packages/GNU/gcc-build/gcc' make[1]: *** [bootstrap-lean] Error 2 make[1]: Leaving directory `/net/packages/GNU/gcc-build/gcc' make: *** [bootstrap-lean] Error 2 In what direction should I try to understand what occurs, or to repair it? Olivier Lecarme

2 1

RE: GPC on a DEC Alpha
by Mason Ip 15 Feb '00

15 Feb '00

I got the same error : Â“heap.pas:30: module/unit `error' could not be compile.Â” ---------- From: Olivier Lecarme [SMTP:ol@i3s.unice.fr] Sent: Tuesday, February 15, 2000 12:06 AM To: gpc(a)gnu.de Cc: ol(a)i3s.unice.fr Subject: GPC on a DEC Alpha I just applied, from scratch, the instructions given in the new FAQ we just got. The command "make bootstrap-lean" terminates with the following error messages : ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissi ng-prototypes -Wmissing-declarations -O2 -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS _VERSION_`cat /net/packages/GNU/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS= 0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/net/packages /GNU/gcc-2.95.2/gcc/p/rts --automake /net/packages/GNU/gcc-2.95.2/gcc/p/rts/heap .pas /net/packages/GNU/gcc-2.95.2/gcc/p/rts/error.pas: In function `Geterrormessage': /net/packages/GNU/gcc-2.95.2/gcc/p/rts/error.pas:365: Internal compiler error in `copy_to_mode_reg', at gcc-2.95.2/gcc/explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../.././xgpc exited with status 1 /net/packages/GNU/gcc-2.95.2/gcc/p/rts/heap.pas:30: module/unit `error' could no t be compiled make[3]: *** [heap.o] Error 1 make[3]: Leaving directory `/net/packages/GNU/gcc-build/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/net/packages/GNU/gcc-build/gcc' make[1]: *** [bootstrap-lean] Error 2 make[1]: Leaving directory `/net/packages/GNU/gcc-build/gcc' make: *** [bootstrap-lean] Error 2 In what direction should I try to understand what occurs, or to repair it? Olivier Lecarme

1 0

faq - 2nd version
by Russ Whitaker 15 Feb '00

15 Feb '00

Hi all attached is faq.gz any comments, suggestions? thanks, Russ <russwhit(a)mind.net>

3 2

gpc on a DEC Alpha
by Olivier Lecarme 14 Feb '00

14 Feb '00

I tried to install gpc 19991030 on top of gcc-2.95.2, on a DEC Alpha computer with OSF 4.0e. According to suggestions made by Nicola Girardi, I proceeded in the following way : tar xvfz gcc-2.95.2.tar.gz tar xvfz gpc-19991030.tar.gz mv gpc/p gcc-2.95.2/gcc/ cd gcc-2.95.2 mkdir gpc ../configure --enable-languages=pascal [ here the necessary patch was applied ] make The last step terminates with the following results : ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat /net2/ciceron2/ol/src/Install/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/net2/ciceron2/ol/src/Install/gcc-2.95.2/gcc/p/rts --automake heap.pas error.pas: In function `Geterrormessage': error.pas:365: Internal compiler error in `copy_to_mode_reg', at explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../.././xgpc exited with status 1 heap.pas:30: module/unit `error' could not be compiled make[2]: *** [heap.o] Error 1 make[2]: Leaving directory `/net2/ciceron2/ol/src/Install/gcc-2.95.2/gcc/p/rts' make[1]: *** [pascal.rts] Error 2 make[1]: Leaving directory `/net2/ciceron2/ol/src/Install/gcc-2.95.2/gcc' make: *** [all-gcc] Error 2 Did this problem occur to anybody else ? Olivier Lecarme

1 0

gpc 19991030 and gcc 2.95.2
by Olivier Lecarme 13 Feb '00

13 Feb '00

I have been suggested to try building the last alpha version of gpc instead of 19990118, called the current one on the official site. I tried to build on top of gcc-2.95.2 on a DEC Alpha computer. "configure" runs without any warning, and without requiring any to aply any patch. "make LANGUAGES=pascal" terminates prematurely with the following error message : make[1]: *** No rule to make target `pascal', needed by `native'. Stop. make[1]: Leaving directory `/net2/ciceron2/ol/src/Install/gcc-2.95.2/gcc' make: *** [all-gcc] Error 2 Am I missing something ? -- Olivier Lecarme

3 2

GPC on DEC Unix (OSF)
by Olivier Lecarme 13 Feb '00

13 Feb '00

I just installed gpc on a DEC Alpha computer with DEC Unix (OSF) version 4.0e. The installation with gcc 2.8.1 ran without error, and gpc answers as follows : zenon(~)31: gpc -v Reading specs from /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0e/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 Program compiling runs correctly. However, when trying to execute any generated load image, the error message is always the same : internal error: duplicate constructor Is there any explanation? Did I get the correct versions of gpc and gcc? -- Olivier Lecarme

3 3

current gpc vs. current gcc
by Olivier Lecarme 13 Feb '00

13 Feb '00

I just successfully installed the last gpc, using the gcc-2.8.1 distribution. However, the current gcc distribution is 2.95.2, which was previously installed on the same machine. Thus, I would like to ask: - whether gpc can be installed using gcc-2.95.something (it seemed to me that it didn't work); - or whether gpc-2.8.1 can coexist with gcc-2.95.2 on the same machine. Thanks in advance, -- Olivier Lecarme

2 1

Re: GPC on DEC Unix (OSF)
by Frank Heckenbach 12 Feb '00

12 Feb '00

Olivier Lecarme wrote: > I just installed gpc on a DEC Alpha computer with DEC Unix (OSF) version > 4.0e. The installation with gcc 2.8.1 ran without error, and gpc answers > as follows : > > zenon(~)31: gpc -v > Reading specs from /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0e/2.8.1/specs > gpc version 19990118, based on gcc-2.8.1 > > Program compiling runs correctly. However, when trying to execute any > generated load image, the error message is always the same : > > internal error: duplicate constructor > > Is there any explanation? Did I get the correct versions of gpc and gcc? That's a known bug with that version. It's fixed in later alpha versions. You can simply remove or uncomment the misleading warning in rts/misc.c and rebuild. It's harmless. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

crt library for GNU?
by Ian Maddox 09 Feb '00

09 Feb '00

I am a high-school student using the Gnu pascal compiler for programming homework, but I run into a regrettable hitch. My programs are now requiring the Borland Pascal crt library, and I don't know where to find either that library or a similar one for GNU. Is there any hope? ((The crt library is responsible for clearing the screen, creating sounds and colors on the screen, and random numbers, I think.)) Thanks for your help... Ian Maddox

2 1

List archive working again
by Anja Drewitz 08 Feb '00

08 Feb '00

Hello, the list archive at should be working again now. The URL is http://www.gnu.de/archive/wilma.cgi/gpc and http://www.gnu.de/archive/wilma.cgi/gpc-announce respectively. Now the pages also come in gpc signature colors. :-) Currently, the search option is working fine. If you find it broken, please email me at <anja(a)drewitz.de>. Please don't mail a copy to the gpc list because I let procmail move all mails with To: gpc... and Cc: gpc... to a separate folder and would not see your mail for a long time. Best wishes, Anja

1 0

Failure when using crt unit
by Klaus Friis Østergaard 08 Feb '00

08 Feb '00

I get this failure when I try to compile a program that uses the crt unit program test; uses crt; ... begin .. end. I call gpc with this gpc -O --automake --extended-syntax test.pas -o test I get this failure: gpc: installation problem, cannot exec 'cpp': no such file or directory gpc1: gpc exits with status 1 /usr/lib/gcc-lib/i386-rehat-linux/2.8.1/crt.pas:345 '/usr/lib/gcc-lib/i386-rehat-linux/2.8.1/crtc.c' could not be compiled modul crt could not be compiled I have run the test with make which uses units the standard units which is descibed in the documentation of the beta relaese , should be read automatically. Does anybody seen this problem and what shal I do to fix it? Klaus F. Ãstergaard

2 1

External (asmname) variables (was: rough draft - FAQ
by Dr Abimbola A Olowofoyeku 04 Feb '00

04 Feb '00

On 3 Feb 00, at 14:39, Peter Gerwinski wrote: > Matze Braun wrote: > > You should add, how to use global vars from C-Librarie. I had to > > look for a long time before I noticed, that I have to use asmname > > '...' before the Data Type. > > I often thought about > > - replacing `asmname' by `external name' (inspired by DLL > support in BP), I am strongly in favour of that. > - making `external' a rigidly reserved word, so we can place > it _after_ the type. Good idea! Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro v5.21.1 for Win32 http://ourworld.compuserve.com/homepages/African_Chief/chief32.htm

1 0

Re: Compiling gpc-19991030 fails on rts.c
by Frank Heckenbach 04 Feb '00

04 Feb '00

Dr A Olowofoyeku wrote: > Here is the fsync function. I get compile errors when converting it to > a macro in os-hacks.h - so please convert it for me. > > int fsync (int __fd) > { > return FlushFileBuffers ((HANDLE) _get_osfhandle (__fd)); > } I don't know all the relevant declarations, but normally, the following should work: #define fsync(__fd) (FlushFileBuffers ((HANDLE) _get_osfhandle (__fd))) If it doesn't, please show me the error messages. BTW, does FlushFileBuffers return 0 on success and -1 on error? If it returns 1 on success and 0 on error (as some Windoze routines do IIRC), try: #define fsync(__fd) ((FlushFileBuffers ((HANDLE) _get_osfhandle (__fd))) ? 0 : -1) > > getpwnam, getpwuid - get password file entry > > Here is my implementation. The WinAPI calls are correct, but I am > clearly not doing things correctly as far as the return values for > pointers to the passwd structure is concerned - I get garbabe in the > fields when I call the functions that return pointers to the passwd > structure (but inside the functions themselves, when I do "printf" of > the return values from the WinAPI functions, I get correct values). > So the problem is how to assign the values returned by WinAPI to > the fields of the structure, and how to return correctly. This is because local variables (can) become invalid after the function returns which is problematic if you return a pointer to them. To solve it, declare them as `static'. AFAICS, this affects the following variables: char fcc[260]; WCHAR wname[256]; struct passwd psw; struct passwd psw; struct passwd psw1; BTW: The statment `psw0 = malloc (sizeof (*psw0));' seems to be superfluous as psw0 is overwritten two lines below. Another thing, in the function: char *wide2ansi (LPWSTR wide) { char fcc[260]; fcc[0] = NULL; WideCharToMultiByte ( CP_ACP, 0, wide, -1, fcc, 260, NULL, NULL ); return &fcc; } The `&' should be omitted (in C, arrays are automatically treated as pointers when necessary -- though it seems to work with the `&' as well, but produces a warning). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Compiling gpc-19991030 fails on rts.c
by Frank Heckenbach 04 Feb '00

04 Feb '00

Dr A Olowofoyeku wrote: > On 23 Jan 00, at 2:17, Frank Heckenbach wrote: > > > J. David Bryan wrote: > > > > > On 21 Jan 00, at 9:58, Dr A Olowofoyeku wrote: > > > > > > > Your problem is probably due to things that are missing in the gcc Mingw > > > > libraries (and there are many of them). > > > > > > I have tracked my specific problem down to the lack of a "pwd.h" file in > > > Mingw (thanks, Chief!). The trouble is that "_p_pwl2c" in "rts.c" > > > references the "passwd" struct, which is defined in "pwd.h", but "pwd.h" > > > isn't part of Mingw. This is detected by the Pascal "configure", which > > > sets "#undef HAVE_PWD_H" in "rts-config.h" but is not covered by alternate > > > code in "rts.c". The result is a syntax error when compiling. > > > > As I said, the current code (to be released as a snapshot soon) > > contains such a check. However, no alternate code (just a failure > > result) -- if there's equivalent functionality on other systems > > (which I don't know about), I'll have to leave it to you to add > > it... > > Can you please let me know what the code is actually supposed to > do? Perhaps there is a way to write an implementation for it, which > we can include in 'os-hacks.h'. It returns information about the user accounts on the system (i.e., not the users currently logged in, but all users who are allowed to log in). I guess on MS-Windows 95/98, there's not much point to it, but on NT, there might be... The relevant functions and data types are: --- NAME getpwnam, getpwuid - get password file entry SYNOPSIS #include <pwd.h> #include <sys/types.h> struct passwd *getpwnam(const char * name); struct passwd *getpwuid(uid_t uid); DESCRIPTION The getpwnam() function returns a pointer to a structure containing the broken out fields of a line from /etc/passwd for the entry that matches the user name name. The getpwuid() function returns a pointer to a structure containing the broken out fields of a line from /etc/passwd for the entry that matches the user uid uid. The passwd structure is defined in <pwd.h> as follows: struct passwd { char *pw_name; /* user name */ char *pw_passwd; /* user password */ uid_t pw_uid; /* user id */ gid_t pw_gid; /* group id */ char *pw_gecos; /* real name */ char *pw_dir; /* home directory */ char *pw_shell; /* shell program */ }; RETURN VALUE The getpwnam() and getpwuid() functions return the passwd structure, or NULL if the matching entry is not found or an error occurs. --- NAME getpwent, setpwent, endpwent - get password file entry SYNOPSIS #include <pwd.h> #include <sys/types.h> struct passwd *getpwent(void); void setpwent(void); void endpwent(void); DESCRIPTION The getpwent() function returns a pointer to a structure containing the broken out fields of a line from /etc/passwd. The first time it is called it returns the first entry; thereafter, it returns successive entries. The setpwent() function rewinds the file pointer to the beginning of the /etc/passwd file. The endpwent() function closes the /etc/passwd file. The passwd structure is defined in <pwd.h> as follows: struct passwd { char *pw_name; /* user name */ char *pw_passwd; /* user password */ uid_t pw_uid; /* user id */ gid_t pw_gid; /* group id */ char *pw_gecos; /* real name */ char *pw_dir; /* home directory */ char *pw_shell; /* shell program */ }; RETURN VALUE The getpwent() function returns the passwd structure, or NULL if there are no more entries or an error occurs. --- So, getpwnam and getpwuid find an entry by user name or user ID, resp., while getpwent returns all entries successively. Of course, the former to can be implemented on top of the latter, so if only the latter is available, that'll be fine. BTW, the pw_passwd contains the password in encrypted form, of course! And on systems that use shadow, it doesn't contain anything interesting (at least for normal programs), but usually `*' or `x'. That's better security-wise, so you probably shouldn't even try to put something interesting in this field... If it's not possible to implement them, don't worry. These functions will by marked as optional (i.e., not returning meaningful information on all systems), and programs are expected to cope with that (which will appear to them like a system with no accounts). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: rough draft - FAQ
by Frank Heckenbach 03 Feb '00

03 Feb '00

Russ Whitaker wrote: > attached is a rough draft of a FAQ. Will add about the Solaris 8 > binaries. Any additions, corrections, comments? OK, here are some... > Is it compatible with Turbo Pascal (R) ? > ======================================== > > GPC is currently *not* a drop-in replacement for Borland's Turbo > Pascal (R). It supports a number, but not all of the Borland > extensions to the Pascal language. There is no replacement for most of > the Borland runtime library functions. GNU Pascal is part of the GNU > project, so portability is one of its primary goals. For this reason, > non-portable features of Borland Pascal will probably not be included > into GNU Pascal. More information can be found in the section "Borland > Pascal" of the GPC manual. This has changed a lot. Almost all BP language features are supported now. Notable exceptions are the string format (as discussed below), or the `Mem' and `Port' pseudo arrays, though replacement functions for the latter on x86 platforms exist in the `Ports' unit. Also, almost all of BP's run time library is supported in GPC (built-in or in units with the same names as their BP counterparts). Some notes: - A BP compatible Graph unit exists, but is distributed separately due to its license. - The OOP stuff (Turbo Vision etc.) is not yet completed, but work on several projects is underway. - Some exotic routines need an explicit `uses System' statement, or equivalently a `--uses=system' command line option. See the system unit for details. - A few unportable routines are not supported in the Dos unit (see the comments there). I think there's an older, unportable, Dos unit which supports them (or else it's easy to write one) if you really need those routines... > When I build `libgpc.a', `rt0.c' says: SIGXCPU undefined (and more) > ======================================================================= I'm adding an autoconf test to overcome this problem, so I think you can remove the item after the next release. > Can you recommend an IDE? > ========================= > > Users of Borland Pascal may wonder if there's a replacement for the > IDE (Integrated Development Environment). Here's a few suggestions: > > * (X)Emacs. Some people think it's the answer to the question of > Life, the Universe and Everything, others decide it's uGNUsable. > Available from your friendly GNU mirror. > > * XWPE is an imitation of the Borland IDE, so users of Borland > Pascal may find it a good alternative. > > * RHIDE. djgpp users should definately try RHIDE. The latest (beta) > release is compatible with GNU Pascal and allows stepping, tracing > and watching like Borland's IDE. RHIDE v0.6 beta can be downloaded > from: > http://www.tu-chemnitz.de/~rho/rhidetest.html The URL has changed to: http://www.tu-chemnitz.de/~sho/rho/rhide/rhide.html Also, I'd like to plug my own IDE, PENG. It's not free software, but it was written with GPC. It's also very similar to Borland's IDE, but with many extensions: http://fjf.gnu.de/peng.html > Do you have a binary for me? > ============================ > > Currently, we have binaries for these platforms: > > i486-linux (ELF) > i486-linuxaout > i486-linuxoldld > i386-freebsd1.2.0 > djgpp V2 (msdos) > emx 0.9B (OS/2, msdos) > cygwin32 beta16 (Windows95, Windows NT) > mips-sgi-irix5.3 > sun-sparc-sunos4.1.4 > > New binaries may have been added after the release of this FAQ. You might want to update the list by looking at the FTP directory beta/binary on agnes. > 3.0 GNU Pascal and your system libraries > **************************************** > > This section discusses common problems people have when they try to > access their system's libraries. > > How do I use <insert_your_function_here> from the C library? > ============================================================ > > GNU Pascal can use every function of your C library, but it may be > up to you to write declaration of an external function, before you can > use it. Consider the function `sleep'. `man(3) sleep' reveals: > > --------------------------------------------------------- > NAME > sleep - Sleep for the specified number of seconds > > SYNOPSIS > #include <unistd.h> > > unsigned int sleep(unsigned int seconds); > --------------------------------------------------------- > > This small demo program shows how to use `sleep' in a Pascal program: > > --------------------------------------------------------- > program SleepDemo; > > type > word = __unsigned__ integer; > > function sleep(seconds: word): word; C; > > var > result : word; > > begin > result := sleep(10); > end. GPC knows the type `Word' (and, for that matter, equivalent built-in types for all integer types in C). `__unsigned__' is considered obsolete and will probably removed soon, so using the built-in `Word' (or `Cardinal' which is the same) is recommended (see the subsection `Integer Types' in the GPC manual). Also, as Peter mentioned, GPC by now provides routines for many libc functions. Most of them are declared in the GPC unit (see the section `Run time library' in the chapter `Programming' in the GPC manual for complete declarations). `Sleep' is one of them, and using the one from the GPC unit is recommended, because it's more portable. > How do I build/use a shared library? > ==================================== > > (topic under construction) Using them is easy: Just add the appropriate `-lfoo' option to the command line, or (more recommended) a `{$L foo}' compiler directive (where `foo' is the name of the library) into the program or a unit. This will use a shared library by default, and a static one if a shared library is not found or the command line option `-static' is given. Creating a shared library currently works like in GCC, e.g. by linking the object files with `-shared'. You will have to take care about the interfaces yourself, since GPI files are not handled, and you might have to explicitly call any unit/module initializers. There is support for building the GPC runtime library (libgpc) dynamically, by configuring the RTS (not the compiler!) with `--with-shared', which can reduce the size of executables dramatically, but since it makes the executables dependent on the shared library version and the runtime library is changing fast, this is currently considered "on your own risk". Don't do it if you intend to distribute your binaries. Note that some platforms, e.g. DJGPP, don't support shared libs at all. > However, the > Pascal string schema, as defined in section 6.4.3.3.3 of the ISO-10206: > 1990 Extended Pascal standard, is a record: > > type string = record > Capacity : integer; > length : integer; > string : packed array [ 1..Capacity ] of char; > end; Actually it's a schema record: type String (Capacity : integer) = record Length : 0 .. Capacity; String : packed array [1 .. Capacity + 1] of Char end; The `+ 1' is a GPC extension to make it feasible to automatically add the #0 terminator when passing or assigning them to CStrings. > In standard pascal you expect ic[1] to align > with the first character position of s and thus one character to the left > is the length of s. Thus ic[0] is the length of s. True? Better add a "Q:" here, otherwise careless readers might take the "standard pascal" bit as a true statement... > There may be other ways to do the same thing; you could declare a > type `PChar' instead of `CString': > > type > PChar = ^char; > > and replace all references to `CString' with `PChar'. Do *NOT* pass > a "C" style string as a var-argument if the C prototype says `const > char *' or you will get a coredump. > > You are right if you think this stuff belongs in a library, to be > distributed with GPC. Have patience, or start coding! `PChar' is predefined now (though we recommend `CString' because it makes it clearer that we're talking about some kind of string rather than a single character), and a lot of library routines in Pascal for many applications (in the GPC unit and some other units) have been written (see above)... > At least for some of the pre-releases of `gpc-1.2', the > `gpc.info' file is invalid: it refers to the `gpc.i*' sections as > `gpc.info-*'. This can be fixed by loading `gpc.inf' in an editor and > replacing `gpc.info-*' with `gpc.i*' I think that's obsolete. :-) > A guide is available which was written by Brennan Mr. Wacko Underwood > <brennan(a)mack.rt66.com> and describes how to use inline assembly > programming with DJGPP, at this URL: > > http://www.rt66.com/~brennan/djgpp/djgpp_asm.html There's also a GPC assembler tutorial at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/gpcasm.zip > type > word = __unsigned__ integer; > short = __short__ integer; > byte = __byte__ integer; See above. (`Byte' and `Word' are built-in, and `ShortInt' is `short' in C.) > Bugs are best reported to the GPC mailinglist <gpc(a)hut.fi>. > > You can send a message to the GPC mailing list by sending email to > the list address <gpc(a)hut.fi> as if it were a person. > > You can join the mailing list by sending a message to > <gpc-request(a)hut.fi> (NOT <gpc(a)hut.fi> !) with your request to be added > to the list. Maintenance is done by hand, so some delay is possible. > > To leave the mailing list, send a message to <gpc-request(a)hut.fi>. s/hut.fi/gnu.de/ :-) Maintenance is automatic now. > 7.0 Miscellaneous > ***************** > > I want to contribute; where do I start? > ======================================= > > A list of jobs which should be done for GNU-Pascal can be found in > the section "How to contribute" of the Texinfo deocumentation. In cases > where somebody is already working on a topic, the name of that person is > written behind the job's description. This is hopelessly outdated (and I think has been removed from the distribution now). For now, if you want to contribute, please write to the mailing list. > The master FTP site for GNU Pascal is `kampi.hut.fi'. GNU Pascal > related files can be found in: > > ftp://ftp.kampi.hut.fi/jtv/gnu-pascal/ > > This site is mirrored on: > > ftp://sunsite.doc.ic.ac.uk/gnu/pascal/ > > The latest developer releases can be downloaded from: > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ agnes is now the master FTP site rather than kampi. > Also, we have a homepage on the web: > > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ Or shorter: http://home.pages.de/~GNU-Pascal/ Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

rough draft - FAQ
by Russ Whitaker 03 Feb '00

03 Feb '00

Hi all attached is a rough draft of a FAQ. Will add about the Solaris 8 binaries. Any additions, corrections, comments? Thanks Russ <russwhit(a)mind.net> ********************************************************************* GNU Pascal Frequently-Asked Questions List, Edition 0.5, February 2000 by Russ Whitaker <russwhit(a)mind.net> based on GNU Pascal Frequently-Asked Questions List, Edition 0.4, for GPC version 2.0, November 1996 by J.J. van der Heijden <j.j.vanderheijden(a)student.utwente.nl> For up-to-date information, ask the GPC mailing list (see below). Index ***** 1.0 GNU Pascal - what, where and why 2.0 Installation 3.0 Pascal and system libraries 4.0 Strings 5.0 Pascal on the djgpp platform 6.0 Getting Help 7.0 Miscellaneous 1.0 GNU Pascal *************** 1.1 What and why? ================= The purpose of the GNU Pascal project is to produce a Pascal compiler (called GNU Pascal or GPC) which * combines the clarity of Pascal with powerful tools suitable for real-life programming, * supports both the Pascal standard and the Extended Pascal standard as defined by ISO, ANSI and IEEE. (ISO 7185:1990, ISO/IEC 10206:1991, ANSI/IEEE 770X3.160-1989) * supports other Pascal standards (UCSD Pascal, Borland Pascal, Pascal-SC) in so far as this serves the goal of clarity and usability, * may be distributed under GNU license conditions * can generate code and run on any computer for which the GNU C compiler can generate code and run. Pascal was originally designed for teaching. GNU Pascal provides a smooth way to proceed to challenging programming tasks without learning a completely different language. 1.2 What is the current version? ================================ The latest release as of this writing is GPC-19991030. GPC requires GCC as a back-end. Patches for GCC 2.8.1 thru GCC 2.95.2 are provided but it is recommended that you use at least GCC 2.95. 1.3 Where can I get it? ======================= You can download the latest alpha or beta releases of gpc from ftp://agnes.dida.physik.uni-essen.de/ Is it compatible with Turbo Pascal (R) ? ======================================== GPC is currently *not* a drop-in replacement for Borland's Turbo Pascal (R). It supports a number, but not all of the Borland extensions to the Pascal language. There is no replacement for most of the Borland runtime library functions. GNU Pascal is part of the GNU project, so portability is one of its primary goals. For this reason, non-portable features of Borland Pascal will probably not be included into GNU Pascal. More information can be found in the section "Borland Pascal" of the GPC manual. Also see "About Strings", below. 2.0 Installation related questions ********************************** This section discusses some common problems with the installation of GNU Pascal. Which platforms are supported by GNU Pascal? ============================================ GPC uses the GCC backend, so it should run on any system that is supported by GNU CC. This includes a large variety of Unix systems, MS-DOS, OS/2 and Win32. A full list of platforms supported by GCC can be found in the file `INSTALL' of the GCC distribution. Not all of these have actually been tested, but it is known to run on these platforms: ix86-linux (Linux 2.x, ELF) i486-linuxaout i486-linuxoldld i386-freebsd1.2.0 djgpp V2 (msdos) emx 0.9B (OS/2, msdos) cygwin32 beta16 (Windows95, Windows NT) mips-sgi-irix5.3 sun-sparc-sunos4.1.4 >>> Ok people - send us your success stories, with canonical machine name! <<< Which components do I need to compile Pascal source code? ========================================================= A complete Pascal compiler system should at least have: 1. The actual compiler, GPC. While there are some binaries available you can build GPC yourself. You nee a working C compiler, some tools: bash, ar, patch, make, the GCC source, and the GPC source. 2. An editor, Assembler, linker, librarian and friends. 3. A C library. If you have a working C compiler you already have this. 4. A debugger, if you want to debug your programs. For most people, the GNU binutils and GNU debugger (gdb) are a good choice, although some may prefer to use vendor specific tools. How do I build a GPC compiler? ============================== If you have a typical ix86 box the routine is fairly simple. Any other computer you should carefully read the documentation in GCC*/install. Assuming you have: 1. A working C compiler. 2. The usual tools: ar, awk, bash, bison, ld, make, patch, sed 3. The GPC and GCC tar.gz source in directory /usr/local/src Then here's a cookbook recipe: 1. Unpack the two sources: tar -xvzf gcc-2.95.2.tar.gz tar -xvzf gpc-19991030.tar.gz 2. Since GCC recommends building gcc in a separate directory, lets make one: we'll call it gcc-build. mkdir gcc-build 3. Now we need to move GPC into GCC: mv gpc/p gcc-2.95.2/gcc 4. Next is a patch to gcc: cd gcc-2.95.2/gcc patch -s -p1 < p/diffs/gcc-2.95.2.diff 5. Now GCC is ready to build several languages, including pascal. If you want to know what languages, grep language= */config-lang.in will give you a list. 6. So let's go do it: cd ../../gcc-build ../gcc-2.95.2/configure --enable-languages=pascal make bootstrap-lean That "make bootstrap-lean" will take some time. If you want to know how much, you could date > /time1 ; make bootstrap-lean ; date > /time2 On my 400mhz i586 with 128m ram, no swap, it took 24 min 34 sec. 7. If all went well you can now install it: make install That's it. You can find some interesting demos in /usr/local/doc/gpc/demos and you can find the units directory with find /usr/local/lib -name units note: the following six items are untouched from the original FAQ Help! linking `gpc1' fails: `_emit_string_move' undefined (and more) ==================================================================== If linking `gpc1' bombs out with an error message that looks like this: ld: Undefined symbol _emit_string_move _emit_string_pad _maybe_find_function_data _dbxout_set_type_status _version_flag *** Error code 1 make: Fatal error: Command failed for target `gpc1' you probably suffer from a VPATH make problem. A few GPC source files have counterparts with identical name in the GCC source directory. When you have built GCC in the GCC source directory and you are not using a recent version of GNU make this problem may occur. There are three solutions: 1. Get a recent version of GNU make. Version 3.74 or better is known to work. 2. Build GCC in a seperate directory instead of using the GCC source directory. 3. Manually delete these files from the GCC object directory: `stor-layout.o' `dbxout.o' `expr.o' `fold-const.o' `optabs.o' `convert.o' `function.o' `setop.o' `toplev.o' then resume `make'. When I build `libgpc.a', `rt0.c' says: SIGXCPU undefined (and more) ======================================================================= Compilation of the runtime system may fail in `rt0.c' with a message simular to this: rt0.c: `SIGXCPU' undeclared (first use this function) or: rt0.c: storage size of `sv' isn't known rt0.c: storage size of `osv' isn't known If this happens to you, you probably have run the `configure' script with the `--with-bsdrts' option while your Unix is not fully BSD compliant. The solution is to rerun `configure' without the `--with-bsdrts' switch. I'm using Unix, and all my Pascal programs have linking problems. ================================================================= A number of Unix configurations use their system's linker instead of GNU `ld'. Usually, GPC and GCC need a program called `collect2' before calling the system's `ld'. `collect2' is installed by GCC, and if you only install GPC, it will not find `collect2', and use the system linker directly, which will result in various linker errors. The solution is to copy `collect2' by hand from the GCC directory to the location where `gpc1' lives. How do I debug my Pascal programs? ================================== To debug your programs, (a) GNU Pascal must be able to generate executables with debug info for your platform, and (b) you must have a debugger which understands this. * If `gpc -g -o hello hello.p' says: `gpc: -g not supported for this platform', then GPC is unable to generate debug info. Usually, installing GAS instead of your system's assembler can overcome this. When you configure the GCC used for GPC, specify `-with-gnu-as', and possibly `-with-gnu-ld' and/or `-with-stabs'. More information can be found in `INSTALL' file in the GNU CC source directory. * Your system's debugger may not understand the debug info generated by GNU tools. In this case, installing GDB may help. The bottom line: if you can debug GCC compiled programs, you should be able to do this with GPC too. The GNU debugger (GDB) currently does not have a "Pascal" mode, so it is unable to display certain Pascal structures etc. When debugging, please note that the Initial Letter In Each Identifier Is In Upper Case And The Rest Are In Lower Case. If you want to display variable `foo' in the debugger, type `show Foo' or `display Foo' instead. Can you recommend an IDE? ========================= Users of Borland Pascal may wonder if there's a replacement for the IDE (Integrated Development Environment). Here's a few suggestions: * (X)Emacs. Some people think it's the answer to the question of Life, the Universe and Everything, others decide it's uGNUsable. Available from your friendly GNU mirror. * XWPE is an imitation of the Borland IDE, so users of Borland Pascal may find it a good alternative. * RHIDE. djgpp users should definately try RHIDE. The latest (beta) release is compatible with GNU Pascal and allows stepping, tracing and watching like Borland's IDE. RHIDE v0.6 beta can be downloaded from: http://www.tu-chemnitz.de/~rho/rhidetest.html Although GDB is an excellent debugger, it's user interface is not very attractive. Refer to the comp.windows.x FAQ: "Where can I get an X-based debugger?" at: http://www.cis.ohio-state.edu/hypertext/faq/usenet/x-faq/part6/faq-doc-2.htm l Some useful frontends include: XXGDB, tGDB and XWPE. see: http://www.ee.ryerson.ca:8080/~elf/xapps/Q-IV.html Very nice, but resource consuming is the Motif based DDD: http://sol.ibr.cs.tu-bs.de/softech/ddd/ Do you have a binary for me? ============================ Currently, we have binaries for these platforms: i486-linux (ELF) i486-linuxaout i486-linuxoldld i386-freebsd1.2.0 djgpp V2 (msdos) emx 0.9B (OS/2, msdos) cygwin32 beta16 (Windows95, Windows NT) mips-sgi-irix5.3 sun-sparc-sunos4.1.4 New binaries may have been added after the release of this FAQ. 3.0 GNU Pascal and your system libraries **************************************** This section discusses common problems people have when they try to access their system's libraries. How do I use <insert_your_function_here> from the C library? ============================================================ GNU Pascal can use every function of your C library, but it may be up to you to write declaration of an external function, before you can use it. Consider the function `sleep'. `man(3) sleep' reveals: --------------------------------------------------------- NAME sleep - Sleep for the specified number of seconds SYNOPSIS #include <unistd.h> unsigned int sleep(unsigned int seconds); --------------------------------------------------------- This small demo program shows how to use `sleep' in a Pascal program: --------------------------------------------------------- program SleepDemo; type word = __unsigned__ integer; function sleep(seconds: word): word; C; var result : word; begin result := sleep(10); end. ---------------------------------------------------------- Are GNU Pascal objects compatible with GNU C++ classes ? ======================================================== No. (This may change in a future version) How do I build/use a shared library? ==================================== (topic under construction) 4.0 STRINGS *********** What's this confusion about strings? ==================================== Turbo Pascal strings have a length byte in front. Since a byte has the range 0 - 255, this limits a string to 255 characters. However, the Pascal string schema, as defined in section 6.4.3.3.3 of the ISO-10206: 1990 Extended Pascal standard, is a record: type string = record Capacity : integer; length : integer; string : packed array [ 1..Capacity ] of char; end; Thus at the expense of a little added complexity ( must declare capacity, don't use GetMem, and the additional space requiremnent ) you can now have very long strings. The following Q&A is also about strings: ======================================== Q: Should the different variants in a variant record overlay in the same memory? Previous Pascals I have used have guaranteed this, and I've got low-level code that relies on this. The variants are not the same length, and they are intended not to be. A: No, this is intentional so that the discriminants are not overwritten, and they can be properly initialized in the first place. Consider: record case Boolean of False: (s1 : String (42)); True: (s2 : String (99)); end; If the strings would overlay, in particular their disriminants would occupy the same place in memory. How should it be initialized? Either way, it would be wrong for at least one of the variants... So, after a discussion in comp.lang.pascal.ansi-iso where this topic came up concerning file variables (which also require some automatic initialization and finalization), we decided to do this in GPC for all types with automatic initialization and finalization (currently files and schemata, in the future this might also be Delphi compatible classes and user-defined initialized and finalized types), since the standard does not guarantee variants to overlay, anyway... There are two ways in GPC to get guaranteed overlaying (both non-standard, of course, since the standard does not assume anything about internal representations; both BP compatible), `absolute' declarations and variable type casts. E.g., in order to overlay a byte array to a variable v: var b: array [1 .. SizeOf (v)] of Byte absolute v; or type t = array [1 .. SizeOf (v)] of Byte; then `t (v)' can be used as a byte array overlayed to v. In standard pascal you expect ic[1] to align with the first character position of s and thus one character to the left is the length of s. Thus ic[0] is the length of s. True? This holds for UCSD/BP strings (which GPC does not yet implement, but that's planned). The only strings Standard Pascal knows are arrays of char without any length value. Q: Two different kinds of strings with the same name - string - does make a bit of confusion. Perhaps the oldstyle strings could be renamed "short string" ? A: When we implement the short strings, we'll have to do such a distinction. Our current planning goes like this: string (n): string schema (EP compatible) string [n]: short string (UCSD/BP compatible, where n must be <= 255) string: dependent on flags, by default undiscriminated schema, but in BP mode (or with a special switch) short string of capacity 255 (UCSD/BP compatible). ---- Frank Q: So when will these short strings be available? A: It's been planned for over a year. The delay has been caused by more pressing problems. What about C strings? ===================== A C string (`char *') is an array of char, terminated with a `NULL' char. C library functions require C, not Pascal style string arguments. However, Pascal style strings are automatically converted to C style strings when passed to a routine that expects C style strings. This works only if the routine reads from the string, not if it modifies it. E.g., this is how you access the `system()' call in your C library (which is not necessary any more, since `Execute' is already built-in): --------------------------------------------------------- program SysCall; function system(name : CString): integer; C; var result : integer; begin result := system ('ls -l'); writeln('system() call returned : ', result); end. --------------------------------------------------------- There may be other ways to do the same thing; you could declare a type `PChar' instead of `CString': type PChar = ^char; and replace all references to `CString' with `PChar'. Do *NOT* pass a "C" style string as a var-argument if the C prototype says `const char *' or you will get a coredump. You are right if you think this stuff belongs in a library, to be distributed with GPC. Have patience, or start coding! 5.0 GNU Pascal on the djgpp (MS-DOS) platform ********************************************* This chapter discusses some potential problems with GNU Pascal on MS-DOS, using djgpp. If you need more information ============================ GPC/djgpp is a djgpp V2 application, and most of the djgpp documentation applies for GPC too. A great source of information is the djgpp FAQ: http://www.delorie.com/djgpp/v2faq/faq202b.zip Another place to look for DJGPP documentation is the DJGPP Knowledge Base, at this URL: http://www.delorie.com/djgpp/doc/kb/ What do I download? =================== As discussed in section 2.2, other than GPC itself, you need an assembler, linker and friends, a C library and possibly a debugger. >From your local djgpp mirror, you can get these as: v2/djdev201.zip (C library) v2gnu/bnu270b.zip (assembler, ....) v2gnu/gdb416b.zip (debugger) The rest is up to you; `make' (v2gnu/mak375b.zip) can be useful, The latest RHIDE test release (an IDE with Borland-look) has support for GNU Pascal, and can be downloaded from: http://www.tu-chemnitz.de/~rho/rhidetest.html How do I install the compiler? ============================== If you don't have djgpp installed on your harddisk, create a directory for GNU pascal (`c:\gpc'), and unzip the archives. Make sure you preserve the directory structure (use `pkunzip -d'). Now, add the directory where `gpc.exe' lives (`c:\gpc\bin') to your path and set the DJGPP environment variable to point to your `djgpp.env' file: set DJGPP=c:\gpc\djgpp.env Then, add this to your `djgpp.env' file: --------------------------------------------------------- [gpc-cpp] C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/lang/pascal;%DJDIR%/include;%DJDIR %/contrib/grx20/include [gpc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/lib --------------------------------------------------------- The binary distribution should come with a `djgpp.env' which is already modified, so you may not have to do this. The GPC online documentation is in GNU info format; you need the info reader (`txi390b.zip') to read it. To add the GPC documentation to the info directory file, edit the `c:\gpc\info\dir' file, and locate this section: --------------------------------------------------------- * GCC: (gcc.inf). The GNU C, C++, and Objective-C Compiler * GDB: (gdb.inf). The GNU Debugger (gdb and gdb-dpmi). --------------------------------------------------------- To add GPC, change it to look like this: --------------------------------------------------------- * GCC: (gcc.inf). The GNU C, C++, and Objective-C Compiler * GPC: (gpc.inf). The GNU Pascal Compiler * GDB: (gdb.inf). The GNU Debugger (gdb and gdb-dpmi). --------------------------------------------------------- Specific information for low-memory conditions and more can be found in the djgpp FAQ and documentation. I cannot read the info pages! ============================= To read the info pages, you need the `info' program from `txi390b.zip'. At least for some of the pre-releases of `gpc-1.2', the `gpc.info' file is invalid: it refers to the `gpc.i*' sections as `gpc.info-*'. This can be fixed by loading `gpc.inf' in an editor and replacing `gpc.info-*' with `gpc.i*' GPC says: no DPMI ================= You don't have a DPMI server installed, and DJGPP v2 requires it to run. You can either use one of the commercial DPMI servers (e.g., run `gpc' in a DOS box under Windows) or download and install CWSDPMI (`csdpmi3b.zip') which is a free DPMI server written for DJGPP. I have troubles with assembly code ================================== The GNU Assembler (`as.exe'), or `gas', called by GCC accepts "AT&T" syntax which is different from "Intel" syntax. Differences are discussed in section 17.1 of the djgpp FAQ. A guide is available which was written by Brennan Mr. Wacko Underwood <brennan(a)mack.rt66.com> and describes how to use inline assembly programming with DJGPP, at this URL: http://www.rt66.com/~brennan/djgpp/djgpp_asm.html Section 17.3 of the djgpp FAQ discusses some methods to convert "Intel" syntax to "AT&T". Tell me how to do DPMI, BIOS and other DOS related things. ========================================================== DPMI, BIOS and other functions are no different than other system functions. Refer to section 3.1 how to access your system's C-library. This small example shows how to use DPMI, copying some structures and function prototypes of `<dpmi.h>': --------------------------------------------------------- program dpmitest; {$X+} type word = __unsigned__ integer; short = __short__ integer; byte = __byte__ integer; type PDpmiVersionRet = ^TDpmiVersionRet; TDpmiVersionRet = record major : byte; minor : byte; flags : short; cpu : byte; master_pic : byte; slave_pic : byte; end; type PDpmiFreeMemInfo = ^TDpmiFreeMemInfo; TDpmiFreeMemInfo = record largest_available_free_block_in_bytes : word; maximum_unlocked_page_allocation_in_pages : word; maximum_locked_page_allocation_in_pages : word; linear_address_space_size_in_pages : word; total_number_of_unlocked_pages : word; total_number_of_free_pages : word; total_number_of_physical_pages : word; free_linear_address_space_in_pages : word; size_of_paging_file_partition_in_pages : word; reserved1 : byte; reserved2 : byte; reserved3 : byte; end; function DpmiGetVersion(ret: PDpmiVersionRet): integer; asmname '__dpmi_get_version'; function DpmiGetFreeMemoryInformation(info: PDpmiFreeMemInfo): integer; asmname '__dpmi_get_free_memory_information'; var version: TDpmiVersionRet; meminfo: TDpmiFreeMemInfo; begin DpmiGetVersion(@version); writeln('CPU type : ', version.cpu, '86'); writeln('DPMI major : ', version.major); writeln('DPMI minor : ', version.minor); DpmiGetFreeMemoryInformation(@meminfo); writeln('Free DPMI memory : ', meminfo.total_number_of_free_pages, ' pages.'); end. --------------------------------------------------------- I'm accessing an `array[1..4000000] of byte' and I got an exception. ==================================================================== Per default, the maximum stack size of a djgpp application is 256K. If you need more, you have to adjust it with the stubedit program, i.e.: stubedit your_app.exe minstack=5000K Still, it might be a good idea to use pointers for this kind of structures, and allocate the memory at runtime. 6.0 Getting Help **************** This section discusses ways to get help with GNU Pascal. Please read the documentation (info files, readme's) that come with GPC, plus other docs that might help (the djgpp FAQ if you use djgpp etc.) before you send email to the maintainers or mailing list. Help! The compiler crashed! =========================== If the compiler crashes, you have discovered a bug. A reliable compiler never crashes. To help the maintainers fix this bug, it is important that you send us a problem report. I think I found a bug - now what? ================================= Bugs are best reported to the GPC mailinglist <gpc(a)hut.fi>. That way, they always reach the maintainers. Try to give as much information as possible, plus a short code snippet that triggers the compiler bug. If you're on Unix, you can find out where the compiler crashed if you enable coredumps, then load the compiler (`gpc1') plus the core file in the debugger (`gdb /your_path_here/gpc1 core'), then type `backtrace' to get a stacktrace. Include this stacktrace in your bug report. Which newsgroup(s) are suited for GPC related problems? ======================================================= There are several Pascal related newsgroups, but none is dedicated just to GNU Pascal. This one may be useful: comp.lang.pascal.misc Pascal in general and ungrouped Pascals. Pascal syntax related questions may be appropriate in: comp.lang.pascal.ansi-iso Pascal according to ANSI and ISO standards. comp.lang.pascal.borland Borland Pascal questions. How to post to the mailing list =============================== You can send a message to the GPC mailing list by sending email to the list address <gpc(a)hut.fi> as if it were a person. How to become a subscriber to the mailing list ============================================== You can join the mailing list by sending a message to <gpc-request(a)hut.fi> (NOT <gpc(a)hut.fi> !) with your request to be added to the list. Maintenance is done by hand, so some delay is possible. How to unsubscribe from the mailing list ======================================== To leave the mailing list, send a message to <gpc-request(a)hut.fi>. 7.0 Miscellaneous ***************** I want to contribute; where do I start? ======================================= A list of jobs which should be done for GNU-Pascal can be found in the section "How to contribute" of the Texinfo deocumentation. In cases where somebody is already working on a topic, the name of that person is written behind the job's description. This does not mean that you shouldn't do that but just that you should get in contact with that person if you would like to contribute to that field. Where is the GNU Pascal FTP site? WWW? ====================================== The master FTP site for GNU Pascal is `kampi.hut.fi'. GNU Pascal related files can be found in: ftp://ftp.kampi.hut.fi/jtv/gnu-pascal/ This site is mirrored on: ftp://sunsite.doc.ic.ac.uk/gnu/pascal/ The latest developer releases can be downloaded from: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/ Also, we have a homepage on the web: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/ About this FAQ. =============== Original Maintainer: J.J. van der Heijden <j.j.vanderheijden(a)student.utwente.nl> Current Maintainer: Russ Whitaker <russwhit(a)mind.net> This is the second incarnation of the GNU Pascal FAQ list. Comments about, suggestions for, or corrections to this FAQ list are welcome. Please make sure to include in your mail the version number of the document to which your comments apply (you can find the version at the beginning of this FAQ list). Much of the info in, and inspiration for this FAQ list was taken from the gpc mailing list traffic, so you may have (unbeknownst to you) contributed to this list.

3 2

Binaries for Solaris 8
by Mariusz Zynel 01 Feb '00

01 Feb '00

Hi All Binaries for Solaris 8 (Sparc and Intel) are now available on: http://math.uwb.edu.pl/download/solaris8/ ftp://mizar.uwb.edu.pl/pub/misc/solaris8/ Hope someone uses it -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

2 1

Re: Compiling gpc-19991030 fails on rts.c
by Frank Heckenbach 24 Jan '00

24 Jan '00

J. David Bryan wrote: > On 21 Jan 00, at 9:58, Dr A Olowofoyeku wrote: > > > Your problem is probably due to things that are missing in the gcc Mingw > > libraries (and there are many of them). > > I have tracked my specific problem down to the lack of a "pwd.h" file in > Mingw (thanks, Chief!). The trouble is that "_p_pwl2c" in "rts.c" > references the "passwd" struct, which is defined in "pwd.h", but "pwd.h" > isn't part of Mingw. This is detected by the Pascal "configure", which > sets "#undef HAVE_PWD_H" in "rts-config.h" but is not covered by alternate > code in "rts.c". The result is a syntax error when compiling. As I said, the current code (to be released as a snapshot soon) contains such a check. However, no alternate code (just a failure result) -- if there's equivalent functionality on other systems (which I don't know about), I'll have to leave it to you to add it... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Compiling gpc-19991030 fails on rts.c
by J. David Bryan 23 Jan '00

23 Jan '00

Dear ListFolks, I am attempting to make an i486-pc-mingwmsvc (i.e., Windows NT standalone) version of the latest gpc alpha (gpc-19991030) using the Cygwin B20.1 emulation, and I get a compilation error when the build process attempts to make the run-time library. Specifically, I get: /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c: At top level: /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:577: warning: `struct passwd' declared inside parameter list /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:577: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c: In function `_p_pwl2c': /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:579: dereferencing pointer to incomplete type /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:592: dereferencing pointer to incomplete type /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:593: dereferencing pointer to incomplete type /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:594: dereferencing pointer to incomplete type /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:595: dereferencing pointer to incomplete type I don't know enough C to be sure, but this looks like a syntax error. Surely, though, it must compile on other systems, so I'm stumped. Perhaps it has something to do with the Cygwin-specific version of gcc? As far as I can tell, everything was unloaded, patched, and configured correctly. The compiler itself appears to have been made correctly, i.e., I have xgpc.exe, gpc1.exe, and gpc-cpp.exe in the object directory. The invocation on the RTL appears to be: ../../i486-pc-mingwmsvc-gcc -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat /usr/local/src/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` -v /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c I've tried compiling rts.c with gcc-2.8.1 as a test, and I get the same error. Could someone point me in the right direction? Thanks! -- Dave

2 4

Re: Compiling GCC on HP-UX 10.20
by Frank Heckenbach 22 Jan '00

22 Jan '00

Mason Ip wrote: > 5. GNU autoconf may be necessary; although I did hack a Makefile to get > rid of the Âautoheader not foundÂ error without having GNU autoconf > installed. But lately I just install GNU autoconf to get rid of the trouble. Usually, you should not need autoconf if you just want to install GPC (or most other packages as well). autoconf is used by the developers to create the configure scripts which are invoked during building GPC. You should only need autoconf if you've changed the configure.in file or something like that... > -- B) error messages start here -- > ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings > -Wmissing-prototypes -Wmissing-declarations -O2 -g -O2 > -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat > /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ > x@with_shared@ = xyes ] ; then echo -fPIC; fi` > --unit-path=/opt/OV/tmp/gcc-2.95.2/gcc/p/rts --automake > /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/files.pas > /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/string2.pas: In function `Getenv': > /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/string2.pas:193: internal > error--unrecognizable insn: > (insn 15 14 17 (set (zero_extract:SI (reg:SI 97) > (const_int 32 [0x20]) > (const_int 0 [0x0])) > (reg:SI 98)) -1 (insn_list 12 (insn_list 14 (nil))) > (expr_list:REG_DEAD (reg:SI 98) > (nil))) > gpc1: ../.././xgpc exited with status 1 > /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/files.pas:30: module/unit `string2' could > not be compiled > make[3]: *** [files.o] Error 1 This problem seems to be in the compilation of CString2String. Since Peter is working on the string handling, anyway, there might be some hope that it will be fixed soon. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: compiling GPC on HP-UX
by Frank Heckenbach 22 Jan '00

22 Jan '00

Mason Ip wrote: > Thanks Frank, > I used to use Solaris and seldom worked on HP myself. > I did get gcc binary package from HP's web site. Although I was surprised to > learn gnu ld won't compile on HP. I know that GNU ld doesn't compile for MIPS/IRIX, either, so I'm not too surprised. I suppose, the (binary) GCC uses HP's linker, does it (if unsure, you can check it by watching the output of `gcc -v')? If so, GPC should be able to do the same (and as far as I understood the problems, so far they only concerned the assembler, not the linker, anyway). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Compiling gpc-19991030 fails on rts.c
by Frank Heckenbach 21 Jan '00

21 Jan '00

"Dr A Olowofoyeku" wrote: > On 20 Jan 00, at 22:42, J. David Bryan wrote: > > > I am attempting to make an i486-pc-mingwmsvc (i.e., Windows NT > > standalone) version of the latest gpc alpha (gpc-19991030) using the Cygwin > > B20.1 emulation, and I get a compilation error when the build process > > attempts to make the run-time library. Specifically, I get: > > > > /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c: At top level: > > /usr/local/src/gcc-2.95.2/gcc/p/rts/rts.c:577: warning: `struct passwd' > > declared inside parameter list > > > > [...] The problem occurs because the RTS tries to use `struct passwd' though the C headers don't contain it. The next snapshot will solve the problem by adding an autoconf check and not using `struct passwd' if not available. > Your problem is probably due to things that are missing in the gcc > Mingw libraries (and there are many of them). However, I have been > able to produce a Mingw version of the RTS. It has involved a lot of > patches, C macros in a new header (we presently call it 'os- > hacks.h'), and sources going back and forth between Frank and me. > The good news is that the next gpc snapshot will probably solve > these problems that you are having. > > I am quite disorganised at the moment, having just arrived back from > down under. But when I am more settled, I can send you a copy of > my 'os-hacks.h' file. Frank can tell you where you need to '#include' > it. The best I can tell you right now is to wait for the next snapshot, and then use it together with `os-hacks.h'. Though using `os-hacks.h' with the last alpha should yield some improvements already, it will not solve all problems and probably cause you additional debugging effort for problems that have been solved recently, like the one above... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

None
by Ivan Torshin 21 Jan '00

21 Jan '00

Hello, I'm trying to compile GPC under linux using unix sources. (in order to compile pascal programs written for BP 7.0 but it is another story). The GCC 2.95 and GPC were downloaded and dealt with as it is described in the GPC/p/INSTALL file. Howevre, there are no diff file gcc-2.95.diff and mkdiff script also seems to be of little use (for making this file). running make LANGUAGES=pascal in the outer (gcc) directory does not lead to gpc executable, of course. Could someone help me with it? I'm a novice in compiling compilers, as usually all DOS/Windows programs are ready made, although may contains viruses. Thank you, Ivan.

3 5

GRAPH
by Nash Jamie 21 Jan '00

21 Jan '00

This is my first message to this list, hello to you all...... I'm an Ex-TP programmer, but now 99% of my code is written in DELPHI. I was wondering if there is an equivilent to the old GRAPH unit with TP for gpc? If so what is it? Do I have it? (I thought I downloaded everything) And if I don't have it, could someone send it to me??????? (If it exists obviously......) Preferably binary (Linux) or source to the above address Thanks alot..... Jamie

2 1

build failure on Alpha
by Andreas Jaeger 21 Jan '00

21 Jan '00

I tried to compile gpc-19991030.tar.gz with gcc 2.95.2 on Alpha/Linux and got the following build failure: ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 -O2 -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat /tmp/gcc/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/tmp/gcc/gcc-2.95.2/gcc/p/rts --automake heap.pas error.pas: In function `Geterrormessage': error.pas:365: Internal compiler error in `copy_to_mode_reg', at explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../.././xgpc exited with status 1 heap.pas:30: module/unit `error' could not be compiled make[3]: *** [heap.o] Error 1 make[3]: Leaving directory `/tmp/gcc/gcc-2.95.2/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/tmp/gcc/gcc-2.95.2/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/tmp/gcc/gcc-2.95.2/gcc' make: *** [bootstrap] Error 2 Sorry, no gdb backtrace for now. Btw. I tried to search the mailing list archives - but the last archives I could find are from October 1999. What happened to the archives? Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

2 1

Re: compiling GPC on HP-UX
by S. Achterop IWI-120 3932 21 Jan '00

21 Jan '00

Frank Heckenbach wrote: > .... > > I've never used HP/UX so I don't know exactly what you need. Is > there someone on this list using HP/UX? > We're using HP/UX here. But the most recent version that we got to work here is an alpha version date 19980901 together with egcs-1.1. The newer alpha versions fail to compile. I mailed this to the gpc-list November 3 1999, but regrettably the archive does not contain messages after Oktober 1999. But anyway the gas problem (and solution) is described in the gcc documentation. The ad hoc solution that I have been using several years is the following. First: you need gas. Before making gcc/gpc: put a symbolic link such as "ln -s /usr/local/bin/gas as" in the gcc-build directory. The make process will use this "as". After installing: e.g. in /opt/gcc, add the same symbolic link in the directory where the main compiler code resides, e.g. in /opt/egcs/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.57/ (in our case) The gcc/gpc version will use this "as". This kludge has always worked for me. But again current gpc will fail to compile:(. Sietse

2 1

Re: compiling GPC on HP-UX
by Frank Heckenbach 21 Jan '00

21 Jan '00

Mason Ip wrote: > I got gnu as; and it choked on gnu as with something like Âas : > /var/tmp/xyz.s Â. Something unknownÂ on some *.c files. > I wiped the whole thing out so I no longer had the error messages. With this information, I can't say much about it... Perhaps you might want to ask the GCC list <gcc(a)gcc.gnu.org> how they get GCC running on HP/UX. They might also have the required binaries (except GPC). I've never used HP/UX so I don't know exactly what you need. Is there someone on this list using HP/UX? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

RE: compiling GPC on HP-UX
by Mason Ip 21 Jan '00

21 Jan '00

Thanks Frank, I used to use Solaris and seldom worked on HP myself. I did get gcc binary package from HP's web site. Although I was surprised to learn gnu ld won't compile on HP. Doing web search find me nothing on gpc associated with HP. I would appreciated if anyone has links to gpc / gnu-ld on HP. It seemed to me that I still have lot of things to learn especially on HP. Thanks again. > ---------- > From: Frank Heckenbach[SMTP:frank@g-n-u.de] > Sent: Monday, January 17, 2000 5:33 PM > To: gpc(a)gnu.de > Subject: Re: compiling GPC on HP-UX > > Mason Ip wrote: > > > I got gnu as; and it choked on gnu as with something like "as : > > /var/tmp/xyz.s Â…. Something unknown" on some *.c files. > > I wiped the whole thing out so I no longer had the error messages. > > With this information, I can't say much about it... > > Perhaps you might want to ask the GCC list <gcc(a)gcc.gnu.org> how > they get GCC running on HP/UX. They might also have the required > binaries (except GPC). > > I've never used HP/UX so I don't know exactly what you need. Is > there someone on this list using HP/UX? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html >

1 0

Compiling GCC on HP-UX 10.20
by Mason Ip 21 Jan '00

21 Jan '00

I started this thread last week when I reported the following errors (see below) when compiling gcc-2.52.2-gpc-19991030 on HP-UX 10.20. There had been a series of discussions on how to compile GCC (without GPC) on HP. I try to summarize the issues here. 1. you need GBU binutils to get the assemler (as); HPÂ’s as seemed not working well in building GCC 2. GNU linker (ld), which is a part from GNU binutuils, could not be built. A poster (in comp.sys.hp.hpux) commented on building GNU ld on HP below. Â“You can't -- it's not supported. Reason: HP's odd binary format.Â” 3. Now even if you have GNU Â“asÂ” and HPÂ’s Â“asÂ” on your HP box, and you have GNU Â“asÂ” before HP Â“asÂ” in your $PATH, GCC compilation cannot be guaranteed to use GNU Â“asÂ”. One trick a poster (in gpc.gnu.de) had suggested is to soft-link GNU Â“asÂ” to GCCÂ’s build directory. This same trick was also suggested by another poster in in comp.sys.hp.hpux. 4. HPÂ’s sed was buggy in that it put time stamps onto some files, making the build to complain. The resolution was two fold : get a patch from HP to patch HPÂ’s sed, or get GNU sed. 5. GNU autoconf may be necessary; although I did hack a Makefile to get rid of the Â“autoheader not foundÂ” error without having GNU autoconf installed. But lately I just install GNU autoconf to get rid of the trouble. 6. A script suggested by a poster (in comp.sys.hp.hpux) help in the building of GCC-2.95.2. I modified it a bit to add comment and add log-files. See the scripted attached at the end of this message. I have succeeded in build GCC-2.95.2 (without GPC) using this script (and the pre-requsites : autoconf, gnu sed, gnu as). Yet I got the same errors (attached at the end) using the same script for GCC-2.95.2-plus-GPC-19991030. So, it seemed to be a GPC bug when comparing the two builds (GCC built OK; GCC-GPC built failed). I hope someone could reproduce the problem on their HP-UX, just to rule out error due to my inexperience on HP-UX. Thanks a lot for your attention. (two attachments below) -- A) build-gcc script started here Â– #!/bin/sh # building gcc-2.95.2 on HP-UX build_root=/opt/OV/tmp cd $build_root # gunzip -qc gcc-2.95.2.tar.gz | tar xvf - # assume $build_root/gcc-2.95.2 contains source for gcc (and gpc) mkdir gcc-2.95.2-hpux-objs # $build_root/gcc-2.95.2-hpux-objs as a separate dir to hold the objects cd gcc-2.95.2-hpux-objs touch config.log1 # $build_root/gcc-2.95.2-hpux-objs/config.log1 as log-file to configure ../gcc-2.95.2/configure --enable-shared --with-gnu-as --without-gnu-ld --enable-cpp --prefix=/opt/GCC2952 >> config.log1 2>&1 cd gcc ln -s /opt/binutils/bin/as as # $build_root/gcc-2.95.2-hpux-objs/gcc/as now points to /opt/binutils/bin/as cd .. touch make.log1 # $build_root/gcc-2.95.2-hpux-objs/make.log1 as log-file to make echo make bootstrap started at `date` >> make.log1 make bootstrap >> make.log1 2>&1 echo make bootstrap started at `date` >> make.log1 -- build_gcc script end -- -- B) error messages start here -- tail -20 make.log1 ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/opt/OV/tmp/gcc-2.95.2/gcc/p/rts --automake /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/heap.pas ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/opt/OV/tmp/gcc-2.95.2/gcc/p/rts --automake /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/files.pas /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/string2.pas: In function `Getenv': /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/string2.pas:193: internal error--unrecognizable insn: (insn 15 14 17 (set (zero_extract:SI (reg:SI 97) (const_int 32 [0x20]) (const_int 0 [0x0])) (reg:SI 98)) -1 (insn_list 12 (insn_list 14 (nil))) (expr_list:REG_DEAD (reg:SI 98) (nil))) gpc1: ../.././xgpc exited with status 1 /opt/OV/tmp/gcc-2.95.2/gcc/p/rts/files.pas:30: module/unit `string2' could not be compiled make[3]: *** [files.o] Error 1 make[3]: Leaving directory `/opt/OV/tmp/gcc-2.95.2-hpux-objs/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/opt/OV/tmp/gcc-2.95.2-hpux-objs/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/opt/OV/tmp/gcc-2.95.2-hpux-objs/gcc' make: *** [bootstrap] Error 2 - error message end here Â–

1 0

Compiler error
by Moore, Jason 21 Jan '00

21 Jan '00

Hello all. I am getting a strange compiler error and I don't know why. Maybe one of you can help. In one global file I have: DevMdType = ( DevShared, DevExclusive ); In another file I have this: PROCEDURE LPOpen ( LPDevMode : DevMdType; VAR LPStatus : SHORTINT ); Still later, I try to call LPOpen: LPOpen (DevShared, PrnStatus); And I get "incompatible type for argument 1 of `Lpopen'" Shouldn't this work? Thanks -Jason

1 0

pointers, arrays
by Klaus Friis Østergaard 21 Jan '00

21 Jan '00

Thanks for the help with dynamic allocation of arrays. Can any body help me with these two questions: 1) Is it possible to use a notation like the this in C: item->next_item->data->name = 'test name' and if it is, how is it done? 2) To get data out of an array by the help of pointers type arraytype = array[1..100, 1..100] of interger; var a: arraytype; k : ect.. .. max :=0; for k := 51 to 100 begin if A[50,k]>max then max := A[50,k]; end; or for k := 51 to 100 begin if A[k,50]>max then max := A[k,50]; end; I am thinke of something like this not very nice example: finish_ptr := addrs(A[50,100]) a_ptr := addrs(A[50,51]) max_ptr := a_ptr; incrementing value/function ? while a_ptr <> finish_ptr do begin (a_ptr := a_ptr + incrementionvalue) / (incremention function (a_prt)); if a_ptr > max_ptr then max_ptr := a_ptr; end; If it is possible how do I calculate the incrementation value(x) for both A[50, 51+x] and A[51+x,50] or make a function/procedure? 3) Is there a good place or textbook to find information about working with pointers in pascal and datastructures? I will be gratefull for any help, klaus

2 1

RE: compiling GPC on HP-UX
by Mason Ip 17 Jan '00

17 Jan '00

I got gnu as; and it choked on gnu as with something like Â“as : /var/tmp/xyz.s Â…. Something unknownÂ” on some *.c files. I wiped the whole thing out so I no longer had the error messages. ---------- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Monday, January 17, 2000 3:25 PM To: gpc(a)gnu.de Subject: Re: compiling GPC on HP-UX Mason Ip wrote: > Well, I couldnÂ’t get gnu ld; binutils-2.9.1 package (from HPÂ’s site) had > Â“ldÂ” missing. > I fetched the source of binutils-2.9.1 and tried to build it myself with no > luck. > The configure script complained that Â“this configuration Â…. had problem > building ldÂ”. > So, IÂ’m still stuck with getting gnu ld before I can build gpc :-( But do you have GNU as? That's what your message complained about. If you configure with `--with-gnu-as' but without `--with-gnu-ld', it might work with GNU as and HP's ld. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: compiling GPC on HP-UX
by Frank Heckenbach 17 Jan '00

17 Jan '00

Mason Ip wrote: > Well, I couldnÂt get gnu ld; binutils-2.9.1 package (from HPÂs site) had > ÂldÂ missing. > I fetched the source of binutils-2.9.1 and tried to build it myself with no > luck. > The configure script complained that Âthis configuration Â. had problem > building ldÂ. > So, IÂm still stuck with getting gnu ld before I can build gpc :-( But do you have GNU as? That's what your message complained about. If you configure with `--with-gnu-as' but without `--with-gnu-ld', it might work with GNU as and HP's ld. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

RE: compiling GPC on HP-UX
by Mason Ip 17 Jan '00

17 Jan '00

Well, I couldnÂ’t get gnu ld; binutils-2.9.1 package (from HPÂ’s site) had Â“ldÂ” missing. I fetched the source of binutils-2.9.1 and tried to build it myself with no luck. The configure script complained that Â“this configuration Â…. had problem building ldÂ”. So, IÂ’m still stuck with getting gnu ld before I can build gpc :-( ---------- From: Nicholas Geovanis [SMTP:nickgeo@merle.acns.nwu.edu] Sent: Monday, January 17, 2000 9:23 AM To: gpc(a)gnu.de Subject: Re: compiling GPC on HP-UX On Sun, 16 Jan 2000, Frank Heckenbach wrote: > > gpc1: warning: -g option disabled. > > gpc1: warning: -g is only supported when using GAS on this processor, > > gpc1: warning: -g option disabled. > > Try giving configure the `--with-gnu-as' (and possibly also > `--with-gnu-ld') option. I haven't had to use it so far, but > according to the documentation, it should help... It was the case with older gcc's that the GNU assembler and loader were required instead of HP's on HPUX. I haven't looked at 2.95 yet, so I don't know if theis is still true with "post-reunification" gcc. If I recall, 2.7.2 still required gas. > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/

1 0

Re: compiling GPC on HP-UX
by Frank Heckenbach 17 Jan '00

17 Jan '00

Mason Ip wrote: > I had GNU {make, autoconf, automake, binutils, bison} on my $PATH on my > HP-UX. > I tried several times (first with gcc-2.7.2.1, second with all the GNU utils > installed, > third with gcc-2.95.2 binary installed) and got the same following error. > > Hope someone can help me. > > tail -20 make.log > gpc1: warning: -g option disabled. > gpc1: warning: -g is only supported when using GAS on this processor, > gpc1: warning: -g option disabled. Try giving configure the `--with-gnu-as' (and possibly also `--with-gnu-ld') option. I haven't had to use it so far, but according to the documentation, it should help... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

FAQ
by Russ Whitaker 17 Jan '00

17 Jan '00

Hi Read the FAQ - took notes Reread some of this mailing list - took notes So unless someone else has started to update the FAQ I'll volunteer. How soon do you need it? Russ <russwhit(a)mind.net>

2 1

Re: problems installing gpc on dos
by Frank Heckenbach 17 Jan '00

17 Jan '00

Yaron Cohen-Tal wrote: > i haven't found out how to install gpc on dos, or somewhere where it's > explained well how to do it. i managed to build simple hello program, > but once i add "uses crt" i get in the message window: > .. > .. > "f:\djgpp\lib\gcc-lib\djgpp\2.81\units\crt.c(34) Error: curses.h: no > such file or directory (ENOENT)" > "f:\djgpp\lib\gcc-lib\djgpp\2.81\units\crt.c(34) Error: curspriv.h: no > such file or directory (ENOENT)" > .. > .. > "module/unit crt could not be compiled" > i'd thank any1 who can help, coz ive spent days tryin to make some > 32-bit pascal compiler+ide work here. > yaron Please get the PDCurses library. It's available (in source and binary form) in ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

problems installing gpc on dos
by Yaron Cohen-Tal 16 Jan '00

16 Jan '00

i haven't found out how to install gpc on dos, or somewhere where it's explained well how to do it. i managed to build simple hello program, but once i add "uses crt" i get in the message window: .. .. "f:\djgpp\lib\gcc-lib\djgpp\2.81\units\crt.c(34) Error: curses.h: no such file or directory (ENOENT)" "f:\djgpp\lib\gcc-lib\djgpp\2.81\units\crt.c(34) Error: curspriv.h: no such file or directory (ENOENT)" .. .. "module/unit crt could not be compiled" i'd thank any1 who can help, coz ive spent days tryin to make some 32-bit pascal compiler+ide work here. yaron

1 0

compiling GPC on HP-UX
by Mason Ip 16 Jan '00

16 Jan '00

I am stuck on compiling GPC on HP-UX 10.20, and need some help. I got gcc-2.95.2 binuary from HP's web site; there was no gpc and that hence I needed to compile from the source. First, I merged gcc-2.95.2 with gpc-19991030. This merged source compiled OK and installed OK on Sparc Solaris 7. The same merged source, when compiled on HP-UX, was stuck when compiling GPC's rts/string2.pas. The following error was what I got. I had GNU {make, autoconf, automake, binutils, bison} on my $PATH on my HP-UX. I tried several times (first with gcc-2.7.2.1, second with all the GNU utils installed, third with gcc-2.95.2 binary installed) and got the same following error. Hope someone can help me. tail -20 make.log gpc1: warning: -g option disabled. gpc1: warning: -g is only supported when using GAS on this processor, gpc1: warning: -g option disabled. string2.pas: In function `Getenv': string2.pas:193: internal error--unrecognizable insn: (insn 15 14 17 (set (zero_extract:SI (reg:SI 97) (const_int 32 [0x20]) (const_int 0 [0x0])) (reg:SI 98)) -1 (insn_list 12 (insn_list 14 (nil))) (expr_list:REG_DEAD (reg:SI 98) (nil))) gpc1: ../.././xgpc exited with status 1 files.pas:30: module/unit `string2' could not be compiled make[3]: *** [files.o] Error 1 make[3]: Leaving directory `/opt/OV/tmp/gcc-2.95.2/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/opt/OV/tmp/gcc-2.95.2/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/opt/OV/tmp/gcc-2.95.2/gcc' make: *** [bootstrap] Error 2

1 0

Still porting
by Moore, Jason 10 Jan '00

10 Jan '00

We are trying to port some old code from SCO OpenServer to Linux. We need a c compiler that generates object files in coff format so we can link with our other object files. Can gcc do this? Thank you. -Jason

2 1

Problem in decompressing gpc-19990118.alphaev56-dec-osf4.0d.tar.gz
by Nuno Pinhão 10 Jan '00

10 Jan '00

Hi, I am trying to install gpc in a OSF1 Alpha system. However, I am unable to decompress gpc-19990118.alphaev56-dec-osf4.0d.tar.gz. I've already downloaded it three times (obviously in binary transfer mode), checked the version of gzip (it's version 1.2.4) [I've even downloaded the gzip source code and compiled] but without success... Is it possible that gpc-19990118.alphaev56-dec-osf4.0d.tar.gz is corrupted? What is your advice? Thank you Nuno Pinhao _______________________________________________________ ITN - Instituto Tecnologico e Nuclear _|_|_|_| Dr. Nuno R. Pinhao _|c|_|_| Computational Physics Group _|_|p|_| Physics Dept. _|_|_|_| Estrada Nacional 10 2685 Sacavem PORTUGAL fax: +351-1-994.15.25 mailto://npinhao@itn1.itn.pt mailto://n.pinhao@mail.telepac.pt http://newton.itn.pt/Users/Nuno _______________________________________________________

2 1

Compiler error with transferring dynamic arrays???
by Klaus Friis Østergaard 10 Jan '00

10 Jan '00

Hi all, Is this a compiler error or a programming error we I get junk in B in =the procedure the values are good enough. see below. program Type MyArray ( m, n ) = array [ 1..m, 1..n ] of Integer; Var B: ^MyArray; [...] Procedure BuildArray(var NewArray : MyArray; k: Integer); begin New ( NewArray, k, k); [...] For i := 1 to k NewArray^[3 ,k ]:= i+k; [...] end; begin buildArray(B, 10); For i := 1 to 10 begin Writeln(b^[3,i]; end; Dispose ( B ); [...] end. Klaus F. Østergaard Laser Technical Services A/S Sneppevang 3 3450 Allerød tel +45 48 17 61 61 fax +45 48 17 10 65 e-mail Laser(a)lasertech.dk

2 1

UNSUBSCRIBE
by Stanislav Anatolievich Vorontsov 10 Jan '00

10 Jan '00

1 0

Re: cannot compile gpc-19991030.tar.gz with gcc-2.95.2
by Russ Whitaker 09 Jan '00

09 Jan '00

quick question: did you put p under gcc-2.95.2/gcc ? this is a change from the old gcc-2.8/p hope this helps Russ <russwhit(a)mind.net> ---------- > From: George Shapovalov <georges(a)its.caltech.edu> > To: gpc(a)gnu.de > Subject: cannot compile gpc-19991030.tar.gz with gcc-2.95.2 > Date: Saturday, January 08, 2000 10:41 PM > > Hi > > I recently tried to install gpc on my box. I have Turbo Linux Workstation > 4.0.5 installed. I upgraded kernel to 2.2.13. Main compiler (under which this > distribution is compiled) is: egcs-2.91.60 19981201 (egcs-1.1.1 release) > installed under /usr. I also installed gcc-2.95.2 under /usr/local. I can > invoke and compile with any of them, however gpc source hase patch only against > gcc-2.95.2 (I grabbed the latest available version - gpc-19991030). > When I run ./configure or ../gcc-2.95.2/configure (I tried to build it from > source directory as well as from separate, as gcc-2.95.* suggests) it seems > that it does not find gpc. --enable-languages=pascal does not change that. When > I do make or make bootstrap there is no trace of gpc being built. When I do > make LANGUAGES=pascal it stops with: > "make[1]: *** No rule to make target `pascal', needed by `native'. Stop." > I even tried patching gcc-2.95.2 with gpc-19991030, then replacing p > subdirectory with the one from gpc-19990118 and building it over. I got the > same result. Also as described in building notes for gpc, specifying languages > to build when running make does not work anymore, and this is the way descrideb > in gpc installation notes. > So what is the correct way to build gpc now? > > I also tried using binary packages gpc-1990118. pi.pas from demos compiles > fine, but when I execute it I get "segmentation fault, core dumped". This looks > like some configuration problem. > > George >

1 0

Re: DOS, CRT Units?
by Frank Heckenbach 09 Jan '00

09 Jan '00

"Khimenko Victor" wrote: > > Sorry for this newbie question: > > > Where can I find Borland compatible > > replacement units (system, dos, crt)? > > They are included in latest versions of GPC. Youmust compile them manually > though: it's not part of installation process. Or you compile your programs with `--automake'. On OS/2, `--automake' probably has the same bugs as on Dos, so you might need `--autobuild' instead. (I'm writing a utility to solve these problems.) > > The gpc FAQ led me to believe that they > > do not yet exist, but people are discussing > > them so they must! > > AFAIK all existing documetation for GPC is REALLY old :-(( Could someone please take a gun a shoot this FAQ? ;-) Or, better yet, update it? :-) > > If it matters, I'm using the version of > > gpc running under EMX on OS/2. I'm trying > > to develop some statistical programs that > > will run under any version of gpc, however. > > Oh. I never tried to use gpc on non-*nix platform. It's possible to do > (even CRT can be compiled AFAIK) but I'm not know details... As said, you need the curses library. The libraries used (curses for CRT, and GMP for the GMP unit as well as RX for the RegEx unit, both not BP compatible units, but new GPC units) can be found on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/ There are binaries for some platforms, but not yet for EMX (you're the first one to ask for it). If you manage to compile them (which was quite easy under DJGPP and Cygwin, and at least PDCurses has special OS/2 build instructions and mentions EMX, so it seems to be supported), please upload them for the benefit of other users. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: DOS, CRT Units?
by Russ Whitaker 08 Jan '00

08 Jan '00

Jeff Miller wrote > Where can I find Borland compatible > replacement units (system, dos, crt)? They should be in a directory named units. Also of interest is a directory named demos. try find /usr/local -name units and find /usr/local -name demos The duplicate copies under /usr/local/src should be used as back-ups J.I.C. Hopes this helps Russ <russwhit(a)mind.net>

1 0

DOS, CRT Units?
by miller＠otago.ac.nz 08 Jan '00

08 Jan '00

Sorry for this newbie question: Where can I find Borland compatible replacement units (system, dos, crt)? The gpc FAQ led me to believe that they do not yet exist, but people are discussing them so they must! If it matters, I'm using the version of gpc running under EMX on OS/2. I'm trying to develop some statistical programs that will run under any version of gpc, however. Thanks for your help, Jeff Prof Jeff Miller Dept of Psychology University of Otago Dunedin, New Zealand International FAX: 64-3-479-8335 miller(a)otago.ac.nz http://psy.otago.ac.nz:800/staff/miller/welcome.htm

2 1

Problem building gcc-2.95.2/gpc
by Martin Liddle 08 Jan '00

08 Jan '00

I have successfully built gcc-2.95.2 and gpc on one of my Linux systems. I have just done a fresh install of Linux (RedHat 6.0) on a different system. I have installed the gcc-2.95.2 sources and the latest gpc snapshot (from the same tar files as used for the first installation). I have successfully applied the gpc patches. However when I try to ../gcc-29.2/configure --enable-languages=c++,pascal the process fails almost immediately with the message "config.guess failed to determine the host type. You need to specify one". By running configure on the first system I deduce the host type should be i586-pc-linux-gnu however specifying this leads to another error message. Clearly something is wrong with my Linux installation on the second machine (I guess a required package is not installed) but I can't figure out what to do. Anybody any suggestions as to what to do next? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324.

2 2

Trying to compile GPC19991030
by Alfredo Cesar Fontana 06 Jan '00

06 Jan '00

Hello: Happy New Year!. I've trying to compile GPC 19991030 in RedHat Linux 5.2, 6.1, within then gcc 2.8.1 ( same as I did with the GPC 19990118 ) but I met that the set_word_size and set_word_big_endian in the pascal_init function in the file util.c are undeclared. I also try to compile within the gcc 2.95 source ( RH Linux 6.1 ). But there is not recognice the pascal language. Is there any suggestion? ... Alfredo

2 1

Re: GPC Strings
by Frank Heckenbach 06 Jan '00

06 Jan '00

"Larry Carter" wrote: > Hi everyone, > > I apologize if this subject has been discussed already, but since I could > find no mention of it on either the GPC to-do pages or in the mailing list > archives I thought that I would bring it up. > > I know that the current GPC string standard has no length limitation, but > do you have to define the max length when declaring varaiables? And if so, > why? One nice thing about Delphi's "AnsiStrings" is that they are > dynamically assigned their length based on the length of the string > assigned. Also, they are reference counted so that copies of a string do > actually take up memory. > > The reason that I am wondering about this is that I am writing a small > unix utility that needs to parse file names (with path in some cases) and so > I need strings long enough to accomodate these names. However, I don't want > to be wasting memory declaring for example, > > strWork : String(2048); > > just to hold "HelloWorld.c" or even "/home/user/HelloWorld.c" but still be > able to take care of those evil ones like > "/usr/X11R6/lib/X11/shared/icons/samples/commercial/YourFriendlyNeighborhood > ComputerGuy.txt" as an example (ok, a stupid one, but...). > > > Is there a way to do this with existing GPC strings? If not, what about > supporting Delphi's string type that would allow > > strWork : String; > > and still accomodate any string needs up to available memory? This is planned ("undiscriminated strings" on the To-Do list), but currently we don't have the time to implement it, so it will have to wait... :-( Currently, the only way to do what you want is to use pointers and allocate memory dynamically as you need it. You can do: var p : ^String; { without length limitation } [...] New (p, 42); { allocate space for a string of length 42 } p^ := 'some text which is no longer then 42 chars'; [...] Dispose (p); Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

GPC Strings
by Larry Carter 06 Jan '00

06 Jan '00

Hi everyone, I apologize if this subject has been discussed already, but since I could find no mention of it on either the GPC to-do pages or in the mailing list archives I thought that I would bring it up. I know that the current GPC string standard has no length limitation, but do you have to define the max length when declaring varaiables? And if so, why? One nice thing about Delphi's "AnsiStrings" is that they are dynamically assigned their length based on the length of the string assigned. Also, they are reference counted so that copies of a string do actually take up memory. The reason that I am wondering about this is that I am writing a small unix utility that needs to parse file names (with path in some cases) and so I need strings long enough to accomodate these names. However, I don't want to be wasting memory declaring for example, strWork : String(2048); just to hold "HelloWorld.c" or even "/home/user/HelloWorld.c" but still be able to take care of those evil ones like "/usr/X11R6/lib/X11/shared/icons/samples/commercial/YourFriendlyNeighborhood ComputerGuy.txt" as an example (ok, a stupid one, but...). Is there a way to do this with existing GPC strings? If not, what about supporting Delphi's string type that would allow strWork : String; and still accomodate any string needs up to available memory? Larry Carter lcarter(a)hbtn.portland.or.us

1 0

Porting to gpc
by Moore, Jason 05 Jan '00

05 Jan '00

I am a novice gpc user trying to port some code from an old Unix compiler to gpc. We have the following scattered throughout the code. Most of this code was written before I got here, so I take no credit. PString = STRING[255]; pPString = ^PString; . . . PPtr : pPString; . . . PPtr^ := ''; . . . PPtr^[0] := CHR(I); gpc is complaining about the PPtr^[0] line. If I change it to say "PPtr^ := CHR(I);" the compiler is happy, but we use this method several times to get the length of arrays or strings. Is there anyway to get gpc to allow this or does it violate the Pascal standard? -Jason

2 1

/usr/i486-linux/bin/ld: cannot open -l-
by Andreas Neumann 05 Jan '00

05 Jan '00

Hello! I tried to compile a pascal program on SuSE Linux 6.3 and got the following error: ------------------------------------------------------- /usr/i486-linux/bin/ld: cannot open -l-: Datei oder Verzeichnis nicht gefunden collect2: ld returned 1 exit status ------------------------------------------------------- seems like it compiles without problems but cannot link - seems like a file or lib is missing or a path is not set correctly any idea what the problem could be? Thanks for help, Andreas PS: the small demo files that come with gpc compile and run correctly -- ---------------------------------------------- Andreas Neumann - Department of Cartography Swiss Federal Institute of Technology (ETH) ETH Hoenggerberg, CH-8093 Zurich, Switzerland Phone: ++41-1-633 3037, Fax: ++41-1-633 1153 e-mail: andreas.neumann(a)karto.baug.ethz.ch www: http://www.karto.ethz.ch/~an/ Private Address: Rebbergstrasse 16/102, CH-8037 Zurich Phone: ++41-1-273 66 68

2 3

Integrating a compiler into the GCC back end
by Tim Josling 04 Jan '00

04 Jan '00

Hi, I am working on a COBOL compiler. My plan is to integrate into the GCC back end. I am looking at how to do this. Currently I have about 19,000 lines of code, which is the preprocessor plus the cobol nucleus grammar parser (cobol is a big language), at timjosling.homepage.com. Currently I have the book 'Using and Porting GCC', plus a sample integration of a toy language, as well as the fortran and pascal implementations. Which I am poring through at the moment. Given that you guys have already done this, I was wondering if there is anyone there who may be able/willing to answer some questions for me if I get roadblocked? I am not asking to be spoon fed, but sometimes someone just knows the answer to a question that may take ages to work out by yourself. Any suggestions about starting points, documentation, who to speak to, pros and cons of using the gcc back end are more than welcome. Tim Josling

2 1

GNU Pascal DLL Support
by Grace C. Jewitt 03 Jan '00

03 Jan '00

I am president of a small company (Interstate Robotics) formed as a corporation in April, 1997 in Wilmington, Delaware in order to exploit cost/performance opportunities that exist in niche markets that require video data acquisition, storage, processing, and display capability. To date we have focused on developing and obtaining patent protection for core technologies to include Direct Device Interfaces (DDIs) and a visual programming tool. The visual programming tool provides an efficient means of developing applications by drawing flow diagrams to represent the interaction between software components. A DDI is an Application Program Interface (API) and device driver hybrid providing desktop and/or Web-enabled applications with direct, language-independent access to a physical device in order to simultaneously optimize speed of execution and minimize utilization of computer resources. Existing DDIs which expose the functionality of graphics, timer/scheduler, physical memory, and video data acquisition devices. Our current projects are listed on the Global Project Marketing Network at http://gpmn.com. All of our source code is in BP 7.0. In order to utilize GNU Pascal it would need to provide the capability to make and use DLLs. Is this the case? Regards Grace Jewitt

2 1

Installing gpc
by Salaam Yitbarek 03 Jan '00

03 Jan '00

Hi, I'm having trouble installing gpc with an existing version of gcc . I followed the installation guidelines, copying /p into the gcc source directory, running configure from the gcc object directory, and running make with LANGUAGE=pascal. The only thing I didn't do was the patch--I tried it, and it didnt' work, presumably because it was expecting gcc 2.8.1. Here are the steps I follow: ----------------- # ls gcc gcc-2.95.2 gpc make-3.78.1 p2c # cd gcc # ../gcc-2.95.2/configure Configuring for a sparc-sun-solaris2.6 host. Created "Makefile" in /usr/local/src/gcc using "mh-frag" ./config.status is unchanged Configuring libiberty... loading cache ../config.cache checking host system type... sparc-sun-solaris2.6 checking build system type... sparc-sun-solaris2.6 checking for ar... (cached) ar checking for ranlib... (cached) ranlib checking for gcc... (cached) gcc checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for POSIXized ISC... no checking for a BSD compatible install... ../../gcc-2.95.2/libiberty/../install-sh -c xhost-mkfrag is unchanged checking how to run the C preprocessor... (cached) gcc -E checking for sys/file.h... (cached) yes checking for sys/param.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for strings.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking for asprintf... (cached) no checking for atexit... (cached) yes checking for basename... (cached) yes checking for bcmp... (cached) yes checking for bcopy... (cached) yes checking for bzero... (cached) yes checking for calloc... (cached) yes checking for clock... (cached) yes checking for getcwd... (cached) yes checking for getpagesize... (cached) yes checking for index... (cached) yes checking for insque... (cached) yes checking for memchr... (cached) yes checking for memcmp... (cached) yes checking for memcpy... (cached) yes checking for memmove... (cached) yes checking for memset... (cached) yes checking for mkstemps... (cached) no checking for putenv... (cached) yes checking for random... (cached) yes checking for rename... (cached) yes checking for rindex... (cached) yes checking for setenv... (cached) no checking for sigsetmask... (cached) no checking for strcasecmp... (cached) yes checking for strchr... (cached) yes checking for strdup... (cached) yes checking for strncasecmp... (cached) yes checking for strrchr... (cached) yes checking for strstr... (cached) yes checking for strtod... (cached) yes checking for strtol... (cached) yes checking for strtoul... (cached) yes checking for tmpnam... (cached) yes checking for vasprintf... (cached) no checking for vfprintf... (cached) yes checking for vprintf... (cached) yes checking for vsprintf... (cached) yes checking for waitpid... (cached) yes checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for ANSI C header files... (cached) yes checking for pid_t... (cached) yes checking for vfork.h... (cached) no checking for working vfork... (cached) no checking for sys_errlist... (cached) yes checking for sys_nerr... (cached) yes checking for sys_siglist... (cached) no checking for getrusage... (cached) yes checking for on_exit... (cached) no checking for psignal... (cached) yes checking for strerror... (cached) yes checking for strsignal... (cached) yes checking for sysconf... (cached) yes checking for times... (cached) yes checking for sbrk... (cached) yes checking for gettimeofday... (cached) yes creating ./config.status creating Makefile creating testsuite/Makefile creating config.h config.h is unchanged Configuring texinfo... loading cache ../config.cache checking for a BSD compatible install... ../../gcc-2.95.2/texinfo/../install-sh -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... missing checking for working autoconf... missing checking for working automake... missing checking for working autoheader... missing checking for working makeinfo... missing checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking whether gcc needs -traditional... (cached) no checking for a BSD compatible install... ../../gcc-2.95.2/texinfo/../install-sh -c checking for ranlib... (cached) ranlib checking for texconfig... (cached) false checking for POSIXized ISC... no checking for minix/config.h... (cached) no checking whether to enable maintainer-specific portions of Makefiles... no checking for Cygwin32 environment... (cached) no checking for Mingw32 environment... (cached) no checking for executable suffix... (cached) no checking for sigblock... (cached) no checking for sigblock in -lbsd... (cached) no checking for tputs in -lncurses... (cached) no checking for tputs in -lcurses... (cached) yes checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for pwd.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for termcap.h... (cached) no checking for termio.h... (cached) yes checking for termios.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/fcntl.h... (cached) yes checking for sys/file.h... (cached) yes checking for sys/ptem.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/ttold.h... (cached) yes checking for sys/wait.h... (cached) yes checking for off_t... (cached) yes checking return type of signal handlers... (cached) void checking for working const... (cached) yes checking whether struct tm is in sys/time.h or time.h... (cached) time.h checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for vprintf... (cached) yes checking for setvbuf... (cached) yes checking for getcwd... (cached) yes checking for memset... (cached) yes checking for bzero... (cached) yes checking for strchr... (cached) yes checking for strcasecmp... (cached) yes checking for sigprocmask... (cached) yes checking for sigsetmask... (cached) no checking for memcpy... (cached) yes checking for memmove... (cached) yes checking for strdup... (cached) yes checking for strerror... (cached) yes checking for inline... (cached) inline checking for size_t... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) yes checking for argz.h... (cached) no checking for limits.h... (cached) yes checking for locale.h... (cached) yes checking for nl_types.h... (cached) yes checking for malloc.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for values.h... (cached) yes checking for sys/param.h... (cached) yes checking for getcwd... (cached) yes checking for munmap... (cached) yes checking for putenv... (cached) yes checking for setenv... (cached) no checking for setlocale... (cached) yes checking for strchr... (cached) yes checking for strcasecmp... (cached) yes checking for __argz_count... (cached) no checking for __argz_stringify... (cached) no checking for __argz_next... (cached) no checking for LC_MESSAGES... (cached) yes checking whether NLS is requested... yes checking whether included gettext is requested... no checking for libintl.h... (cached) yes checking for gettext in libc... (cached) yes checking for msgfmt... (cached) /usr/bin/msgfmt checking for dcgettext... (cached) yes checking for gmsgfmt... (cached) /usr/bin/msgfmt checking for xgettext... (cached) /usr/bin/xgettext found xgettext programs is not GNU xgettext; ignore it checking for catalogs to be installed... de fr updating cache ../config.cache creating ./config.status creating Makefile creating doc/Makefile creating info/Makefile creating intl/Makefile creating lib/Makefile creating makeinfo/Makefile creating po/Makefile.in creating util/Makefile creating config.h config.h is unchanged Configuring gcc... loading cache ../config.cache checking LIBRARY_PATH variable... ok checking GCC_EXEC_PREFIX variable... ok checking host system type... sparc-sun-solaris2.6 checking target system type... sparc-sun-solaris2.6 checking build system type... sparc-sun-solaris2.6 checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking whether a default assembler was specified... no checking whether a default linker was specified... no checking for gawk... (cached) nawk checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking whether ln works... (cached) yes checking whether ln -s works... (cached) yes checking for volatile... (cached) yes checking for ranlib... (cached) ranlib checking for bison... (cached) bison -y checking for a BSD compatible install... ../../gcc-2.95.2/gcc/../install-sh -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking whether string.h and strings.h may both be included... (cached) yes checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking for limits.h... (cached) yes checking for stddef.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking for time.h... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for stab.h... (cached) no checking for sys/file.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/param.h... (cached) yes checking for sys/times.h... (cached) yes checking for sys/stat.h... (cached) yes checking for direct.h... (cached) no checking for thread.h... (cached) yes checking for pthread.h... (cached) yes checking for gnatbind... (cached) no checking whether cpp understands the stringify operator... (cached) yes checking for inttypes.h... (cached) yes checking for strtoul... (cached) yes checking for bsearch... (cached) yes checking for strerror... (cached) yes checking for putenv... (cached) yes checking for popen... (cached) yes checking for bcopy... (cached) yes checking for bzero... (cached) yes checking for bcmp... (cached) yes checking for index... (cached) yes checking for rindex... (cached) yes checking for strchr... (cached) yes checking for strrchr... (cached) yes checking for kill... (cached) yes checking for getrlimit... (cached) yes checking for setrlimit... (cached) yes checking for atoll... (cached) yes checking for atoq... (cached) no checking for sysconf... (cached) yes checking for isascii... (cached) yes checking for gettimeofday... (cached) yes checking for strsignal... (cached) yes checking for putc_unlocked... (cached) yes checking for fputc_unlocked... (cached) no checking for fputs_unlocked... (cached) no checking for vprintf... (cached) yes checking whether the printf functions support %p... (cached) yes checking for pid_t... (cached) yes checking for vfork.h... (cached) no checking for working vfork... (cached) no checking whether malloc must be declared... (cached) no checking whether realloc must be declared... (cached) no checking whether calloc must be declared... (cached) no checking whether free must be declared... (cached) no checking whether bcopy must be declared... (cached) no checking whether bzero must be declared... (cached) no checking whether bcmp must be declared... (cached) no checking whether index must be declared... (cached) no checking whether rindex must be declared... (cached) no checking whether getenv must be declared... (cached) no checking whether atol must be declared... (cached) no checking whether sbrk must be declared... (cached) no checking whether abort must be declared... (cached) no checking whether atof must be declared... (cached) no checking whether strerror must be declared... (cached) no checking whether getcwd must be declared... (cached) no checking whether getwd must be declared... (cached) no checking whether strsignal must be declared... (cached) no checking whether putc_unlocked must be declared... (cached) yes checking whether fputs_unlocked must be declared... (cached) yes checking whether strstr must be declared... (cached) no checking whether getrlimit must be declared... (cached) no checking whether setrlimit must be declared... (cached) no checking for sys_siglist declaration in signal.h or unistd.h... (cached) no checking if mkdir takes one argument... (cached) no Using `../../gcc-2.95.2/gcc/config/sparc/sparc.c' to output insns. Using `../../gcc-2.95.2/gcc/config/sparc/sparc.md' as machine description file. Using `../../gcc-2.95.2/gcc/config/sparc/sol2-sld.h' as target machine macro file. Using the following host machine macro files: ../../gcc-2.95.2/gcc/config/xm-siglist.h ../../gcc-2.95.2/gcc/config/sparc/xm-sysv4.h ../../gcc-2.95.2/gcc/config/sparc/xm-sol2.h checking for strerror in -lcposix... (cached) no checking for working const... (cached) yes checking for inline... (cached) inline checking for off_t... (cached) yes checking for size_t... (cached) yes checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) yes checking for argz.h... (cached) no checking for limits.h... (cached) yes checking for locale.h... (cached) yes checking for nl_types.h... (cached) yes checking for malloc.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/param.h... (cached) yes checking for getcwd... (cached) yes checking for munmap... (cached) yes checking for putenv... (cached) yes checking for setenv... (cached) no checking for setlocale... (cached) yes checking for strchr... (cached) yes checking for strcasecmp... (cached) yes checking for strdup... (cached) yes checking for __argz_count... (cached) no checking for __argz_stringify... (cached) no checking for __argz_next... (cached) no checking for LC_MESSAGES... (cached) yes checking whether NLS is requested... no checking assembler alignment features... checking assembler subsection support... checking assembler instructions... Using the Haifa scheduler. Links are now set up to build a native compiler for sparc-sun-solaris2.6 updating cache ../config.cache creating ./config.status creating Makefile creating intl/Makefile creating po/Makefile.in creating fixinc/Makefile creating cp/Makefile creating f/Makefile creating java/Makefile creating auto-host.h auto-host.h is unchanged linking ../../gcc-2.95.2/gcc/intl/libgettext.h to intl/libintl.h Merged sparc/x-sysv4. Merged sparc/t-sol2 and t-install-cpp. Created `ch/Makefile'. Merged sparc/x-sysv4. Merged sparc/t-sol2 and t-install-cpp. Created `objc/Makefile'. creating libintl.h Configuring etc... loading cache ../config.cache checking for a BSD compatible install... ../../gcc-2.95.2/etc/../install-sh -c creating ./config.status creating Makefile # make LANGUAGES=pascal make[1]: Entering directory `/usr/local/src/gcc/libiberty' rm -f needed-list; touch needed-list; \ for f in atexit calloc memchr memcmp memcpy memmove memset rename strchr strerror strrchr strstr strtol strtoul tmpnam vfprintf vprintf vfork waitpid bcmp bcopy bzero; do \ for g in asprintf.o mkstemps.o setenv.o sigsetmask.o vasprintf.o vfork.o ; do \ case "$g" in \ *$f*) echo $g >> needed-list ;; \ esac; \ done; \ done echo argv.o choose-temp.o concat.o cplus-dem.o fdmatch.o fnmatch.o getopt.o getopt1.o getruntime.o hex.o floatformat.o objalloc.o obstack.o pexecute.o spaces.o splay-tree.o strerror.o strsignal.o xatexit.o xexit.o xmalloc.o xstrdup.o xstrerror.o > required-list make[2]: Entering directory `/usr/local/src/gcc/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gcc/libiberty/testsuite' make[1]: Leaving directory `/usr/local/src/gcc/libiberty' make[1]: Entering directory `/usr/local/src/gcc/texinfo' make all-recursive make[2]: Entering directory `/usr/local/src/gcc/texinfo' Making all in intl make[3]: Entering directory `/usr/local/src/gcc/texinfo/intl' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/gcc/texinfo/intl' Making all in lib make[3]: Entering directory `/usr/local/src/gcc/texinfo/lib' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/gcc/texinfo/lib' Making all in makeinfo make[3]: Entering directory `/usr/local/src/gcc/texinfo/makeinfo' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/local/src/gcc/texinfo/makeinfo' make[2]: Leaving directory `/usr/local/src/gcc/texinfo' make[1]: Leaving directory `/usr/local/src/gcc/texinfo' make[1]: Entering directory `/usr/local/src/gcc/etc' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/gcc/etc' make[1]: Entering directory `/usr/local/src/gcc/gcc' gcc -DIN_GCC -DHAIFA -DSVR4 -g -O2 -DHAVE_CONFIG_H -I. -I../../gcc-2.95.2/gcc -I../../gcc-2.95.2/gcc/config -I../../gcc-2.95.2/gcc/../include \ -DGCC_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include\" \ -DGPLUSPLUS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../..`echo /usr/local | sed -e 's|^/usr/local||' -e 's|/[^/]*|/..|g'`/include/g++-3\" \ -DLOCAL_INCLUDE_DIR=\"/usr/local/include\" \ -DCROSS_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../sparc-sun-solaris2.6/sys-include\" \ -DTOOL_INCLUDE_DIR=\"/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../sparc-sun-solaris2.6/include\" \ -c `echo ../../gcc-2.95.2/gcc/cccp.c | sed 's,^\./,,'` gcc -DIN_GCC -DHAIFA -DSVR4 -g -O2 -DHAVE_CONFIG_H -I. -I../../gcc-2.95.2/gcc -I../../gcc-2.95.2/gcc/config -I../../gcc-2.95.2/gcc/../include \ -DLOCALEDIR=\"/usr/local/share/locale\" \ -c `echo ../../gcc-2.95.2/gcc/intl.c | sed 's,^\./,,'` gcc -DIN_GCC -DHAIFA -DSVR4 -g -O2 -DHAVE_CONFIG_H -I. -I../../gcc-2.95.2/gcc -I../../gcc-2.95.2/gcc/config -I../../gcc-2.95.2/gcc/../include \ -DPREFIX=\"/usr/local\" \ -c `echo ../../gcc-2.95.2/gcc/prefix.c | sed 's,^\./,,'` gcc -DIN_GCC -DHAIFA -DSVR4 -g -O2 -DHAVE_CONFIG_H -o cccp cccp.o cexp.o intl.o prefix.o version.o mbchar.o obstack.o alloca.o ../libiberty/libiberty.a rm -f cpp ln cccp cpp (cd intl && make all) make[2]: Entering directory `/usr/local/src/gcc/gcc/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/usr/local/src/gcc/gcc/intl' make[1]: *** No rule to make target `pascal', needed by `native'. Stop. make[1]: Leaving directory `/usr/local/src/gcc/gcc' make: *** [all-gcc] Error 2 # ----------------- Salaam Yitbarek

3 2

Re: Problem with rewrite on file of packed array of packed record
by Frank Heckenbach 30 Dec '99

30 Dec '99

David James wrote: > The attached program declares a direct access file whose elements are > PACKED ARRAYS of a PACKED RECORD. The program fails with error #405 > when a rewrite is issued for the file. Removing the PACKED from the > array declaration makes the error go away. Is this correct behaviour? It's a GPC bug. Thanks for the report. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Problem with rewrite on file of packed array of packed record
by david＠tcs01.demon.co.uk 30 Dec '99

30 Dec '99

The attached program declares a direct access file whose elements are PACKED ARRAYS of a PACKED RECORD. The program fails with error #405 when a rewrite is issued for the file. Removing the PACKED from the array declaration makes the error go away. Is this correct behaviour? program daj7(input,output); const maxcontrol = 170; maxcomp = 200; type TCHECK1=PACKED RECORD CHECH:0..47; (*6 bits*) CHECM:0..60; (*6 bits*) CHECS:0..60; (*6 bits*) CHECT:0..999; (*10 bits*) GENERATED:BOOLEAN; QUERY:BOOLEAN; from_audit:boolean; END; TCHECK=PACKED ARRAY [0..MAXCONTROL] OF TCHECK1; (*if declared as PACKED, get error 405 on the rewrite if not declared PACKED, runs OK*) var count:integer; f:file [0..maxcomp] of tcheck; begin rewrite(f,'daj7.fil'); (*./daj7: could not open `daj7.fil' (error #405) here *) for count:=0 to maxcomp do begin seekwrite(f,count); f^[0].chect:=count; put(f); end; close(f); reset(f,'daj7.fil'); for count:=1 to maxcomp do begin seekread(f,count); writeln(count:1,' ',f^[0].chect:1); end; close(f); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/> -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: Bug? Variants don't overlay when they contain strings
by Frank Heckenbach 30 Dec '99

30 Dec '99

David James wrote: > Should the different variants in a variant record overlay in the same > memory? > > Previous Pascals I have used have guaranteed this, and I've got > low-level code that relies on this. > > [...] > > (I know the variants are not the same length, and they are intended > not to be.) As you assumed in your latter mail, this is intentional so the discriminants are not overwritten, and they can be properly initialized in the first place. Consider: record case Boolean of False: (s1 : String (42)); True: (s2 : String (99)); end; If the strings would overlay, in particular their disriminants would occupy the same place in memory. How should it be initialized? Either way, it would be wrong for at least one of the variants... So, after a discussion in comp.lang.pascal.ansi-iso where this topic came up concerning file variables (which also require some automatic initialization and finalization), we decided to do this in GPC for all types with automatic initialization and finalization (currently files and schemata, in the future this might also be Delphi compatible classes and user-defined initialized and finalized types), since the standard does not guarantee variants to overlay, anyway... There are two ways in GPC to get guaranteed overlaying (both non-standard, of course, since the standard does not assume anything about internal representations; both BP compatible), `absolute' declarations and variable type casts. E.g., in order to overlay a byte array to a variable v: var b: array [1 .. SizeOf (v)] of Byte absolute v; or type t = array [1 .. SizeOf (v)] of Byte; then `t (v)' can be used as a byte array overlayed to v. Russ Whitaker wrote: > You have more than an overlay problem. In standard pascal you expect ic[ 1 > ] to align > with the first character position of s and thus one character to the left > is the length of s. > Thus ic[0] is the length of s. This holds for UCSD/BP strings (which GPC does not yet implement, but that's planned). The only strings Standard Pascal knows are arrays of char without any length value. > Two different kinds of strings with the same name - string - does make a > bit of confusion. Perhaps the > oldstyle strings could be renamed "short string" ?? ( didn't think > changing the spelling to "stwing" > would fly ) When we implement the short strings, we'll have to do such a distinction. Our current planning goes like this: string (n): string schema (EP compatible) string [n]: short string (UCSD/BP compatible, where n must be <= 255) string: dependent on flags, by default undiscriminated schema, but in BP mode (or with a special switch) short string of capacity 255 (UCSD/BP compatible). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Bug? Variants don't overlay when they contain strings
by Russ Whitaker 29 Dec '99

29 Dec '99

Hi David James wrote: > Subject: Bug? Variants don't overlay when they contain strings > Date: Tuesday, December 28, 1999 11:25 AM > > Should the different variants in a variant record overlay in the same > memory? > > Previous Pascals I have used have guaranteed this, and I've got > low-level code that relies on this. > > The simple example below shows that this is not true for GPC - the version > as reported by gpc -v is: > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 19991030, based on 2.95.2 19991024 (release) > > The output from the program is: > > addr of i is: -1073742896 > addr of s is: -1073742760 > addr of ic is: -1073742668 > > program daj15(input,output); > type trec = record > case integer of > 1:(i:array [1..34] of integer); > 2:(s:string(80)); > 3:(ic:packed array[0..79] of char); > end; > > var r:trec; > > procedure sub(r:trec); > begin > writeln('addr of i is: ',integer(addr(r.i)):1); > writeln('addr of s is: ',integer(addr(r.s)):1); > writeln('addr of ic is: ',integer(addr(r.ic)):1); > end; as an aside, if you change the cast "integer" to "cardinal" the output will be a positive number > > begin > sub(r); > end. > > If the string s is removed from the record, then the same address is > reported for i and ic. > You have more than an overlay problem. In standard pascal you expect ic[ 1 ] to align with the first character position of s and thus one character to the left is the length of s. Thus ic[0] is the length of s. In extended pascal there is 8 bytes to the left of the first charactor position makingt ic[ 0 ] useless So you end up leaving s out of Trec but what you can do is index s like an array[ 1..CAPACITY] and use Setlength when you need to. Two different kinds of strings with the same name - string - does make a bit of confusion. Perhaps the oldstyle strings could be renamed "short string" ?? ( didn't think changing the spelling to "stwing" would fly ) Russ <russwhit(a)mind.net>

1 0

Re: Bug? Variants don't overlay when they contain strings
by david＠tcs01.demon.co.uk 29 Dec '99

29 Dec '99

In message <199912292231.OAA17912(a)ego.mind.net> "Russ Whitaker" writes: > Hi > David James wrote: > > Subject: Bug? Variants don't overlay when they contain strings > > > > Should the different variants in a variant record overlay in the same > > memory? > > > > You have more than an overlay problem. In standard pascal you expect ic[ 1 > ] to align > with the first character position of s and thus one character to the left > is the length of s. > Thus ic[0] is the length of s. > > In extended pascal there is 8 bytes to the left of the first charactor > position makingt ic[ 0 ] useless > So you end up leaving s out of Trec but what you can do is index s like an > array[ 1..CAPACITY] > and use Setlength when you need to. In this artificially simple example, yes; however my real-life example is much more complicated, some of the variants are themselves records which contain strings, the aim was to get a byte array which was overlaid on all the variants (which is then sent over a network connection to another machine where an identical variant record receives bytes into the byte array and then uses the appropriate variant). I can work around the problem (by throwing away the variant record, keeping the individual variants and copying them to the byte array as needed). My question is still: should variants overlay in memory? I think I understand why they don't (I assume it's so that the string capacities do not get smashed by the other variants), but it's a nasty feature that could do to be highlighted in the documentation (maybe it is, but I haven't found it). -- David James mailto:david@tcs01.demon.co.uk

1 0

using Crt unit
by Matija Papec 28 Dec '99

28 Dec '99

Hello all! I would like to hear someone who does not have problems using Crt unit on Linux. On Mandrake6.1 (distribution very similar to RedHat), gpc says the following: ---- gpc -c -g --automake /home/mpapec/pas/dumy.pas -o ./dumy.o /tmp/cc8xNyqX.s: Assembler messages: /tmp/cc8xNyqX.s:6193: Error: Symbol `Initexec' can not be both weak and common /tmp/cc8xNyqX.s:6193: Error: Symbol `Doneexec' can not be both weak and common gpc1: gpc exited with status 1 crt.pas:345: `/usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/units/crtc.c' could not be compiled ---- and these are problematical lines: --file:crtc.c-- /* Assign the Dos unit's variables to the following routines to be called before and after Exec. If Dos is not used, create dummies here. */ void (*Initexec)() __attribute__((weak)); void (*Doneexec)() __attribute__((weak)); ---- What should be putted here? TIA :)

2 1

UNSUBSCRIBE
by Claude Roy 28 Dec '99

28 Dec '99

croy(a)osiris.com Claude Roy President Osiris inc. croy(a)osiris.com http://www.osiris.com

1 0

UNSUBSCRIBE
by Ed Way 28 Dec '99

28 Dec '99

1 0

Bug? Variants don't overlay when they contain strings
by david＠tcs01.demon.co.uk 28 Dec '99

28 Dec '99

Should the different variants in a variant record overlay in the same memory? Previous Pascals I have used have guaranteed this, and I've got low-level code that relies on this. The simple example below shows that this is not true for GPC - the version as reported by gpc -v is: Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 19991030, based on 2.95.2 19991024 (release) The output from the program is: addr of i is: -1073742896 addr of s is: -1073742760 addr of ic is: -1073742668 program daj15(input,output); type trec = record case integer of 1:(i:array [1..34] of integer); 2:(s:string(80)); 3:(ic:packed array[0..79] of char); end; var r:trec; procedure sub(r:trec); begin writeln('addr of i is: ',integer(addr(r.i)):1); writeln('addr of s is: ',integer(addr(r.s)):1); writeln('addr of ic is: ',integer(addr(r.ic)):1); end; begin sub(r); end. If the string s is removed from the record, then the same address is reported for i and ic. (I know the variants are not the same length, and they are intended not to be.) -- David James mailto:david@tcs01.demon.co.uk

1 0

compiling gpc units
by Dr A Olowofoyeku 24 Dec '99

24 Dec '99

Hi all I have been following the threads on compiling the GPC units for a while. A simple solution is an empty program that USEs all the units - build that program, and all the units are built automatically. Here is my version; {**********************************************************************} {**********************************************************************} {************** A program to build the main GPC units *****************} {*************** run 'gpc --autobuild -O2 build.pas' *****************} {**********************************************************************} {**********************************************************************} Program Build; USES crt, dos, dosunix, gmp, gpc, gpcutil, heapmon, overlay, pipe, ports, printer, regex, strings, system, trap, turbo3, windos; Begin End. Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro v5.21.1 for Win32 http://ourworld.compuserve.com/homepages/African_Chief/chief521.zip

1 0

Re: could not compile crt.pas
by Frank Heckenbach 23 Dec '99

23 Dec '99

Mason Ip wrote: > I wrote: > > BTW, this little script could build all the units (except > gpc-bp.pas for BP, not for GPC). > > > /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> cat > build_units > > #!/bin/sh > > for file in `ls *.pas` > > do > > gpc -c $file > > done > > Oooop... forgot to say : > Run this script twice; the first run build those units without > dependancy on the others; the second run build the remainder. Dirty and > quick :) I think you can just use `--automake' in this script to avoid the problem... BTW, ls is not really needed, just `for file in *.pas' will do. Well, in fact, you can even do `gpc --automake -c *.pas', I just tried it... :-) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

RE: could not compile crt.pas
by Mason Ip 23 Dec '99

23 Dec '99

I wrote: > BTW, this little script could build all the units (except gpc-bp.pas for BP, not for GPC). > /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> cat build_units > #!/bin/sh > for file in `ls *.pas` > do > gpc -c $file > done Oooop... forgot to say : Run this script twice; the first run build those units without dependancy on the others; the second run build the remainder. Dirty and quick :)

1 0

RE: could not compile crt.pas
by Mason Ip 23 Dec '99

23 Dec '99

Thanks a lot, Frank. BTW, this little script could build all the units (except gpc-bp.pas for BP, not for GPC). /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> cat build_units #!/bin/sh for file in `ls *.pas` do gpc -c $file done Thanks again. > ---------- > From: Frank Heckenbach[SMTP:frank@g-n-u.de] > Sent: Thursday, December 23, 1999 10:56 AM > To: gpc(a)gnu.de > Subject: Re: could not compile crt.pas > > Mason Ip wrote: > > > I had compiled gpc on Sparc Solaris 7 OK. But the crt.pas was not > compiled. > > As Mariusz said, units are not compiled when building GPC, but when > needed in a program. > > > After installation, gpc (and gcc, etc) were installed OK. But there was > no > > crt.gpm built from crt.pas. > > There is no crt.gpm because CRT is a (BP style) unit, not an (EP > style) module. Units create .gpi and .o files, modules .gpi, .gpm > and .o. > > > /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> gpc -O > > --automake crt.pas > > By default, GPC tries to link (i.e. create an executable) which it > can't do with a unit. To compile a unit, use the `-c' option. > > Or, you can directly compile a program, e.g. > `gpc -O --automake /usr/doc/gpc/examples/crtdemo.pas' which will > automatically compile CRT and link all requires files and libraries. > > I'm just writing a utility which will make all of this easier... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html >

1 0

Re: Help for gpc install
by Frank Heckenbach 23 Dec '99

23 Dec '99

"Khimenko Victor" wrote: > >> glibc (for example) is also stable product and many libraries compiled with it > >> are distributed and still you can get mess while mixing libraries compiled > >> against glibc 2.0.x/glibc 2.1.x (EVEN if developers of glibc tried VERY > >> hard to make glibc 2.1 backward compatible with glibc 2.0 on binary level!). > > > That's (beside the problems of incompatible glibc's on different > > distributions) why I personally don't consider glibc too stable > > yet... > > Hmm. libjpeg, libpng, libgif/libungif, Qt, GTK, etc, etc. Are we really have > ANY stable libraries at all ? To me it looks like wrong criterion :-) > Different visions of libraries usually are NOT compatible on binary level. > Be it in Linux, Windows or Solaris. As for static libs, they have the version number encoded into them (file names, and `-soname=...'), so the linker can prevent the wrong one from being linked. (At least that's true for Unix-like systems; I've heard under Windoze there are bigger problems, but I don't have personnal experience...) But if the compiler version also matters, it means we would have to use something like `/usr/lib/libjpeg.so.6.0.1.gcc-2.8.1'... And for static libs, this matters if another lib is compiled with one version of the lib (i.e., against its headers), and later used with another version of the lib. Yes, this can be a problem, but only affects a fraction of the libs out there (e.g. svgalib), while libgcc.a could potentially affect everything since it's used automatically by GCC, so the extent of problems would be much bigger. Anyway, I'm gonna ask the GCC people next year... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: could not compile crt.pas
by Frank Heckenbach 23 Dec '99

23 Dec '99

Mason Ip wrote: > I had compiled gpc on Sparc Solaris 7 OK. But the crt.pas was not compiled. As Mariusz said, units are not compiled when building GPC, but when needed in a program. > After installation, gpc (and gcc, etc) were installed OK. But there was no > crt.gpm built from crt.pas. There is no crt.gpm because CRT is a (BP style) unit, not an (EP style) module. Units create .gpi and .o files, modules .gpi, .gpm and .o. > /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> gpc -O > --automake crt.pas By default, GPC tries to link (i.e. create an executable) which it can't do with a unit. To compile a unit, use the `-c' option. Or, you can directly compile a program, e.g. `gpc -O --automake /usr/doc/gpc/examples/crtdemo.pas' which will automatically compile CRT and link all requires files and libraries. I'm just writing a utility which will make all of this easier... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

could not compile crt.pas
by Mason Ip 23 Dec '99

23 Dec '99

I had compiled gpc on Sparc Solaris 7 OK. But the crt.pas was not compiled. The sources of gcc and gpc were as follow. ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19991030.tar.gz ftp://ftp.cs.ubc.ca/pub/archive/mirror/gnu/gcc/gcc-2.95.2.tar.gz After installation, gpc (and gcc, etc) were installed OK. But there was no crt.gpm built from crt.pas. The following were what I got when trying to compile crt.pas manually. /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> which gpc /opt/GCC2952/bin/gpc /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> gpc -v Reading specs from /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gpc version 19991030, based on 2.95.2 19991024 (release) /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> gpc -O --automake crt.pas Undefined first referenced symbol in file crt_clrscr /var/tmp/cclOaycI1.o crt_clearterminal /var/tmp/cclOaycI1.o crt_restore_terminal_crt /var/tmp/cclOaycI1.o crt_read /var/tmp/cclOaycI1.o crt_HasColors /var/tmp/cclOaycI1.o crt_restore_terminal_no_crt /var/tmp/cclOaycI1.o crt_get_input_fd /var/tmp/cclOaycI1.o crt_readchar /var/tmp/cclOaycI1.o crt_NormAttr /var/tmp/cclOaycI1.o crt_setcontrolchars /var/tmp/cclOaycI1.o crt_ungetch /var/tmp/cclOaycI1.o [snip] crt_winsize /var/tmp/cclOaycI1.o crt_readwin /var/tmp/cclOaycI1.o main /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/crt1.o crt_getcursorshape /var/tmp/cclOaycI1.o crt_setscroll /var/tmp/cclOaycI1.o crt_ColorFlag /var/tmp/cclOaycI1.o crt_check_winchanged /var/tmp/cclOaycI1.o crt_gotoxy /var/tmp/cclOaycI1.o crt_done /var/tmp/cclOaycI1.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> ls ./ crtunix.h gpc.gpm pipec.c ../ crtunix1.h gpc.o ports.pas crt.gpi crtx.c gpc.pas printer.pas crt.inc crtxcurses.h gpc_bp.gpi regex.pas crt.pas dos.gpi gpc_delphi.gpi regexc.c crtc.c dos.pas gpc_ep.gpi strings.pas crtc.h dosunix.pas gpc_sp.gpi system.pas crtc.o gmp.gpi gpcutil.pas trap.pas crtdospc.h gmp.pas heapmon.pas trapc.c crtdummy.h gpc-bp.pas overlay.pas turbo3.pas crtlinux386.h gpc.gpi pipe.pas windos.pas /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/units> I have libncurses installed on my system (from sunfreeware). What did I miss for compiling crt.pas ? Thanks for any pointer; please excuse me if this problem had been answered (and I had missed the answer).

2 1

Vacation
by Frank Heckenbach 23 Dec '99

23 Dec '99

Hi, the GPC team is taking vacations. Peter has already gone on holidays, and I'll also be off for some days. Furthermore, we do not know for sure if our mail server, or any server on the way, or any server's power supply, or whatever else will by affected by any Y2K bugs. So, if you send a request to the list in the next few weeks and don't get any reply, please send it again some weeks later... Merry Christmas and a Happy New Year (without too many bugs :-), Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Help for gpc install
by Frank Heckenbach 23 Dec '99

23 Dec '99

"Khimenko Victor" wrote: > > Since GPC uses the same backend as GCC, this is equivalent > > to the question whether you can link C files compiled with gcc-2.8.1 > > and gcc-2.95, which is the situation if you install gcc-2.95 on your > > system while your libraries have been compiled with gcc-2.8.1. Since > > I didn't read in the GCC docs that I should recompile all my libs > > after installing a new GCC version, I still can't believe that > > there's a problem (as far as C and Pascal are concerned)... > > There WAS such problems with oldier versions of GCC (2.5 => 2.7 or something). > Now gcc backend looks stable enough to avoid it but who knows ? Ask in gcc > mailing list if want to be 100% sure (not about gpc but about different > versions of gcc and "C" backend of course :-) Of course. :-) Will do so... > glibc (for example) is also stable product and many libraries compiled with it > are distributed and still you can get mess while mixing libraries compiled > against glibc 2.0.x/glibc 2.1.x (EVEN if developers of glibc tried VERY > hard to make glibc 2.1 backward compatible with glibc 2.0 on binary level!). That's (beside the problems of incompatible glibc's on different distributions) why I personally don't consider glibc too stable yet... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Problem with some strings procedures.
by Frank Heckenbach 22 Dec '99

22 Dec '99

Alfredo Cesar Fontana wrote: > Hello: > > In this example: > > PROGRAM STR; > {$IFDEF BAD} > TYPE P=PROCEDURE(S:STRING); > {$ENDIF} > VAR S:STRING; > BEGIN > S:='123'; > DELETE(S,1,1); > WRITELN(S) > END. > > with GPC v 19990118 (DJGPP and Linux) and GPC v 19990609 > > when I "gpc -o str str.pas" > I get: "23", the delete procedure works fine. But > if I "gpc -o str str.pas -DBAD" > then I get: "123". I lost my delete procedure :'-( Thanks for the report, I'm adding it to the To-Do list and testsuite (fontana1.pas). I've traced the problem to parse.y:2196, but I can't fix it because there are strange things going on in that area which I don't understand. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Help for gpc install
by Frank Heckenbach 22 Dec '99

22 Dec '99

"Khimenko Victor" wrote: > I'm not know if it's right thing to do. Internal gcc libraries are installed > in <prefix>/lib/gcc-lib/<platform>/<version>/ on purpose and not just since > "so happens" (libstdc++ is installed there as well while shared version > of library is installed in <prefix>/lib :-) On my gcc-2.95.2 installation, both libstdc++.{a,so} are symlinks to the ones in /usr/lib. > libgcc.a depends on libc, BTW. "C" part of libgcc.a is more or less stable > now (AFAIK anyway). So usually it works. But "C++" part (at least C++ part!) > of libgcc.a is in constant flux. And yes, if you have C++ library compiled > with gcc 2.8.1 you can not use it with gcc 2.95.2 (even if this library does > not use libstdc++ library and it's very rare C++ library then :-) Only two > days ago I helped guy to compile some program based on C++ library compiled > in RedHat 5.2 under RedHat 6.1. He ended with installation of egcs 1.0.3 from > RedHat 5.2 ... GPC does not use the C++ part of libgcc.a, so we can exclude this for now. The question is, is it possible (without subtle bugs) to link files compiled with, say GPC based on gcc-2.8.1 and files compiled with gcc-2.95 (in which case the libgcc.a used would be wrong for either of them)? Since GPC uses the same backend as GCC, this is equivalent to the question whether you can link C files compiled with gcc-2.8.1 and gcc-2.95, which is the situation if you install gcc-2.95 on your system while your libraries have been compiled with gcc-2.8.1. Since I didn't read in the GCC docs that I should recompile all my libs after installing a new GCC version, I still can't believe that there's a problem (as far as C and Pascal are concerned)... > P.S. Do you think much about possible usage of libgpc.a with different > version of gpc while developing gpc/libgpc ? No. > Why do you think gcc development > is different ? Because GCC is a stable product and many libraries compiled with it are distributed, while GPC is alpha/beta... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Unit ports.pas, InPortW
by Opie Pecheux 22 Dec '99

22 Dec '99

Hi, I think that there is a mistake un the ports.pas unit on the gpc-19990430-i386-pc-djgppv202.zip : function InPortW (PortNumber : ShortWord) : ShortWord; var Result : volatile ShortWord; (*@@*) begin asm ('inb %%dx, %%al' : '=a' (Result) : 'd' (PortNumber) : 'ax', 'dx'); InPortW := Result end; Wasn't ax instead of al? Note: I don't need to use it! -- Opie --------Publicite--personnelle--------------------------------------- ........ ABC de la Programmation (Assembleur, C, Pascal) ................ http://www.multimania.com/opecheux ................ Pour Ãªtre averti des nouvelles Ã©tapes, abonnez vous Abonnez vous aux listes franÃ§aises: - Assembleur: http://www.onelist.com/subscribe/prog_nasm - C : http://www.onelist.com/subscribe/prog_c_gnu - Pascal : http://www.onelist.com/subscribe/prog_pascal_gnu --

2 1

Re: Problem with the CRT uniy
by Frank Heckenbach 22 Dec '99

22 Dec '99

Peter Gerwinski wrote: > > > And `/usr/lib/gcc-lib/i386-redhat-linux/2.8.1/units/crt.pas' is > > > in place? > > > > Nothing, I don't have this, I don't understand.... => I installed gpc with the > > src.rpm (base and extra) > > Then your `src.rpm' is incomplete. If this is the archive > from `agnes.dida.physik.uni-essen.de' it should be complete. > (I tend to remember to have checked that before uploading; > however I cannot re-check right now because I am on holidays > and have only a slow and very expensive connection to the > Internet.) I just checked it. I assume you mean gpc-19990118-1.src.rpm. It contains gpc-19990118.tar.gz which is a complete GPC source archive, including CRT and the other units. Did you install GPC after building with `make install' or similar? If you just copied the compiler executables or something, you'll be missing the units, of course. In case the installation is done by the packaging utilities automatically (I didn't check this), maybe these scripts have to be adjusted... But you can simply copy the units from the source archive to the directory named above, they're not modified in any way while building GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

Re: Problem with the CRT uniy
by Frank Heckenbach 22 Dec '99

22 Dec '99

Romain Chantereau wrote: > Ok, I installed gpc with the tar.gz gived with the src.rpm, and it works !!! > > But, I would know how compile without the --automake option, because xwpe-alpha or > rhide don't permit to modify the basic command line... (and I don't want to make > remplacement script, but if I dont' find something, i will do that..) > > Thks for all, it was very cool to help me like that !!! RHIDE (not sure about xwpe) lets you modify the command line -- in fact, it does use `--automake' by default, but (unless that has been corrected in a newer release) also some obsolete automake parameters which cause a warning by GPC. Some earlier messages this year on this list described how to modify the command line. You also might want to try my IDE PENG (http://fjf.gnu.de/peng.html) which was written in GPC and, of course, uses an appropriate command line for GPC. (What a shameless plug! ;-) Apart from that, to answer your question, you can compile a single unit or program with the `-c' switch, and link all the object files, e.g. with a program `foo' that uses a unit `bar': gpc -c bar.pas gpc -c foo.pas gpc -o foo foo.o bar.o This way, you have to compile the units used by a program/unit before the program/unit itself, and you have to make sure to recompile anything when necessary. Also, you have to take care of C files and libs referenced from some units, e.g. CRT, with `{$L}' directives. IOW, you better write a Makefile, as usual in C... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Help for gpc install
by Frank Heckenbach 22 Dec '99

22 Dec '99

Tom Schneider wrote: > > Here is your problem: GPC can not be used with different version of GCC. > > If it's compiled from sources against of GCC 2.8.1 you need GCC 2.8.1 to run > > the beast, if it's compiled against of EGCS 1.1.2 you need EGCS 1.1.2 and so > > on. Even minor changes (EGCS 1.1.1 => EGCS 1.1.2) will break harmony :-) > > That's lovely. So why not read from the current gcc > what version it is and if they differ put up a BIG MESSAGE > and abort? The current problem is a bit different: GPC searches for the GCC files (including libgcc.a and cc1, the actual C compiler which is used for compiling C files referenced from Pascal code) in the same directory it's installed in (i.e. <prefix>/lib/gcc-lib/<platform>/<version>/). If there is a matching GCC version, it will be installed in the same directory, GPC will find the files, and everything is fine. If there's no matching GCC installed, GPC will simply not see it, and will therefore not give any particular message about this situation, just the usual linker error that a library is not found. Well, I'm currently writing a utility to simplify the usage of GPC, avoid the automake problems, and I've also intended it to simplify the calling of GCC so it will by default call `gcc' rather than cc1 (with special handling for cross-compiles and similar things) which will work with any installed GCC (as long as it can be found in the PATH). Now I'm reading this stuff about libgcc.a incompatibilites, and I'm wondering if that's the right thing to do, or if it will just replace an obvious problem by more difficult to find subtle problems (which would be a bad thing)... Khimenko Victor wrote: > 20-Dec-99 18:11 you wrote: > > Hello again. > > > Khimenko Victor wrote: > >> > >> > to a global one (such as /usr/local/lib/). After my humble > >> > experience, this doesn't harm. (But don't blame me if it does > >> > for you.;-) > >> > >> It will work for simple programs like "Hello, World!" (where libgcc is not > >> needed anyway) just fine. But for more complex programs it'll create problems. > >> libgcc.a is INTERNAL gcc library - [...] > > > So you mean that different versions of `libgcc.a' are not > > compatible enough even between egcs-1.1.1 and egcs-1.1.2 to > > make this work in a stable way? > > It CAN be compatible but it's NOT tested (and since it's not used this way > and not used much overral probability is VERY high to get silent damage and > not notice it for very long time). > > > Well, then the creator of the GPC binary distribution _must_ > > supply a matching `libgcc.a'. > > He just must add > -- cut -- > Require: gcc = 2.8.1 > -- cut -- > line in .spec file. Then rpm will just refuse to install gpc without > corresponding gcc. If the incompatibility really exists, than that's indeed what has to be done, i.e. each GPC binary should require or include GCC. Just supplying libgcc.a with GPC without the corresponding GCC would be problematic because: - Parts of the Run Time System and some units are written in C, and would "require" another libgcc.a if compiled with another C compiler. - Perhaps it's a problem for the packages if both GCC and GPC contain libgcc.a. I don't know the different packaging systems to well, so I don't know if they're designed to handle this situation. But I'm still wondering about this incompatibility. I recently did a joint Pascal/C++ project using gpc-19990813, based on gcc-2.8.1, and g++-2.95, linking to g++-2.95's libgcc.a, and it works well under both Solaris/Sparc and Linux/x86, even though the Pascal code does some 64 bit arithmetic... That's, of course, no proof that there are no problems. But what about libraries, e.g.? If they're dependent on the libgcc.a used for compiling them, this would mean that each program using a library has to be compiled with the same compiler version (i.e., the same libgcc.a version) as the library itself, to prevent subtle bugs. IOW, after upgrading a compiler, one would have to recompile libc and everything that depends on it, i.e. basically the whole system. I've never heard of this, and I really hope this isn't true... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Unit ports.pas, InPortW
by Frank Heckenbach 21 Dec '99

21 Dec '99

Opie Pecheux wrote: > Hi, > > I think that there is a mistake un the ports.pas unit on the > gpc-19990430-i386-pc-djgppv202.zip : > > > function InPortW (PortNumber : ShortWord) : ShortWord; > var Result : volatile ShortWord; (*@@*) > begin > asm ('inb %%dx, %%al' : '=a' (Result) : 'd' (PortNumber) : 'ax', > 'dx'); > InPortW := Result > end; > > Wasn't ax instead of al? That's right, also `inw' instead of `inb'. Thanks for the report, Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Problem with some strings procedures.
by Alfredo Cesar Fontana 20 Dec '99

20 Dec '99

Hello: In this example: PROGRAM STR; {$IFDEF BAD} TYPE P=PROCEDURE(S:STRING); {$ENDIF} VAR S:STRING; BEGIN S:='123'; DELETE(S,1,1); WRITELN(S) END. with GPC v 19990118 (DJGPP and Linux) and GPC v 19990609 when I "gpc -o str str.pas" I get: "23", the delete procedure works fine. But if I "gpc -o str str.pas -DBAD" then I get: "123". I lost my delete procedure :'-( I'm trying to migrate to GPC from TP. I want that the source compiles in TP, GPC in DOS and GPC in Linux. But I have some problems. How can I use the BP Strings Schema for not converting databases? I'm not realy sure. But I think that when I try compile a line who needs a function which returns a string but this function is undeclared; the compiler breaks. I'll work on it for getting the realy trouble, and then ask you for help. Thanks... Alfredo

1 0

x-compile, graphics, array vs pointers
by Klaus Friis Østergaard 20 Dec '99

20 Dec '99

Hi , I have just installed GPC-19990118 on a redhat 6.0 linux. I have some questions: a.. Is it possible to make the program development on the linux, and =when I am finished to cross-compile it to windows 98/windowsNT? b.. How do I work with graphics in GNU pascal, so that I am able to =use the same source to compile to both linux/windows execute files. c.. Where do I find information on the graphics tools to use in GPC. d.. I am working with the traveling salesmans problem. There I need to =make a 2-dimensional array which contain the distance between each =city/node. As I'am new to GNU pascal and pointers, I wounder if it is =possible to make some kind of pointer structure that is working faster, =use memory dynamically or smarter than using a 2-dimensionally array? kind regards, klaus ---------------------------- Klaus F. Østergaard Laser Technical Services A/S Private: Sneppevang 3 Farremosen 3 DK-3450 Allerød DK-3450 Allerød tel: +45 48 17 61 61 +45 48 17 30 44 fax: + 45 48 17 10 65 Email : kfo(a)lasertech.dk company : laser(a)lasertech.dk

5 5

Problem with the CRT uniy
by Romain Chantereau 20 Dec '99

20 Dec '99

Hi, I wanted to compile a program with the GPC, and when I invoke gpc supp.pas it make "supp.pas:5: module/unit interface `Crt' could not be imported" !! I have installed GPC with the src.rpm. I have installed FPC too, and I tried to compile with the crt.o or/and the crt.ppu or/and the crt.pas gived with the source. Where can I find this Unit under Linux ?? Or how to do this work ! ?

2 6

Help for gpc install
by Marc SERRAU 20 Dec '99

20 Dec '99

Hello, My name is Marc SERRAU and I discovered the GNU Pascal Compiler few days ago. I installed it on my linux based PC from the binary package. (rpm) The installation worked well but I always become the following message after compiler even with a trivial Hello.pas program : [marc@altair hisix]$ gpc hello.pas ld: cannot open -lgcc: Aucun fichier ou rÃ©pertoire de ce type The linker cannot find some stuff, but what ? The gcc compiler was installed from an RH 6.0 distrib. Who can help me ? Thank you for your effort. Marc SERRAU Visit http://www.astrosurf.org/noctambule Marc SERRAU Visitez http://www.astrosurf.org/noctambule In Linux we trust, more and more...

4 7

_dos_ds
by Opie Pecheux 20 Dec '99

20 Dec '99

Hi, I use gpc 19990430 for dos with rhide. I want to access to the video memory. In C I use _farsetsel without problems, but in Pascal I have a problem with the selector _dos_ds. For _farsetsel, I write: Procedure FarSetSel(Selecteur:integer); AsmName '_farsetsel'; But I don't know how to use _dos_ds, of course FarSetSel(_dos_ds); don't work. Thanks for help. -- A+ Opie --------Publicite--personnelle--------------------------------------- ........ ABC de la Programmation (Assembleur, C, Pascal) ................ http://www.multimania.com/opecheux ................ Pour Ãªtre averti des nouvelles Ã©tapes, abonnez vous --

2 1

Re: Strings problem
by Frank Heckenbach 20 Dec '99

20 Dec '99

"Dr A Olowofoyeku" wrote: > On 19 Dec 99, at 21:06, Maurice Lombardi wrote: > > > LUJOP a Ã©crit : > > > The output generated is: > > > Bye<Hello > > > Bye>Hello > > > > Strange ! I find the correct result > > > > Hello>Bye > > Bye<Hello > > > > But I use the last alpha version of gpc. > > Is this a corrected bug ? > > IIRC, the answer is "Yes". Indeed. The bug was fixed Jan 26 which was after the release of the last beta version, but before the release of the subsequent alphas. (And, IIRC, the bug was "created" shortly before, so it only affects that one beta version.) A real solution to this problem would require an update of the compiler, or at least the runtime library (libgpc.a). As a work-around, you could possibly use the compiler directive `{$no-exact-compare-strings}' at the beginning of your code or pass the option `--no-exact-compare-strings' on the command line. This will cause spaces at the end of strings to be ignored in the comparison (like ISO 10206 demands). The operators that compare that way were not affected by the bug, but of course, the bevahiour is a little different, so this might not be an option to you... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Strings problem
by LUJOP 20 Dec '99

20 Dec '99

First of all excusme for my little english. I'm new and I haven't experience with GPC, in fact I don't like Pascal very much. But I need to do a work for the university. The version I run is: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 And I have some problems comparing strings. If I compile and run the next program: Program test; var a,b:string(20); begin a:='Hello'; b:='Bye'; if(a<b) then writeln('Hello<Bye'); if(a>b) then writeln('Hello>Bye'); if(b<a) then writeln('Bye<Hello'); if(b>a) then writeln('Bye>Hello'); end. The output generated is: Bye<Hello Bye>Hello And, logically it isn't very nice :-) My question is simple: why the program don't function as desired? Or, if the error is mine, What I do bad? Postdate: I need to compile the program in the metionated version, and I can't update to a newer (university's administrators are not very servicial) Thus, if we can give a solution for the above version I'll be very happy. Otherwise I will be to codify strings with arrays of chars. Please , if someone reply to this message can send a copy to jpujo012(a)correu.udg.es Thanks And, another time excusme for me english.

3 2

Strings problem
by LUJOP 20 Dec '99

20 Dec '99

First of all excusme for my little english. I'm new and I haven't experience with GPC, in fact I don't like Pascal very much. But I need to do a work for the university. The version I run is: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 And I have some problems comparing strings. If I compile and run the next program: Program test; var a,b:string(20); begin a:='Hello'; b:='Bye'; if(a<b) then writeln('Hello<Bye'); if(a>b) then writeln('Hello>Bye'); if(b<a) then writeln('Bye<Hello'); if(b>a) then writeln('Bye>Hello'); end. The output generated is: Bye<Hello Bye>Hello And, logically it isn't very nice :-) My question is simple: why the program don't function as desired? Or, if the error is mine, What I do bad? Postdate: I need to compile the program in the metionated version, and I can't update to a newer (university's administrators are not very servicial) Thus, if we can give a solution for the above version I'll be very happy. Otherwise I will be to codify strings with arrays of chars. Please , if someone reply to this message can send a copy to jpujo012(a)correu.udg.es Thanks And, another time excusme for me english.

1 0

Re: Modules/units, separate compilation, minimal re-compilations
by Frank Heckenbach 15 Dec '99

15 Dec '99

David James wrote: I have several applications which I'm porting to GPC on Linux from another (almost) ISO-10206 extended Pascal. > The application is structured in several layers, in this sort of > scheme: > > modules A, B, C export constants, types, variables, procedures and > functions which are used by modules D, E, F which in turn export > constants, types, variables, procedures and functions which are > imported by modules G, H, I which in turn ... are imported by > programs X, Y, Z. > > The previous compiler allowed (as GPC does) the interface and > implementation parts of each module to be in separate files (usually > .h for the interface and .p for the implementation). > > When deciding what needed re-building when re-compiling program X, > it only checked for updates since the last re-build to the *interface* > parts of the modules imported by X (and, recursively, the modules it > imported). > > This lead to a major reduction in the amount of compilation needed > when re-building one of the applications, for example, if a change > was made to the implementation part of module A, rebuilding program X > would result in module A being re-compiled and then program X being > re-linked. > > So, finally my question: is it possible to do this with GPC? Not currently, but one of the next releases will probably contain a feature to do this. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

GPC and Red Hat 6.0
by Ken_A_Munro＠keane.com 15 Dec '99

15 Dec '99

Hi. Sorry if I missed something in the documentation, but I think I've read it all over. I have installed the binaries for GPC on my Red Hat 6.0 system. I can get Pascal programs to compile, but when they execute, they core dump. (I have attached the output from a verbose gpc compile of the pi.pas demo program.) The Red Hat 6.0 compiler is egcs-1.1.2, but the GPC binary (from gpc-19990118-egcs-1_1_1_i386-linux-glibc2.tar) was compiled with egcs-1.1.1. Is that why the executables are core dumping? I have also tried compiling GPC, but when I "make LANGUAGES=pascal", I get a lot of "assignment makes pointer from integer without a cast" errors when gcc is compiling gpc.c. Why should that be happening, and how can I remedy it? Also, is this mailing list archived anywhere? Thanks in advance. Any help would be greatly appreciated. Ken Munro **************************** versions of gcc and gpc *************************************************** [root@client11 demos]# egcs -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) [root@client11 demos]# gpc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) ******************* verbose ouput of pascal compile of sample pi.pas program ****************** [root@client11 demos]# gpc --automake pi.pas -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ pi.pas /tmp/cceao36i.i GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc1 /tmp/cceao36i.i -quiet -dumpbase pi.pas -version -famtmpfile=/tmp/cc2OLhLJ.gpc -fautomake -o /tmp/cceao36i.s GNU Pascal version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386-redhat-linux) compiled by GNU C version egcs-2.91.60 19981201 (egcs-1.1.1 release). GPC AutoMake: gpc --automake -v --amtmpfile=/tmp/cc2OLhLJ.gpc -M /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gpc.pas -o /tmp/cc0clDMX Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gpc.pas -o /tmp/cc0clDMX GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -v --amtmpfile=/tmp/cc2OLhLJ.gpc -M /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gmp.pas -o /tmp/cceFAqbP Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nochar escape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gmp.pas -o /tmp/cceFAqbP GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. GPC AutoMake: done as -V -Qy -o /tmp/cceao36i1.o /tmp/cceao36i.s GNU assembler version 2.9.1 (i386-redhat-linux), using BFD version 2.9.1.0.23 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60 -L/usr/i386-redhat-linux/lib gmp.o gpc.o /tmp/cceao36i1.o -lgpc -lm -lgmp -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/crtend.o /usr/lib/crtn.o [root@client11 demos]#

1 0

Re: Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 12 Dec '99

12 Dec '99

In message <199912112317.SAA26060(a)mail.bcpl.net> "J. David Bryan" writes: > On 11 Dec 99, at 13:31, David James wrote: > > > I'm still not sure what my example should do. Looking at the copy of > > Extended Pascal ISO/TEC 10206:1990(E) that I found on (I think) a > > DEC site somewhere, I *think* it is saying (in section 6.7.5.2) that > > after the call to 'extend' the file should be in 'Generation' mode. > > Right. There is no precondition for "extend" that the file be closed. In > fact, there is no "close" predefined function in EP. That explains why I cannot find 'close' in the standard :-). So how should one 'close' a file in EP - would that be 'unbind'? [snip] > > I make no claim to expertise with the EP standard, and the prose in the > standard is nearly impenetrable :-), I think you have an extraneous word there - it's the "nearly" :-) > but as far as I can see, "extend" > following a "reset" is perfectly OK. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Re: Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

In message <19991211124359.A4186(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > David James wrote: > > [...] > > The previous compiler allowed one to write to a text file that had been > > opened with 'reset' and then 'extend'ed. GPC says: > > > > ./daj13: cannot write to read only file `daj13.pas' (error #422) > > > > ===== > > program daj13(input,output); > > > > var f:text; > > > > begin > > reset(f,'daj13.pas'); > > extend(f); > > writeln(f,'extra text'); > > end. > > If you `close' the file before the `extend', it works. I'm still not sure what my example should do. Looking at the copy of Extended Pascal ISO/TEC 10206:1990(E) that I found on (I think) a DEC site somewhere, I *think* it is saying (in section 6.7.5.2) that after the call to 'extend' the file should be in 'Generation' mode. I think the run-time error on the 'writeln' is incorrect. However, it is possible that there should be an error on the call to 'extend' (it's not clear to me whether calling 'extend' on a file that has already been 'reset' is allowed). > > Do you happen to know what Extended Pascal thinks about how > `close' should work? No, I'm afraid I don't. I cannot find any reference to 'close' in the index of ISO 10206, and I cannot see anything referring to 'close' in section 6.7.5.2 'File Handling procedures'. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 2

Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

I'm not sure what the correct behaviour should be in the attached program, but GPC's behaviour is different from the previous extended Pascal compiler I used (I'm not saying that the previous compiler was right). The previous compiler allowed one to write to a text file that had been opened with 'reset' and then 'extend'ed. GPC says: ./daj13: cannot write to read only file `daj13.pas' (error #422) ===== program daj13(input,output); var f:text; begin reset(f,'daj13.pas'); extend(f); writeln(f,'extra text'); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 3

Problem with rewrite on file of packed array of packed record
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

The attached program declares a direct access file whose elements are PACKED ARRAYS of a PACKED RECORD. The program fails with error #405 when a rewrite is issued for the file. Removing the PACKED from the array declaration makes the error go away. Is this correct behaviour? program daj7(input,output); const maxcontrol = 170; maxcomp = 200; type TCHECK1=PACKED RECORD CHECH:0..47; (*6 bits*) CHECM:0..60; (*6 bits*) CHECS:0..60; (*6 bits*) CHECT:0..999; (*10 bits*) GENERATED:BOOLEAN; QUERY:BOOLEAN; from_audit:boolean; END; TCHECK=PACKED ARRAY [0..MAXCONTROL] OF TCHECK1; (*if declared as PACKED, get error 405 on the rewrite if not declared PACKED, runs OK*) var count:integer; f:file [0..maxcomp] of tcheck; begin rewrite(f,'daj7.fil'); (*./daj7: could not open `daj7.fil' (error #405) here *) for count:=0 to maxcomp do begin seekwrite(f,count); f^[0].chect:=count; put(f); end; close(f); reset(f,'daj7.fil'); for count:=1 to maxcomp do begin seekread(f,count); writeln(count:1,' ',f^[0].chect:1); end; close(f); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Modules/units, separate compilation, minimal re-compilations
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

I have several applications which I'm porting to GPC on Linux from another (almost) ISO-10206 extended Pascal. The application is structured in several layers, in this sort of scheme: modules A, B, C export constants, types, variables, procedures and functions which are used by modules D, E, F which in turn export constants, types, variables, procedures and functions which are imported by modules G, H, I which in turn ... are imported by programs X, Y, Z. The previous compiler allowed (as GPC does) the interface and implementation parts of each module to be in separate files (usually .h for the interface and .p for the implementation). When deciding what needed re-building when re-compiling program X, it only checked for updates since the last re-build to the *interface* parts of the modules imported by X (and, recursively, the modules it imported). This lead to a major reduction in the amount of compilation needed when re-building one of the applications, for example, if a change was made to the implementation part of module A, rebuilding program X would result in module A being re-compiled and then program X being re-linked. So, finally my question: is it possible to do this with GPC? If it is, how do I need to structure my source code to make it happen. If it isn't possible, can I offer this as a development suggestion. A final note, I'm in the process of converting all my source code from modules to units, since the problem I've already reported in program daj3 makes the use of modules impossible in my applications. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Precompiled units
by Mariusz Zynel 07 Dec '99

07 Dec '99

Hi All How to tell gpc where the precompiled units are? I would like to keep standard/shared object files (precompiled units) in one directory and make them available for all the projects I'm working on. I'm using the latest beta 1030 on Solaris 7. Thanks for suggestions -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

2 2

Help with GPC installation on Mingw32 on NT...
by Rod Chapman 06 Dec '99

06 Dec '99

Perhaps someone could help me with installing GPC 19990118 for mingw32 on NT. I've unzipped the binaries into d:\rod\gpc\ on my machine and I have GCC_EXEC_PREFIX set to d:\rod\gpc\lib\gcc-lib\ Compiling my application works OK, but linking fails with... D:\rod\lalr>gpc -o sparklalr sparklalr.o ld: cannot open crt1.o: No such file or directory D:\rod\lalr>gpc -o sparklalr -v sparklalr.o Reading specs from d:\rod\gpc\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 ld -o sparklalr.exe crt1.o -Ld:\rod\gpc\lib\gcc-lib\i386-mingw32\2.8.1 -Ld:\rod\gpc\lib\gcc-lib -LD:\GNATPRO\lib sparklalr.o -lgpc -lcrtdll -lmingw32 -lgcc -lmoldname -lcrtdll -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lcrtdll ld: cannot open crt1.o: No such file or directory I can't find crt1.o anywhere on my system - where does it come from? Thanks, Rod Chapman Praxis Critical Systems ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This email has been swept for the presence of known computer viruses. **********************************************************************

2 1

dos and intr
by Opie Pecheux 02 Dec '99

02 Dec '99

Hi, I use the Pascal gnu on a PC-i386 machine (with rhide), with gpc-19990430-i386-pc-djgppv202 (i have the same problem with the version 19990813 or 19991030). I want to use the function intr, but in the dos unit, there is only a comment about it and i didn't find the definition. For now, i use my own intr with a asmname ?__dpmi_int', but i want to know if there is a unit how do this. Second question: how can i access directly to the screen (address a0000)? Thanks. Opie

2 1

Re: Problem with strings in record imported/exported from/to modules
by Frank Heckenbach 26 Nov '99

26 Nov '99

David James wrote: > Thank you, that seems to do everything I need at present. I can see I > need to read gpc.pas more carefully to see what other nice features > are in there. :-) And we should document them better... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: CRT Unit
by Frank Heckenbach 26 Nov '99

26 Nov '99

Opie Pecheux wrote: > Now, the curse23.zip file have disappeared, and i recommend > pdcurs24.beta.zip . At first i install pdcurs24 on my pc, and it was > working. But i didn't delete all my files before. > If i try to install from the beginning, i have the message "curspriv.h: > no such file or directory (ENOENT)." with rhide or in line. Oh yeah... I used curspriv.h in some GPC versions, but not in the current one, so I didn't notice the problem when I uploaded pdcurs24. So, in order to use pdcurs24 you have two choices: - Get the most recent GPC alpha (though I'm not sure if there are DJGPP binaries available), or - get curspriv.h from the PDCurses sources (ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/pdcurs24.beta.22-May-99.zip) > What we have to do? I send all the file at the end. Note: i don't know > how to use -v in gpc, all the messages go on the screen. How can i get > them in a file? DJGPP contains the redir utility for that purpose, e.g.: redir -eo gpc -v ... > logfile (But the screen dump below is also fine, apart from the line breaks...) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: test results
by Frank Heckenbach 26 Nov '99

26 Nov '99

"Dr A Olowofoyeku" wrote: > > > dialec3.pas failed > > IIRC this is okay under Cygwin but fails under Mingw, with > complaints about undefined references to 'pipe' and 'fork' (or > something like that - Frank will remember because I reported the > problem to him (it was an RTS problem)). dialec[356] basically test all units (only for compileability). The pipe/fork problem occurred under mingw, in this case the problems reported were: : /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function : `_p_pipe': : /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): : multiple definition of `_p_pipe' : pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first : defined here : /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in : /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o Which means that GPC does not always recognize differently written identical file names... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 26 Nov '99

26 Nov '99

In message <0CE9572A.19991123110923.FOO-4A5F.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > [snip] > > However what I really want to do is to put this record into shared > > memory, so I moved to daj4u and dajunit4, attached. This fails. > > [snip] > > My question is really what is the recommended way to do this: is it > > to set the string's capacity, or should I be calling some other > > function to initialise the record proerly after I shmat the shared > > memory? I assume that new(record_pointer) is initialising string > > capacities within the record, somehow. > > Oh, I see. That's a completely new thing, something which hasn't > been tried with GPC yet. So, let's see, what would be a good > solution here... > [snip > - You could use some lower-level hooks into GPC's memory manager. > These hooks already exist in the gpc unit (originally introduced > to implement some BP compatible stuff in the system unit). They > allow you to redirect any raw memory de-/allocations to > user-defined routines, while GPC will still do all the > initializations of strings, schemata, files, objects, etc. Thank you, that seems to do everything I need at present. I can see I need to read gpc.pas more carefully to see what other nice features are in there. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

test results
by Russ Whitaker 25 Nov '99

25 Nov '99

Hi Frank Ran make in directory test today: These failed: constovfl.pas failed: failed 0 dialec3.pas failed fjf149.pas failed: 64 fjf83.pas failed: Failed goto4.pas failed These Err messeges appeared just before dialec3.pas: /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function `_p_pipe': /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): multiple definition of `_p_pipe' pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first defined here /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o collect2: ld returned 1 exit status /tmp/cc0y2DBt.s: Assembler messages: /tmp/cc0y2DBt.s:110: Error: operands given don't match any known 386 instruction Are the results what you expected? Thanks, Russ

2 1

Re: test results
by Frank Heckenbach 25 Nov '99

25 Nov '99

"Russ Whitaker" wrote: > Hi Frank > > Ran make in directory test today: > > These failed: > > constovfl.pas failed: failed 0 > dialec3.pas failed > fjf149.pas failed: 64 > fjf83.pas failed: Failed > goto4.pas failed > > These Err messeges appeared just before dialec3.pas: > > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function > `_p_pipe': > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): > multiple definition of `_p_pipe' > pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first > defined here > /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o > collect2: ld returned 1 exit status > /tmp/cc0y2DBt.s: Assembler messages: > /tmp/cc0y2DBt.s:110: Error: operands given don't match any known 386 > instruction > > > Are the results what you expected? Not really. Generally, we expect all tests in that directory to succeed. But I'll have to leave this to Peter who can tell if these are new bugs or only problems in connection with the new GCC versions... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: test results
by Peter Gerwinski 25 Nov '99

25 Nov '99

"Russ Whitaker" wrote: > > constovfl.pas failed: failed 0 > fjf83.pas failed: Failed > goto4.pas failed These are "known bugs" in a GPC that works with gcc-2.95.x. I did not move them to the `knownbugs' subdirectory because I was hoping to have them fixed within days after the alpha release. :-I > fjf149.pas failed: 64 This is not really a bug but a change in the way `BitSizeOf' works. I am still unsure wheter we should keep the current behaviour, so I did not yet adapt the test program. > dialec3.pas failed This one should not occur - and does not occur on all systems I have access to. > These Err messeges appeared just before dialec3.pas: > > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function > `_p_pipe': > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): > multiple definition of `_p_pipe' > pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first > defined here > /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o > collect2: ld returned 1 exit status Very strange. It seems as if the test compilation uses `pipec.c' twice from two different directories. It would be useful to see the output of `gpc -v' here, but currently I cannot promise to handle it with high priority. :-( Sorry for that.) > /tmp/cc0y2DBt.s: Assembler messages: > /tmp/cc0y2DBt.s:110: Error: operands given don't match any known 386 > instruction Doesn't this belong to `goto4'? Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

2 1

binaries for gpc on win98/NT platforms
by Scott Brown 24 Nov '99

24 Nov '99

I'm having trouble getting GPC up and running on my home pcs. It would make things very much easier if I could get some binaries instead of source code (as I haven't got the c/c++ compiler either!). Does anyone know where I can find a download site for such things? Do they even exist? Thanks. Scott.

2 1

Re: CRT Unit
by Frank Heckenbach 24 Nov '99

24 Nov '99

"Ariel Bendersky" wrote: > > Did you install the required libraries (see the comments in the CRT > > unit)? > > I have just installed the pdcurse, but the version 2.4, because I > haven't found the 2.3. Anyway, it still gives the same error. 2.4 is fine. The comment referring to 2.3 was a little old (I'll change it). > > Which system do you use? In the case of Dos, you might need to use > > --autobuild because of the automake bugs. > > I'm on DOS, with djgpp. And I tried with the --autobuild, but I still > get the same error. Or in some cases I get a "cannot compile CRT > unit". That's strange. I can reproduce the problem under DJGPP with --automake, but it vanishes with --autobuild. To be sure, please remove all compiled crt*.o and crt*.gpi files once and try again. Did you try it on the command line, or only under rhide? If it works on the command line, but not in rhide, you'll have to edit rhide's settings (this was discussed on this list some time ago, but if you don't have the mails, I could find them). If it doesn't work on the command line either, please compile with `-v' (verbose), and send a complete log of the output. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Unit behaviour
by Marc van Woerkom 24 Nov '99

24 Nov '99

Hi! I have a question concerning the use of units. Consider this example: (*****************) (** Queue.pas **) (*****************) unit Queue; interface function isEmpty : boolean; {..} implementation {..} begin {..} end. { Queue } (**************) (* Test.pas *) (**************) uses Queue; begin {..} if Queue.empty then writeln('Queue is empty!'); {..} end. { Test } I expected to be able to use a "Queue." qualifier in front of the empty call in the test routine. But the compiler complains about an undeclared symbol Queue. Is this a bug or a feature? If the latter, how am I supposed to differentiate between the empty function of an Queue and a Stack, if not by using Queue.empty / Stack.empty? Regards, Marc

2 4

FreeBSD port
by Marc van Woerkom 24 Nov '99

24 Nov '99

As posted earlier, I am working on a FreeBSD port of gpc. So far I managed to create these two versions together with gcc 2.8.1: Reading specs from /usr/ports/lang/gpc/inst/lib/gcc-lib/i386-unknown-freebsd4.0/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 Reading specs from /usr/ports/lang/gpc/inst2/lib/gcc-lib/i386-unknown-freebsd4.0/2.8.1/specs gpc version 19991030, based on gcc-2.8.1 I agreed with our primary compiler maintainer to first finish a clean gcc 2.8.1 based port and then move on to the latest gcc (2.96) we have ported. This is mostly because gpc is easier to integrate with the gcc-2.8.1 port. A major problem is how to distinguish errors due to plattform issues from bugs in the compiler (modulo my limited experience with the gpc dialect of Pascal :) Using a test suite would be very helpful. Something like that is mentioned in the gpc info documentation. Can you point me to a set of test programs (with a statement what is supposed to work and what not)? I would also like to know roughly how dependent gpc is on the gcc backend, do you have something like a reference version of gcc, one to test against? Regards, Marc

2 2

Re: Warnings?
by Frank Heckenbach 23 Nov '99

23 Nov '99

Marc van Woerkom wrote: > > This is indeed only detected when the compiler is tracking > > each variable carefully enough - which is the case only with > > optimization. BTW, global variables are never considered > > uninitialized because they are initialized to zero (or Nil or > > false or empty string or ...) at the beginning of the program. > > I have no problems with it, as a TP and C++ vet, but the Pascal > purists do .. > > When I used gpc for a problem in a programming course recently, > I got some points deducted, because of an unitialized variable > (FeldMax in the example below), the use of the 'Ã¶' Umlaut > in the comment at the beginning and (this gpc is not supposed > to check :) the waste of an array for determing the maximum. Don't get this wrong, but... Better don't rely too much on the compiler's checks and warnings in a programming course, to train yourself to be more careful. It's better to learn programming without so much compiler assistance and later use all the compiler's features for production compiling, than relying on the checks and perhaps sometime later having to do some work in an environment without so many checks available... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Calling C functions in DLL from a Pascal program (Windows 9X environment)
by GiDeSa 23 Nov '99

23 Nov '99

Hello, I have this problem: I want to call some functions in a Windows DLL, the functions are C ones, then I know the list and type of C parameters to pass. Have anyone some suggestions? What are the correspondence from GPC Pascal types to C types? Thank you

3 2

Re: Problem with strings in record imported/exported from/to modules
by Frank Heckenbach 23 Nov '99

23 Nov '99

David James wrote: > I converted my previous test from extended Pascal modules to units. > This is unit dajunit3 and program daj3u, attached. This case works. > daj3u makes the record using new(). So this bug is somehow module-specific. Peter is investigating it, but I don't know the current status... > However what I really want to do is to put this record into shared > memory, so I moved to daj4u and dajunit4, attached. This fails. > > Eventually, I tried setting the string's capacity before trying to > assign a value to it, and, of course, then the program works. > > My question is really what is the recommended way to do this: is it > to set the string's capacity, or should I be calling some other > function to initialise the record proerly after I shmat the shared > memory? I assume that new(record_pointer) is initialising string > capacities within the record, somehow. Oh, I see. That's a completely new thing, something which hasn't been tried with GPC yet. So, let's see, what would be a good solution here... - We could implement a routine that will initialize any data structure, just like `New' does. Technically, this might not be too difficult (Peter?), but OTOH, such a routine could be easily abused when applied to structures already initialized. (In the case of string or schema fields, this would not do much harm, but in the case of files, it could...) - You could use some lower-level hooks into GPC's memory manager. These hooks already exist in the gpc unit (originally introduced to implement some BP compatible stuff in the system unit). They allow you to redirect any raw memory de-/allocations to user-defined routines, while GPC will still do all the initializations of strings, schemata, files, objects, etc. I'm appending a crude example of this below. You might want to move the connect_shared_memory call into ShmGetMem, but it basically works. If you ever Dispose of this record, you will have to provide a similar FreeMem routine, because otherwise the memory would be given to free() which might not know what to do with it (and might segfault or whatever)... program daj4u(output); uses gpc, dajunit4; var size:integer; shmflg1:integer; shmflg2:integer; base_key:integer; shmid:integer; shmaddr:pointer; err:integer; OldGetMem : GetMemType; function ShmGetMem (Size : SizeType) : Pointer; begin (* we probably should check Size here, but that's just a simple demo... *) ShmGetMem := shmaddr end; begin base_key:=16; size:=sizeof(ty_shared_data); shmflg1:=IPC_CREAT + 8#666; shmflg2:=0; writeln('Calling shmget with key ',base_key:1,' for size ',size:1, ' with flags ',shmflg1:1,' and ',shmflg2:1); connect_shared_memory(base_key,size,shmflg1,shmflg2,shmid,shmaddr,err); writeln('returned from connect_shared_memory for main shared memory ', shmid:1,' ',integer(shmaddr):1); if shmid=-1 then begin writeln('Failed to get main shared memory, reason ',err:1); halt; end; if integer(shmaddr)=-1 then begin writeln('Failed to attach main shared memory, reason ',err:1); halt; end; OldGetMem := GetMemPtr; GetMemPtr := @ShmGetMem; New (shared_data); GetMemPtr := OldGetMem; with shared_data^ do begin sanity:=4567; writeln('sanity is ',sanity); prefix:='ABCD'; if (prefix='ABCD') then writeln('OK') else writeln('failed ',prefix,'|'); end; end. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 22 Nov '99

22 Nov '99

In message <214E52CA.19991120140550.FOO-4F71.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > > > I'm having problems with a string in a record that is exported > > from one module and imported into another. I *hope* I am doing > > something stupid! > > > > The maodule (dajmod3.pas) and main program (daj3.pas) below > > should illustrate the problem. > > > > [...] > > This seems to be another innstance of a known bug with string types. > Thanks for the report and the test program which I'm adding to the > test suite. I converted my previous test from extended Pascal modules to units. This is unit dajunit3 and program daj3u, attached. This case works. daj3u makes the record using new(). However what I really want to do is to put this record into shared memory, so I moved to daj4u and dajunit4, attached. This fails. Eventually, I tried setting the string's capacity before trying to assign a value to it, and, of course, then the program works. My question is really what is the recommended way to do this: is it to set the string's capacity, or should I be calling some other function to initialise the record proerly after I shmat the shared memory? I assume that new(record_pointer) is initialising string capacities within the record, somehow. ===== program daj3u(output); uses dajunit3; begin new(shared_data); with shared_data^ do begin sanity:=4567; writeln('sanity is ',sanity); prefix:='ABCD'; if (prefix='ABCD') then writeln('OK') else writeln('failed ',prefix,'|'); end; end. ===== unit dajunit3; interface TYPE astring=string(255); tshared_data = record sanity:integer; prefix:astring; end; VAR shared_data : ^tshared_data; implementation end. {of unit implentation} ===== program daj4u(output); uses dajunit4; var size:integer; shmflg1:integer; shmflg2:integer; base_key:integer; shmid:integer; shmaddr:pointer; err:integer; begin base_key:=16; size:=sizeof(ty_shared_data); shmflg1:=IPC_CREAT + 8#666; shmflg2:=0; writeln('Calling shmget with key ',base_key:1,' for size ',size:1, ' with flags ',shmflg1:1,' and ',shmflg2:1); connect_shared_memory(base_key,size,shmflg1,shmflg2,shmid,shmaddr,err); writeln('returned from connect_shared_memory for main shared memory ', shmid:1,' ',integer(shmaddr):1); if shmid=-1 then begin writeln('Failed to get main shared memory, reason ',err:1); halt; end; if integer(shmaddr)=-1 then begin writeln('Failed to attach main shared memory, reason ',err:1); halt; end; shared_data:=shmaddr; with shared_data^ do begin sanity:=4567; writeln('sanity is ',sanity); (*if we set the string capacity here, everything works prefix.capacity:=255; *) prefix:='ABCD'; if (prefix='ABCD') then writeln('OK') else writeln('failed ',prefix,'|'); end; end. ===== unit dajunit4; interface const IPC_CREAT = 8#0001000; (* create entry if key doesn't exist *) TYPE astring=string(255); ty_shared_data = record sanity:integer; prefix:astring; end; VAR shared_data : ^ty_shared_data; procedure connect_shared_memory(key,size,shmflg1,shmflg2:integer; var shmid:integer; var shmaddr:pointer; var err:integer); implementation var errno: asmname 'errno' integer; function shmget(key:integer; size, shmflg:integer):integer; C_language; function shmat (shmid:integer;shmaddr:integer; shmflg:integer):pointer; C_language; procedure connect_shared_memory; var retval:pointer; inshmaddr:integer; begin shmid:=-1; inshmaddr:=-1; shmid:=shmget(key,size,shmflg1); if shmid=-1 then begin err:=errno; end else begin inshmaddr:=0; retval:=shmat(shmid,inshmaddr,shmflg2); if integer(retval)=-1 then begin integer(shmaddr):=-1; err:=errno; end else begin shmaddr:=retval; end; end; end; end. {of unit implentation} ===== -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: Prototypes translations
by Frank Heckenbach 21 Nov '99

21 Nov '99

Nicola Girardi wrote: > i'm translating svgalib header file (vga.h) under pascal > to make it simply available by using vga.gpi. > > i have some troubles in translating some things, and i ask > you for help... > > these are things i can't translate (they are part of a struct/record) > > {FIXME void *extensions;} Extensions : Pointer; > {FIXME char *linear_aperture;} type TBytes = array [0 .. MaxInt] of Byte; PBytes = ^TBytes; LinearAperture : PBytes; (Most of the time, char * is CString, but here, this is clearly not a C string, but rather a pointer to a 0-based array of Byte (Byte in Pascal is unsigned char in C), so the above is probably the best approximation...) > {FIXME void (*set_aperture_page) (int page);} SetAperturePage : ^procedure (Page : Integer); > {FIXME unsigned char *colors)} Colors : PBytes; Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Prototypes translations
by Nicola Girardi 21 Nov '99

21 Nov '99

i'm translating svgalib header file (vga.h) under pascal to make it simply available by using vga.gpi. i have some troubles in translating some things, and i ask you for help... these are things i can't translate (they are part of a struct/record) {FIXME void *extensions;} {FIXME char *linear_aperture;} {FIXME void (*set_aperture_page) (int page);} {FIXME unsigned char *colors)} thanks in advance -- Nicola Girardi aka nikke <girardi(a)keycomm.it>

1 0

Free Vision
by Pablo Bendersky 21 Nov '99

21 Nov '99

Hi ! Does anyone know where can I get free vision ? (For GPC, or better GCC) Thanks !

3 2

Warnings?
by Marc van Woerkom 21 Nov '99

21 Nov '99

What Warnings are supposed to work right now? I have the impression that -Wall, -pedantic do have not much effect. E.g. detecting uninitialized variables seems to be a problem (did not work too when using -O, -O2..) Regards, Marc

2 2

Re: Problem with strings in record imported/exported from/to modules
by Frank Heckenbach 20 Nov '99

20 Nov '99

David James wrote: > I'm having problems with a string in a record that is exported > from one module and imported into another. I *hope* I am doing > something stupid! > > The maodule (dajmod3.pas) and main program (daj3.pas) below > should illustrate the problem. > > [...] This seems to be another innstance of a known bug with string types. Thanks for the report and the test program which I'm adding to the test suite. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 20 Nov '99

20 Nov '99

In message <214E52CA.19991120140550.FOO-4F71.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > > > I'm having problems with a string in a record that is exported > > from one module and imported into another. I *hope* I am doing > > something stupid! > > [...] > > This seems to be another innstance of a known bug with string types. > Thanks for the report and the test program which I'm adding to the > test suite. Any ideas on whether this is likely to be fixed soon? or whether there are any reasonable work-arounds? The application I am trying to port uses shared memory to share data between multiple processes (running for different users). The shared memory is handled as a large (>200 kbyte) Pascal record with the definition of the record and the procedures to handle the data structure being defined and exported in a module and imported by nearly all the rest of the system. This bug looks rather like a showstopper for my application. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: -x lang and .PAS extension
by Frank Heckenbach 19 Nov '99

19 Nov '99

Dr A Olowofoyeku wrote: > One option for dealing with this is for gpc.exe to convert the filename > to lowercase before passing it on (only on systems such as Win32 > and Dos which do not care about the case of filenames). Another option would be to recognize '*.PAS' as Pascal files. This could be done on every system and would prevent a (small) problem when, say, unpacking a zip file created on Dos with capital file names on a Unix machine... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: -x lang and .PAS extension
by Alexandre Oliva 19 Nov '99

19 Nov '99

On Nov 18, 1999, "Dr A Olowofoyeku" <laa12(a)keele.ac.uk> wrote: >> % gpc FOO.PAS > One option for dealing with this is for gpc.exe to convert the filename > to lowercase before passing it on I don't think this is a good idea. Case matters even on MS-DOS based systems; think of .C (implies -x c++) and .c (implies -x c). Of course, GPC could recognize .PAS and .Pas as pascal extensions, but I don't see any need for it, as long as -x pascal works. > I can send you a diff for gpc.c if you want Thanks, but it was just a week-end issue. Thanks God now I'm back to real operating systems :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

-x lang and .PAS extension
by Alexandre Oliva 18 Nov '99

18 Nov '99

Hi! I've recently had the unfortunate opportunity of having to invoke gpc/cygwin from a compiling/testing engine that used only MS-DOS file names (i.e., all-caps 8.3). (if anybody cares, it was University of California at San Diego's PC^2, an ACM Programming Contest management program) The problem was that, when invoking gpc, the program used the .PAS extension, which gpc didn't recognize as a valid source file, and passed it to the linker. % gpc FOO.PAS /n/gnu/gcc-2.95.2-gpc-19991030-libg++-2.8.1.3-libgcj-2.95.1/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/real-ld:FOO.PAS: file format not recognized; treating as linker script /n/gnu/gcc-2.95.2-gpc-19991030-libg++-2.8.1.3-libgcj-2.95.1/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/real-ld:FOO.PAS:1: parse error collect2: ld returned 1 exit status No problem, I though, I just need to insert `-x pascal' before the source filename, as I had done in the gcc and g++ compiling scripts. Unfortunately, it failed too: % gpc -x pascal FOO.PAS gpc: Internal GPC problem: internal option `--amtmpfile' not given I ended up having to write a shell-script that would convert the extension to lower case, so it wasn't a show-stopper. Anyway, I believe it would be nice if gpc were more gcc-like, in the sense of accepting `-x' (and any other flags gcc accepts, for that matter). Cheers, -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

2 1

Re: What do you want to have fixed/implemented in gpc-2.1?
by Frank Heckenbach 18 Nov '99

18 Nov '99

On Tue, 19 Oct 1999 Peter wrote: Hello, folks! : We are approaching a version of GPC that will (a) compile with : gcc-2.95.x and (b) only need minimal patches to the GCC backend. : : With the next version of the GNU Compiler Collection (GCC), we want : to publish the long-expected gpc-2.1 as a fully integrated frontend. : We expect this next GCC release (2.9x or 3.0) to happen within the next : two months or so. : : It is not realistic to fix all bugs and to implement all wanted features : listed in the GPC TODO list (http://fjf.gnu.de/gpc-todo_toc.html) within : this time schedule. However, most of the bugs listed there are not : really relevant to real-world praxis. So we are planning to re-sort the : TODO list and to focus on the most important bugs and feature requests. : : Please tell us which bugs and/or missing features on the TODO list, : section "Urgent", you consider the most urgent. : : And of course, your help to fix those bugs is welcome. Based of the feedback we have received, I have updated the To-Do list which will hopefully enable us now to produce a GPC 2.1 fully integrated into GCC soon. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 6

Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 17 Nov '99

17 Nov '99

I'm having problems with a string in a record that is exported from one module and imported into another. I *hope* I am doing something stupid! The maodule (dajmod3.pas) and main program (daj3.pas) below should illustrate the problem. This is on a system which identifies itself as Eridani / Red Hat Linux 6.0 (Hedwig) Kernel 2.2.5-15 on an i586 The output of gpc -v is Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 19991030, based on 2.95.2 19991024 (release) daj3.pas: ======== program daj3(output); import globaltypes in 'dajmod3.pas'; globalvars in 'dajmod3.pas'; begin shared_data.prefix:='ABCD'; if (shared_data.prefix='ABCD') then writeln('OK') else writeln('failed ',shared_data.prefix,'|'); end. dajmod3.pas: =========== module dajmod3 interface; export globaltypes =(astring); globalvars =(shared_data); TYPE astring=string(255); VAR shared_data : record prefix:astring; end; end. {of module header} module dajmod3 implementation; end. {of module implentation}

1 0

32-bit dll in GNU Pascal
by Joanna Owczarzak 17 Nov '99

17 Nov '99

Hi! I generated 32-bit dll in GNU Pascal. I used examples from GNU Pascal. My new functions (added to that example) work with *.exe program (that program was in examples too) which uses that dll. But when I'm trying to run function from my dll in my program written in Power Builder 6.0 I get message:"Error opening dll library testdll.dll for external function" Thanks in advance. Joanna

2 1

Re: native building of gpc 19991030 / gcc 2.95.2 for djgpp
by Frank Heckenbach 16 Nov '99

16 Nov '99

Maurice Lombardi wrote: > I succeeded in this native building with only one change to gpc sources due to a > DOS peculiarity. > The problem comes from the following lines contained (at two different > locations) in p/Make-lang-2.95.in > > CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e > 's,^$[^/][^ ]*$,../../\1,'`" \ > PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e > 's,^$[^/][^ ]*$,../../\1,'`" \ > > It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET > if this is a relative, not an absolute directory name. Absolute is recognized by > the first character being a slash. However in DOS an absolute pathname starts > with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute > pathname built through `pwd` in the top makefile, which gives the drive letter. > Solutions could be > - saying that an absolute pathname has either / as first character or : as > second. Can be garbled by a unix relative path starting with d: is this possible > in this context? This gives the attached notroot.dif > - saying that a relative pathname starts by ./ or ../ This is what occurs for > GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary > character, is this possible in this context? This gives the attached > relative.dif. > You can incorporate one of these solutions (or a better you may imagine) into > the gpc sources, or let the djgpp maintainers to make the patch only for djgpp > (and probably other DOS systems). The last solution would mean however the need > to modify the patch for each new gpc alpha or beta distribution, so that the > first is highly preferred. As you say, it can garble unix paths starting with `d:', and also (Unix and Dos) paths consisting of only 1 letter, in particular `.'. I don't know the build process of gcc-2.95 well, so I don't know if these are possible in this context, but it's possible to modify the substitution so as to recognize 1-letter paths. The following should do the trick, but is *untested*: 's,-B$[^/]\([^:].*$\?\)$$,-B../../\1,g' (The double `$' is necessary when using it in a Makefile.) Furthermore, in order to restrict the change only to Dos systems, I suggest the following: - Make the substitution (the string above) a make variable. - Set it to the Unix substitution by using an assignment in the Makefile. - Make sure the variable is transported to sub-makes (see GPC_FLAGS_TO_PASS, GPC_INSTALL_FLAGS_TO_PASS). - When building under Dos, you can override the value on the command line (takes precedence over assignments in the Makefile). You can put this in a batch file or whatever you use to invoke make. - Alternatively, you can hack config-lang.in to add this value automatically on Dos systems, but I can't give you any advice about this, since I don't know this stuff well. > For those interested to internals of djgpp. The beta bash version enables (when > setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more > unix-like behavior, which seems to solve the above problem. Bash understands > command lines starting with /dev/c/bin/something.exe but DOS (command.com) does > not understand ! Now, as explained to me by Eli Zaretskii to solve an other > hairy problem, the djgpp port of Make sends command lines to bash only if he > thinks that the shell is involved, and to COMMAND.COM otherwise (to save > overhead). He recognizes that the shell is needed if the make line includes > something which belongs to the shell, which could be a simple ; at the end of > the makefile line. I have tried to build with PATH_EXPAND=N, it stops building > the rts at the first command line > $(GCC_FOR_TARGET) so so > When adding a ; at the end of that makefile line, make goes somewhat further, > but stops at the next occurrence, which shows that this is indeed the problem. > Now is the overhead in make large enough to warrant all these inconveniences? I'm not sure, though I would guess not, as far as GPC's build process is concerned. But if I understood you right, there's nothing we can do about it anyway, because that happens to be make's behaviour under DJGPP, doesn't it? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

New bug in GPC 19991030 ?
by Maurice Lombardi 16 Nov '99

16 Nov '99

Hi all, While running demos and tests on the newly built GPC 1991030 / gcc-2.95.2 for djgpp I have found two occurences of the same bug. They are in test/goto4.pas and demos/parserdemo.pas Error message is (for parserdemo) f:/djgpp/tmp\ccbqrrbj.s: Assembler messages: f:/djgpp/tmp\ccbqrrbj.s:2010: Error: operands given don't match any known 386 instruction The offending instruction is movl $L177,$__p_MPNGHS eliminating the second $ to give movl $L177,__p_MPNGHS manual assembly and linking gives the correct result. Is this reproducible on other systems ? Has it something to do with new assembly errors generated by gcc-2.95 ? Hope this helps Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

native building of gpc 19991030 / gcc 2.95.2 for djgpp
by Maurice Lombardi 16 Nov '99

16 Nov '99

Hi all I succeeded in this native building with only one change to gpc sources due to a DOS peculiarity. The problem comes from the following lines contained (at two different locations) in p/Make-lang-2.95.in CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e 's,^$[^/][^ ]*$,../../\1,'`" \ PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e 's,^$[^/][^ ]*$,../../\1,'`" \ It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET if this is a relative, not an absolute directory name. Absolute is recognized by the first character being a slash. However in DOS an absolute pathname starts with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute pathname built through `pwd` in the top makefile, which gives the drive letter. Solutions could be - saying that an absolute pathname has either / as first character or : as second. Can be garbled by a unix relative path starting with d: is this possible in this context? This gives the attached notroot.dif - saying that a relative pathname starts by ./ or ../ This is what occurs for GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary character, is this possible in this context? This gives the attached relative.dif. You can incorporate one of these solutions (or a better you may imagine) into the gpc sources, or let the djgpp maintainers to make the patch only for djgpp (and probably other DOS systems). The last solution would mean however the need to modify the patch for each new gpc alpha or beta distribution, so that the first is highly preferred. The building has been made in a W98 DOS box, LFN=Y, with binutils 2.8.1 and the beta version 2.0.3 of bash for djgpp. I can upload the resulting binary file if you are interested. For those interested to internals of djgpp. The beta bash version enables (when setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more unix-like behavior, which seems to solve the above problem. Bash understands command lines starting with /dev/c/bin/something.exe but DOS (command.com) does not understand ! Now, as explained to me by Eli Zaretskii to solve an other hairy problem, the djgpp port of Make sends command lines to bash only if he thinks that the shell is involved, and to COMMAND.COM otherwise (to save overhead). He recognizes that the shell is needed if the make line includes something which belongs to the shell, which could be a simple ; at the end of the makefile line. I have tried to build with PATH_EXPAND=N, it stops building the rts at the first command line $(GCC_FOR_TARGET) so so When adding a ; at the end of that makefile line, make goes somewhat further, but stops at the next occurrence, which shows that this is indeed the problem. Now is the overhead in make large enough to warrant all these inconveniences? Hope this helps. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

PROBLEM TO COMPILE WITH GPC
by Yves POCCHIOLA 15 Nov '99

15 Nov '99

For my first trial of GNU PASCAL, I get compilation error with message: impossible to load module GPC. I have loaded GNU PASCAL for LINUX with the binary package "gpc-19990118-egcs-1_1_1_i386-pc-linux-gnu". The decompression gives a directory "usr" in the working directory. There is no indication on howto configure the environment (PATH, specific variables). I have made some tentatives with PATH (bin and lib directory declaration) and variables (COMPILER_PATH, LIBRARY_PATH) but I always get a message saying a module is missing. This problem occurs either in command line mode or EMACS. Can somebody help me. Thanks.

2 1

GPC 19991030 for Solaris 7 Sparc/x86
by Mariusz Zynel 14 Nov '99

14 Nov '99

GNU Pascal Compiler binaries for Sun Solaris 7 (Sparc/x86) operating environment in native Solaris packages form are available at: Sparc: ftp://mizar.uwb.edu.pl/pub/misc/solaris7/sparc http://math.uwb.edu.pl/download/solaris7/sparc x86: ftp://mizar.uwb.edu.pl/pub/misc/solaris7/x86 http://math.uwb.edu.pl/download/solaris7/x86 For installation instructions read Readme.txt file. GPC 19991030 was compiled based on GCC 2.95. Hope someone uses this -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

1 0

Cannot compile GPC
by Konstantin R.Beliaev 13 Nov '99

13 Nov '99

Hello. Something is wrong when I try to compile GPC. Can anyone helps me ? I have downloaded gcc-2.8.1, gpc-19990118, # patch -s -p1 < p/diffs/gcc-2.8.1.diff (without any messages) # ./configure # make LANGUAGES=pascal Last statement produce message "`all' not remade because of errors". Why? See session log as attachment. Thanks in advance, Konstantin main# pwd /usr/src/gnu/gcc-2.8.1 main# ./configure loading cache ./config.cache checking host system type... i386-unknown-freebsd2.2.8 checking target system type... i386-unknown-freebsd2.2.8 checking build system type... i386-unknown-freebsd2.2.8 checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking for mawk... (cached) awk checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking for ranlib... (cached) ranlib checking for bison... (cached) bison -y checking for a BSD compatible install... (cached) /usr/bin/install -c checking how to run the C preprocessor... (cached) gcc -E checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for limits.h... (cached) yes checking for stddef.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking for time.h... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/file.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/param.h... (cached) yes checking for sys/times.h... (cached) yes checking for inttypes.h... (cached) no checking for strerror... (cached) yes checking for putenv... (cached) yes checking for popen... (cached) yes checking for vprintf... (cached) yes checking for bcopy... (cached) yes checking for bzero... (cached) yes checking for bcmp... (cached) yes checking for index... (cached) yes checking for rindex... (cached) yes checking for kill... (cached) yes checking for getrlimit... (cached) yes checking for setrlimit... (cached) yes checking for sysconf... (cached) yes checking whether malloc must be declared... (cached) no checking whether realloc must be declared... (cached) no checking whether calloc must be declared... (cached) no checking whether free must be declared... (cached) no checking whether index must be declared... (cached) no checking whether rindex must be declared... (cached) no checking whether getenv must be declared... (cached) no checking whether sbrk must be declared... (cached) no checking for sys_siglist declaration in signal.h or unistd.h... (cached) yes Using `./config/i386/i386.c' to output insns. Using `./config/i386/i386.md' as machine description file. Using `./config/i386/freebsd.h' as target machine macro file. Using `./config/i386/xm-i386.h' as host machine macro file. Using `./objc/thr-single.c' as Objective-C Runtime thread file. Links are now set up to build a native compiler for i386-unknown-freebsd2.2.8 updating cache ./config.cache creating ./config.status creating Makefile creating cp/Makefile creating auto-config.h auto-config.h is unchanged Merged i386/t-freebsd. Created `objc/Makefile'. Merged i386/t-freebsd. Created `p/Makefile'. main# make LANGUAGES=pascal gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DGCC_INCLUDE_DIR=\` gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DPREFIX=\"/usr/loc` gcc -DIN_GCC -g -DHAVE_CONFIG_H -o cccp cccp.o cexp.o prefix.o version.o rm -f cpp ln cccp cpp > /dev/null 2>&1 || cp cccp cpp /bin/sh ./genmultilib "" "" "" "" "" > tmp-mlib.h ./move-if-change tmp-mlib.h multilib.h multilib.h is unchanged touch s-mlib gcc -DGPC -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DGPC_MAJOR=o gcc -DGPC -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DGPC_TIME="\o gcc -DIN_GCC -g -DHAVE_CONFIG_H -o xgpc p/gpc.o prefix.o p/version.o cho gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DSTANDARD_STARTFIL` gcc -DIN_GCC -g -DHAVE_CONFIG_H -o xgcc gcc.o prefix.o version.o choose- rm -f tmplibgcc1.a for name in _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _lshrsi3 _ashrsi3 _ashlse _mulsi3 _udivsi3 _divsi3 _umodsi3 _modsi3 _lshrsi3 _ashrsi3 _ashlsi3 _divdf3 _muldf3 _negdf2 _adddf3 _subdf3 _fixdfsi _fixsfsi _floatsidf _floatsisf _truncdfsf2 _extendsfdf2 _addsf3 _negsf2 _subsf3 _mulsf3 _divsf3 _eqdf2 _nedf2 _gtdf2 _gedf2 _ltdf2 _ledf2 _eqsf2 _nesf2 _gtsf2 _gesf2 _ltsf2 _lesf2 for file in .. ; do if [ x${file} != x.. ]; then name=`echo ${file} | sed -ee if [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ; then ranlib tmplibgcc1.a; else tri mv tmplibgcc1.a libgcc1.a if [ -f libgcc2.ready ] ; then true; else touch libgcc2.ready; fi Graph cycles through pascal rm -f include/float.h if [ -f /usr/include/float.h ] && if grep 'ifndef _FLOAT_H___' /usr/include/flc ./xgcc -B./ -DIN_GCC -g -I./include enquire.o -o enquire ./enquire -f > tmp-float.h grep '#define [^_]' tmp-float.h >/dev/null || true > tmp-float.h mv tmp-float.h float.h-nat rm -f gfloat.h cp float.h-nat gfloat.h rm -f include/float.h if [ -s gfloat.h ]; then cp gfloat.h include/float.h && chmod a+r include/floi touch stmp-headers ./xgcc -B./ -dumpspecs > tmp-specs mv tmp-specs specs gcc -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config -DSTANDARD_STARTFILc gcc -DIN_GCC -g -DHAVE_CONFIG_H -o g++ g++.o g++spec.o prefix.o version. echo "int xxy_us_dummy;" >tmp-dum.c ./xgcc -B./ -S tmp-dum.c echo '/*WARNING: This file is automatically generated!*/' >tmp-under.c if grep _xxy_us_dummy tmp-dum.s > /dev/null ; then echo "int prepends_underscoi ./move-if-change tmp-under.c underscore.c underscore.c is unchanged rm -f tmp-dum.c tmp-dum.s touch s-under gcc -c -DIN_GCC -g -DHAVE_CONFIG_H -I. -I. -I./config underscore.c gcc -DIN_GCC -g -DHAVE_CONFIG_H obstack.o ` case "gcc" in "cc") echo "" ;o `all' not remade because of errors.

1 0

Re: segmentation fault
by Frank Heckenbach 13 Nov '99

13 Nov '99

Profeta Mickael wrote: > I installed binary of gpc on my linux/pentium computer. When I manage to > compile a pascal source, I cannot execute the file a.out created, I always got > the same answer: segmentation fault! Which binary did you use? On agnes, there are different ones for libc5 and glibc. If you got the wrong one for your system (if it's a new installation, your system it most likely glibc), it may not work. There is also a little incompatibility between some distributions in their glibc versions -- which distribution do you use? If nothing else helps, you can always get the sources (GCC and GPC), and compile GPC yourself. Under Linux, this is not very difficult. > On the other hand, to compile demos programs I must be root? If you try to compile them in the demos directory, and this is owned by root, then yes. But if you compile them while you are in your home directory (either by copying them there, or by giving the full path to the source), you don't have to be root. You can also use the option `--executable-path=$HOME/bin' (say) to tell GPC to create the exectuables a bin directory below your home directory, and similarly e.g. `--unit-destination-path=$HOME/objects' to tell it where to put compiled units. The directories must exist before calling GPC. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

segmentation fault
by Profeta Mickael 12 Nov '99

12 Nov '99

I installed binary of gpc on my linux/pentium computer. When I manage to compile a pascal source, I cannot execute the file a.out created, I always got the same answer: segmentation fault! On the other hand, to compile demos programs I must be root? May you help me to solve this trouble Thanks Mike

1 0

GPC 2.0 1999/01/18 for Sparc Solaris 7
by Mariusz Zynel 12 Nov '99

12 Nov '99

Dear GPC enthusiasts Precompiled GPC 19990118 with unit sources and precompiled units for Sparc Solaris 7 in pkgadd format is available at: http://math.uwb.edu.pl/download/solaris7/sparc/ and ftp://mizar.uwb.edu.pl/pub/misc/ Regards -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

2 2

Re: Bug report for GPC
by Frank Heckenbach 12 Nov '99

12 Nov '99

David Chandler wrote: > Dear GPC programmers, > > Here at NPL we have Pascal compiler testing software that generates self > checking, legal Pascal source code for the purpose of testing Pascal > compilers. We used this tool to test your compiler and generated the > following bug. > > Your compiler version: > > egcs-2.91.66 1990314 (egcs-1.1.2 release) > > The results of this test show that your compiler failed during compilation > of the following program: > > program test(output); > > type > T9 = false..true; > > var > failed : boolean; > V0 :T9 ; > V2 :T9 ; > > procedure P2; > > begin > failed := false; > V0 := true; > V2 := true = V0; > > { test code } > writeln("V2: ",V2); > writeln("V0: ",V0); > writeln("true: ",true); > end; > > begin P2; > > if V2 <> 1 then > begin > writeln('Verification test failed on line 93'); > failed := true; > end; > end. {Lines of code generated = 104} > > The problem appears to be that the compiler interprets the type > type "false..true" as being different from boolean. If this type is > changed to boolean, then the program runs correctly. > > The compiler options used to generate the test executable were: > > --standard-pascal > no optimisations > > The test platform was an Intel PC. It seems to me that the test program is wrong, and GPC (at least the current alpha version; I don't have 19990314 here to check) reports this error correctly: The program compares V2, which is of type T9 which is equivalent to Boolean, with 1, an integer. Perhaps this was just a mistake in the reproduction of the test program. We've had other bugs concerning types like "false..true", and if there are still such bugs left, we'd like to see a test program to show them... I'm also interested in your test tool. Is it (or the NPL report you mentioned) available on the Web, or how can we get at it? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

gcc 2.95.2
by Brian O'Gorman 11 Nov '99

11 Nov '99

I'm rather new at trying to install gpc, so please excuse this question if it's been discussed elsewhere. Can someone tell me if gpc can be installed if only gcc 2.95.2 is available; or is it gcc 2.8.1 that's needed?

3 2

Bug report for GPC
by David Chandler 11 Nov '99

11 Nov '99

Dear GPC programmers, Here at NPL we have Pascal compiler testing software that generates self checking, legal Pascal source code for the purpose of testing Pascal compilers. We used this tool to test your compiler and generated the following bug. Your compiler version: egcs-2.91.66 1990314 (egcs-1.1.2 release) The results of this test show that your compiler failed during compilation of the following program: program test(output); type T9 = false..true; var failed : boolean; V0 :T9 ; V2 :T9 ; procedure P2; begin failed := false; V0 := true; V2 := true = V0; { test code } writeln("V2: ",V2); writeln("V0: ",V0); writeln("true: ",true); end; begin P2; if V2 <> 1 then begin writeln('Verification test failed on line 93'); failed := true; end; end. {Lines of code generated = 104} The problem appears to be that the compiler interprets the type type "false..true" as being different from boolean. If this type is changed to boolean, then the program runs correctly. The compiler options used to generate the test executable were: --standard-pascal no optimisations The test platform was an Intel PC. If you have any queries or require further information concerning the tests performed or the tools used, please contact either myself at the contact points below, or the author of the test tool, Brian Wichmann at brian.wichmann(a)npl.co.uk If you would like further information on the test tool, PPG (Pascal Program Generator), there is an NPL report "Experience with a Compiler Testing Tool" ISSN 0262-5369. NPL Report DITC 138/89, which is available in electronic format. Regards, David Chandler ================================================================ David Chandler Email: david.chandler(a)npl.co.uk CISE SSS Tel: +44 0181 943 6962 National Physical Laboratory Mobile: +44 0789 973 4151 Teddington, Middlesex, UK. Fax: +44 0181 977 7091 WWW: http://www.npl.co.uk/

1 0

GPC for Solaris 7 x86
by Mariusz Zynel 11 Nov '99

11 Nov '99

Hi All There are binaries of GPC 1999/01/18 for Solaris 7 x86 in pkgadd format to download on: http://math.uwb.edu.pl/download/solaris7/x86/gpc-2.0-19990118-Solaris7-x86.… Some changes to installation instruction and Makefile should be made in order to built GPC under Solaris (both Sparc and x86). First of all Solaris patch utility requires the name of a file to be patched. So it is not possible to patch GCC sources. I patched GCC under Linux, then moved patched sources to Solaris box. There is a GNU patch wchich probably do the job, I haven't try it yet. I suggest to put a Solaris note in the installation instruction and warn that Solaris patch tool will not work. Next problem I faced was "if ! [ ... ]" in Makefile. Does it work under Linux? What would it mean "if ! [ -f file-a ] || [ -f file-b ]"? Is it negation of the first test issue or whole alternative? It's not correct and should be changed to "if [ ! ... ]". Build process itself went flawlesly. After make pascal.install some files are not installed at all. Make is not able to find install.sh for the following targets: pascal.install-units pascal.install-demos pascal.install-info I have no idea how to fix it but I belive you know. Please do apply those fixes and make some guys out the Linux community happier. If all that have been already fixed in some newer alpha release I apologize for wasting your precious time. Thanks for patience, best regards PS. Is there anybody who needs GPC working under Sparc Solaris? -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

2 1

RE: latest snapshot using GCC-2.95
by Russ Whitaker 10 Nov '99

10 Nov '99

Hi Dr A Olowofoyeku wrote: ... ( taking 2 hours and eating 100 mb of my hard disk space ) Looks like instead of "make bootstrap " we should be using "make bootstrap-lean" GCC says this deletes files after they are no longer needed. Since I've already used "make bootstrap" and "make install" ran "make bootstrap-lean" to see what would happen df reports 900049 1k blocks before. and 859745 blocks after thus freeing 45,304 k in the process Thanks, Russ <russwhit(a)mind.net>

3 2

RE: latest snapshot using GCC-2.95
by Russ Whitaker 08 Nov '99

08 Nov '99

Hi Had downloaded GCC-2.95.2 from egcs.cygnus.com on Nov 1 After geting GPC working made original post on what I did Here's some supplimentry information which might help clear the air: An excerpt from: "Installing GCC: Configuration" Quote: We use _srcdir_ to refer to the toplevel source directory for GCC; we use _objdir_ to refer to the toplevel build/object directory. First, we _highly_ recommend that GCC be built into a separate directory than the sources which does _not_ reside within the source tree. This is how we generally build GCC; building where _srcdir_ == _objdir_ should still work, but doesn't get extensive testing; ... To configure GCC: % mkdir _objdir_ % cd _objdir_ % _srcdir_/configure _[target]_ _[options]_ Use _options_ to override several configure time options for GCC. A partial list of supported options: * --enable-languages=_lang1_,_lang2_,... -- Specify that only a particular subset of compilers and their runtime libraries should be built. For a list of valid values for _lang_x you can issue the following command in the gcc directory of your GCC source tree: grep language= */config-lang.in Currently, you can use any of the following: CHILL, c++, f77, java and objc. Please note, that this switch does not work with EGCS 1.1.2 or older versions of egcs. It will be supported in GCC 2.95 and newer version. If you do not pass this flag, all languages available in the gcc sub-tree will be configured. Re-defining LANGUAGES when calling make bootstrap _*does not*_ work anymore, as those language sub-directories might not have been configured! _Last modified on July 16, 1999._ Unquote BTW, discovered once you run configure you can't run it again until you either erase certain file(s) in _objdir_ or use a different _objdir_ An excerpt from: "Installing GCC: Building" Quote Building a native compiler For a native build issue the command `make bootstrap'. This will build the entire GCC system, which includes the following steps: * Build host tools necessary to build the compiler such as texinfo, bison, gperf. * Build target tools for use by the compiler such as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they have been individually linked or moved into the top level GCC source tree before configuring. * Perform a 3-stage bootstrap of the compiler. * Perform a comparison test of the stage2 and stage3 compilers. * Build runtime libraries using the stage3 compiler from the previous step. If you used the flag --enable-languages=... to restrict the compilers to be built, only those you've actually enabled will be built. This will of course only build those runtime libraries, for which the particular compiler has been built. Please note, that re-defining LANGUAGES when calling `make bootstrap' _*does not*_ work anymore! _Last modified on August 27, 1999._ Unquote One last note: after installation GCC now reports same new version as GPC, cc reports the original version that was installed here

2 1

stack size again
by Peter Sondhauss 08 Nov '99

08 Nov '99

Hi everybody, probably my last e-mail was too long and people have not seen the questions at its end. I have still the problem with insufficient stack size. Therefore once more: Is there a possibility to increase the stack size for programs compiled with gpc under Linux? Please help me. There must be somebody, who has alrady used bgi2grx under Linux and had the same problems (and was hopefully more clever and solved them). Peter -- ___ ___ / _ \/ \ / / /\ \ / / ___/ _\ \ /_/ETER____/ONDHAUSS

1 0

(not) building gpc 19991030 on /alpha [patch]
by Alexandre Oliva 08 Nov '99

08 Nov '99

Hi! I'd never been able to build gpc on any alpha host: gpc1 would ICE while building a couple of files within gcc/p/rts, for example, error.pas. Tonight, I decided to try to track the problem down. First, I tried to come up with a minimal testcase that reproduced the problem: The problem was that, while expanding the ARRAY_REF, get_inner_reference() would build a MULT_EXPR with type ssizetype (SImode), but the index type was sizetype (DImode). Since there was no intervening convert(), expand_mult would call copy_to_mode_reg(SImode, a_DImode_register), that would abort(). The problem was that ssizetype was not being properly initialized so as to match sizetype, and it's fixed with the following patch, that matches the corresponding section of c-decl.c as of gcc 2.95.2 and current CVS: I'm Cc:ing the gcc mailing list because I thought we could have helped avoid this problem: - we could arrange that sizetype is no longer an lvalue, so that only set_sizetype would assign to it, and misuses would get a compile-time error instead of a run-time crash only on platforms with ssize_t == long == DImode and int == SImode. - in the code snippet below, from expr.c:get_inner_reference(), we could explicitly convert index to ssizetype. AFAICT, fold would drop the conversion if it found it needless. /* Either the bit offset calculated above is not constant, or it overflowed. In either case, redo the multiplication against the size in units. This is especially important in the non-constant case to avoid a division at runtime. */ xindex = fold (build (MULT_EXPR, ssizetype, index, convert (ssizetype, TYPE_SIZE_UNIT (TREE_TYPE (exp))))); -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

Re: CRT Unit
by Frank Heckenbach 06 Nov '99

06 Nov '99

"Ariel Bendersky" wrote: > Well, I finally got my GPC to work. It works fine, except that I > cannot use the CRT unit (in fact it's the only unit I have tried so far). > > Whenever I try to compile from rhide a code as simple as: > ********************* > Program prueba; > Uses crt; > begin > clrscr; > writeln('Hello'); > end. > ********************** > I get this error: > ********************** > Compiling: test.pas > ignoring AutoMake options `-g'; > (using `-g') > In function `program_Prueba': > test.pas(4) Error: undefined reference to `crt_clrscr' > There were some errors > ********************** Did you install the required libraries (see the comments in the CRT unit)? Which system do you use? In the case of Dos, you might need to use --autobuild because of the automake bugs. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: bug report
by Frank Heckenbach 06 Nov '99

06 Nov '99

Russ Whitaker wrote: > Under the prior release of GPC this simple program writes at 10,10 > compiled under latest snapshot it writes at 1,1 Right. This bug was introduced with my recent changes (19991023: CRT: don't initialize curses at the beginning of the program, but initialize it automatically when the first CRT routine is called (for BP compatiblity); new procedure CRTInit to explicitly initialize CRT which also sets some defaults (PCCharSet and update level) to more natural (and less BP compatible) values). To fix it, add the line "CRT_Check_WinChanged;" to the beginning of FastWrite in crt.pas. This will (among other things) do the automatic initialization if necessary. FastWrite seems to be the only routine where I forgot to do this. Thanks for the report, Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

bug report
by Russ Whitaker 06 Nov '99

06 Nov '99

hi Under the prior release of GPC this simple program writes at 10,10 compiled under latest snapshot it writes at 1,1 program tst; uses crt; var msg : string[ 80 ]; begin msg := 'ok for now'; fastwrite( msg, 10, 10, 16 ); end. thanks Russ <russwhit(a)mind.net>

1 0

CRT Unit
by Ariel Bendersky 06 Nov '99

06 Nov '99

Well, I finally got my GPC to work. It works fine, except that I cannot use the CRT unit (in fact it's the only unit I have tried so far). Whenever I try to compile from rhide a code as simple as: ********************* Program prueba; Uses crt; begin clrscr; writeln('Hello'); end. ********************** I get this error: ********************** Compiling: test.pas ignoring AutoMake options `-g'; (using `-g') In function `program_Prueba': test.pas(4) Error: undefined reference to `crt_clrscr' There were some errors ********************** Some idea on what's going on here? Thank you, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar ICQ 1914963

1 0

How to install bgi2grx under Linux
by Peter Sondhauss 05 Nov '99

05 Nov '99

Nicola Girardi wrote: > > > Hello all, > > hi dear, > i'm trying to get my old programs to work too, > but i can't compile my sources. > > please, could you tell me what i need to get to use > the bgi2grx unit? i mean, which pkgs to download and compile, > how to compile them (command line options) > > please help me! > > thanks in advance > > -- > Nicola Girardi a.k.a. nikke <girardi(at)keycomm.it> Dear Nicola, you need at least 3 packages: The grx graphics package, the bgi2grx package (translates Borland C graphics commands to grx) and bgi2grx (translates BP graph commands to Borland C). The grx package consists of 3 files: grx23.zip grx23fnt.zip grx23rme.fst the latter describes how to unpack, compile and install the package. bcc2grx and bgi2grx consist of 1 file each: bccgrx20.zip bgi2grx.zip Both grx and bcc2grx could be downloaded from every DJGPP distribution, which could be found on a great number of SimTel.NET mirrors. A list of these mirror sites could be found under FAQ no. 4 in http://agnes.dida.physik.uni-essen.de/~gnu-pascal/djgppfaq.html (For you cis.uniroma2.it would be interesting) There, you find the files in the folder: /pub/simtelnet/gnu/djgpp/v2tk/ bgi2grx could be found somewhere else, e.g. ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ Compilation of grx is straight forward and one can follow the instructions given in grx23rme.fst. I compiled a version with X11 support (makefile.x11). The only problem was, that I had to install some X11 include files, which were missed by the compiler. Compilation of bcc2grx was a bit more complicated. Instructions could be found in the readme file. First you have to tell make which system you are using and which version of grx (grx20 is right) by uncommenting some lines in the makedefs file. Furtheron add . (the pwd) to your PATH, if this is not the case already, or alternatively change "BIN2C = bin2c$(EX)" to "BIN2C = ./bin2c$(EX)" in the ./src/makefile. Otherwise make stops, because it cannot find the command bin2c. The second small problem was, that gcc couldn't find the X11 libraries, needed for the compilation of the examples. Adding e.g. -L/usr/X11R6/lib (or whereever your X11 libs are) to CFLAGS = ... in the ./test/makefile should solve it. bgi2grx contains only the Pascal unit bgi2grx.pas and needn't be compiled. I hope you and other people who want to install bgi2grx under Linux, find these hints somehow usefull. Don't hesitate to ask, if there are still some problems. Peter -- ___ ___ / _ \ \ Peter Sondhauss / / / \ / Erfurterstr. 32 / ___/_\ \ 07743 Jena /_/ \____/ Germany

2 1

RE: latest snapshot using 2.95
by Mason Ip 05 Nov '99

05 Nov '99

> From: Niels Kristian Bech Jensen[SMTP:nkbj@image.dk] > Sent: Thursday, November 04, 1999 10:10 PM > To: GNU Pascal Development > Subject: RE: latest snapshot using 2.95 > > On Fri, 5 Nov 1999, Dr A Olowofoyeku wrote: > > > On 4 Nov 99, at 10:15, Mason Ip wrote: > > > [...] > > > The gcc-2.95.x/install/* did mention that if you use the > > > "--enable-languages=" option, "make bootstrap" won't work. > > > > Where? > [mason] gcc-2.95.1/install/Build contains the following description : Building a native compiler [snip] If you used the flag --enable-languages=... to restrict the compilers to be built, only those you've actually enabled will be built. This will of course only build those runtime libraries, for which the particular compiler has been built. Please note, that re-defining LANGUAGES when calling `make bootstrap' _*does not*_ work anymore!

2 1

RE: latest snapshot using 2.95
by Mason Ip 05 Nov '99

05 Nov '99

> ../configure --enable-languages=pascal > make bootstrap > make install Be careful, you might screw up the original gcc binary. The gcc-2.95.x/install/* did mention that if you use the "--enable-languages=" option, "make bootstrap" won't work. So, in the above case, "make bootstrap" will generate a copy of "gcc" which would be different from the case when you "make bootstrap" without the "--enable-languages=" option. Before a fixed (and well tested) gpc INSTALL doc is released, I use the following work around. 1. build GCC without "--enable-languages" option. And make install. This does not build GPC. 2. backup the install-dir to a tar ball 3. build GPC with "--enable-languages=pascal" option. And make install. This build GPC with a "defective" GCC as by-product. Make Install. 4. restore the tar ball from step 2 back to the install-dir. This will over-write the "defective" GCC with the original good copy. > ---------- > From: Russ Whitaker[SMTP:russwhit@mind.net] > Sent: Wednesday, November 03, 1999 8:48 PM > To: gpc(a)gnu.de > Subject: latest snapshot using 2.95 > > Hi > into directory src: > downloaded latest gpc snapshot; > then downloaded gcc-2.95.2 > > tar -vxzf the two files > > found the directory structure of gcc-2.95 is different from 2.8. > so > mv gpc/p gcc-2.95.2/gcc > cd gcc-2.95.2/gcc > patch -s -p1 < p/diffs/gcc-2.95.diff > > next followed the recomendation in the gcc install literature > > cd ../.. > mkdir gcc > cd gcc > ../configure --enable-languages=pascal > make bootstrap > make install > > and you're done > > hopes this helps > Russ <russwhit(a)mind.net> >

3 2

problems with stacksize using bgi2grx under Linux
by Peter Sondhauss 04 Nov '99

04 Nov '99

Hello all, I'm trying to port my old programs written for Borland Pascal 7.0 to Linux (kernel v. 2.2.10). I have chosen gpc v. 19990510 and as an replacement for BP's graph unit the bgi2grx package. The compilation of my old source codes was no problem. But when I start a program using the bgi2grx unit, it ends earlier or later with a segmentation fault (SIGSEGV). The traceback shows, that an innocent library function like getch() seems to be responsible. This happens also with the example programs delivered with bgi2grx. I have found out, that these programs are even more unstable, if I compile them with libX11 insted of libvga. Furtheron I have observed, that if I move the mouse pointer over the X-window, where the graphical output occurs, the crash comes earlier. Funny, isn't it. In the DJGPP FAQ-list I have discovered, that the same happened already with bcc2grx under DOS. The reason was, that the stack was too small. There the problem could be solved by increasing the stack size. Now my questions: Is it possible, that insufficient stack size is the reason for my problems, too? If yes, is there a way how to increase stack size? Peter -- ___ ___ / _ \ \ Peter Sondhauss / / / \ / Erfurterstr. 32 / ___/_\ \ 07743 Jena /_/ \____/ Germany

2 1

attachment to bugreport: virker, alfaplot, syntaks
by Ole Osterby 04 Nov '99

04 Nov '99

program virker(ptfile); (* Virker skidtet ? *) const dim1 = 10; dim2 = 1; nc = 2; (* antal pkt til afrunding *) tk = 0.5; (* tykkelse af streger til omrids af kasser *) tp = 1.0; (* tykkelse af pilestreger *) pl = 10; (* lengde af kort pil *) spx = 3; (* pilespids *) spy = 1; (* pilespids *) pt = 12; (* punktstorrelse af skrift *) ht = 5; (* halv hojde af kasser *) tx = 4; (* offset af tekster *) ty = 1; (* offset af tekster *) #include "alfaplot" var CKX, CKY, CLX, CLY, RXA, RYA : vektor; x, y, x1, y1, x2, y2, x3, x4 : real; i : integer; #include "syntaks" procedure JA(xj, yj : real); begin MESSAGE('Ja', 2, xj, yj); end; (* JA *) procedure NEJ(xj, yj : real); begin MESSAGE('Nej', 3, xj, yj); end; (* NEJ *) begin rewrite(ptfile); START(0, 'PROBLEML\351SNINGSSKEMA', 23); ARX; x1 := x + 16; y1 := y - ht; RD(x, y, 33, 'Virker skidtet?', 15); NEJ(x+1, y+1); AR(x, y, x+pl+5, y, 1); x2 := x + 22; RD(x, y, 45, 'Har du pillet ved det?', 22); JA(x+1, y+1); x4 := x + pl*2 + (52 - 22)/2 - 2; AR(x, y, x4, y, 1); SQ(x, y, 22, 'TUMPE', 5); x3 := x - 11; x := x1; y := y1; JA(x+1, y-ht); AR(x, y, x, y-pl, 1); x := x2; y := y1; NEJ(x+1, y-ht); AR(x, y, x, y-pl, 1); x := x3; y := y1; AR(x, y, x, y-pl, 1); x := x1 - 17; y := y - ht; SQ(x, y, 34, 'Pil ikke ved det', 16); x := x2 - 21; y1 := y - ht; RD(x, y, 42, 'F\331r du problemer?', 20); JA(x+1, y+1); ARX; x4 := x; x := x + pl; JA(x-ht, y+1); AR(x, y, x-pl, y, 1); x := x + pl; RD(x, y, 52, 'Er der nogen der ved det?', 25); x := x1; y := y1; AR(x, y, x, y-pl*3-ht*8, 1); x := x - 23; y := y - ht; SQ(x, y, 47, 'INGEN PROBLEMER', 15); x := x1; y := y - ht; AR(x, y, x, y-pl, 1); x := x2; y := y1; NEJ(x+1, y-ht); AR(x, y, x, y-pl, 1); x := x3; y := y1; NEJ(x+1, y-ht); AR(x, y, x, y-pl, 1); y2 := y - pl - ht*3; x := x4; y := y1 + ht; AR(x, y, x, y2, 1); x := x2 - 13; y := y1 - ht - pl; SQ(x, y, 26, 'Sylt sagen', 10); x := x2 - 13; AR(x, y, x1 , y, 1); x := x3 - 12; SQ(x, y, 24, 'Glem det', 8); x := x3; y := y - ht; AR(x, y, x, y-pl*2-ht*5, 0); x2 := x2 - 11; AR(x, y, x1, y, 1); x := x4; y := y2; AR(x, y, x2+19, y, 1); x := x2 - 18; SQ(x, y, 37, 'STAKKELS DIG', 12); x := x2; y := y - ht; AR(x, y, x, y-pl, 1); x := x2 - 32; y := y - ht; JA(x-ht, y+1); AR(x, y, x1 , y, 1); x := x2 - 32; RD(x, y, 64, 'Kan du skyde skylden p\331 nogen?', 33); NEJ(x+1, y+1); AR(x, y, x4, y, 0); AR(x, y, x, y2, 1); ENDPL end. (* alfaplot version 4.1 10.7.1998 *) type matrix = array[0..dim2, 0..dim2] of real; vektor = array[-1..dim1] of real; tekst = packed array[1..60] of char; xyzrec = record xb, xe, yb, ye, zb, ze, dx, dy, dz, vx, vy, vz : real end; var ptfile : text; xyzvar : xyzrec; global : record overskrift, xticks, yticks, zticks : integer; heading, intxax, intyax, intzax, bld, itl,cross,box : boolean; xxxdisp, xxxmax, xxxorig, xxxscal, xsize, ysize, yyydisp, yyymax, yyyorig, yyyscal : real end; procedure BEGINPL(i : integer); begin with global do begin heading := (i > 0); bld := false; itl := false; intxax := false; intyax := false; intzax := false; xticks := 1; yticks := 1; zticks := 1; cross := false; overskrift := 812; xsize := 21.0; ysize := 29.5 end; writeln(ptfile, '%! qmsplot version 4.1'); writeln(ptfile, '/pt {0.24 mul} def') end; (* BEGINPL *) procedure AREA(x, y : real); var a : timestamp; z : real; procedure outp(t : integer); begin if t < 10 then write(ptfile, '0', t:1) else write(ptfile, t:2) end; (* outp *) begin z := 300/2.54; with global do begin xxxdisp := (xsize - x)/2*z; xxxmax := x*z; yyydisp := (ysize - y)/2*z; yyymax := y*z; if heading then begin writeln(ptfile, '/Times-Roman findfont'); writeln(ptfile, '8 scalefont'); writeln(ptfile, 'setfont'); gettimestamp(a); writeln(ptfile, ' 17 ', overskrift:4, ' moveto'); write(ptfile, '(', a.day:2,'.', a.month:2, '.'); outp(a.year); writeln(ptfile, ') show'); writeln(ptfile, ' 62 ', overskrift:4, ' moveto'); write(ptfile, '(', a.hour:2, ':'); outp(a.minute); write(ptfile, ':'); outp(a.second); writeln(ptfile, ') show') end; writeln(ptfile, '/Times-Roman findfont'); writeln(ptfile, '12 scalefont'); writeln(ptfile, 'setfont'); end end; (* AREA *) procedure BOLD(b : boolean); begin global.bld := b end; (* BOLD *) procedure ITALIC(b : boolean); begin global.itl := b end; (* ITALIC *) procedure TIMES(i : real); begin with global do begin write(ptfile, '/Times-'); if bld then write(ptfile, 'Bold'); if itl then write(ptfile, 'Italic'); if not(bld or itl) then write(ptfile, 'Roman'); writeln(ptfile, ' findfont ', i:5:1, ' scalefont setfont') end end; (* TIMES *) procedure TIM(i : real); begin with global do begin write(ptfile, '/Tim'); writeln(ptfile, ' findfont ', i:5:1, ' scalefont setfont') end end; (* TIM *) procedure HELVETICA(i : integer); begin with global do begin write(ptfile, '/Helvetica'); if bld then write(ptfile, '-Bold') else if itl then write(ptfile, '-'); if itl then write(ptfile, 'Oblique'); writeln(ptfile, ' findfont ', i:4, ' scalefont setfont') end end; (* HELVETICA *) procedure COURIER(i : integer); begin with global do begin write(ptfile, '/Courier'); if bld then write(ptfile, '-Bold') else if itl then write(ptfile, '-'); if itl then write(ptfile, 'Oblique'); writeln(ptfile, ' findfont ', i:4, ' scalefont setfont') end end; (* COURIER *) procedure RGB(r, g, b : real); begin writeln(ptfile, r:7:3, g:7:3, b:7:3, ' setrgbcolor'); end; (* RGB *) procedure CMYK(c, m, y, k : real); begin writeln(ptfile, c:7:3, m:7:3, y:7:3, k:7:3, ' setcmykcolor'); end; (* CMYK *) procedure HSB(h, s, b : real); begin writeln(ptfile, h:7:3, s:7:3, b:7:3, ' sethsbcolor'); end; (* HSB *) procedure INTXAX(b : boolean); begin global.intxax := b end; (* INTXAX *) procedure INTYAX(b : boolean); begin global.intyax := b end; (* INTYAX *) procedure INTZAX(b : boolean); begin global.intzax := b end; (* INTZAX *) procedure XTICKS(i : integer); begin global.xticks := i end; (* XTICKS *) procedure YTICKS(i : integer); begin global.yticks := i end; (* YTICKS *) procedure ZTICKS(i : integer); begin global.zticks := i end; (* ZTICKS *) procedure CROSS(b : boolean); begin global.cross := b end; (* CROSS *) procedure DASH; begin writeln(ptfile, '[4 4] 0 setdash ') end; (* DASH *) procedure BOX(b : boolean); begin global.box := b end; (* BOX *) procedure MOVE(x, y : real); var ix, iy : integer; begin with global do begin ix := round((x - xxxorig)*xxxscal + xxxdisp); iy := round((y - yyyorig)*yyyscal + yyydisp); end; if ix < 0 then ix := 1; if ix > 9999 then ix := 9999; if iy < 0 then iy := 1; if iy > 9999 then iy := 9999; writeln(ptfile, ix:5, ' pt ', iy:5, ' pt moveto') end; (* MOVE *) procedure CONNPT(x, y : real); var ix, iy : integer; begin with global do begin ix := round((x - xxxorig)*xxxscal + xxxdisp); iy := round((y - yyyorig)*yyyscal + yyydisp); end; if ix < 0 then ix := 1; if ix > 9999 then ix := 9999; if iy < 0 then iy := 1; if iy > 9999 then iy := 9999; writeln(ptfile, ix:5, ' pt ', iy:5, ' pt lineto') end; (* CONNPT *) procedure RLVEC(xf, yf, xt, yt, width : real); begin if width < 0.01 then width := 0.01; if width > 50 then width := 50; writeln(ptfile, 'newpath'); MOVE(xf, yf); CONNPT(xt, yt); writeln(ptfile, width:6:2, ' setlinewidth stroke') end; (* RLVEC *) procedure MESSAGE(t : tekst; l : integer; x, y : real); begin MOVE(x, y); if l > 0 then writeln(ptfile, '(', t:l, ') show') end; (* MESSAGE *) procedure MESS(t : tekst; l : integer); begin if l > 0 then writeln(ptfile, '(', t:l, ') show') end; (* MESS *) procedure INTNO(i, l : integer; x, y : real); begin MOVE(x, y); if l > 0 then writeln(ptfile, '(', i:l, ') show') end; (* INTNO *) procedure INT(i, l : integer); begin if l > 0 then writeln(ptfile, '(', i:l, ') show') end; (* INT *) procedure REALNO(r : real; l, m : integer; x, y : real); begin MOVE(x,y); if l > 0 then writeln(ptfile, '(', r:l:m, ') show') end; (* REALNO *) procedure REA(r : real; l, m : integer); begin if l > 0 then writeln(ptfile, '(', r:l:m, ') show') end; (* REA *) procedure KOORD(xb, dx, xe, yb, dy, ye : real); var x, y, xa, ya, xt, yt, yy : real; begin with global do begin xxxorig := xb; xxxscal := xxxmax/(xe - xb); yyyorig := yb; yyyscal := yyymax/(ye - yb); xt := 40/yyyscal; yt := 40/xxxscal; end; if global.cross then ya := 0 else ya := yb; if dx <= xe - xb then RLVEC(xb, ya, xe, ya, 1); yy := ya - xt*2.5; if dx < xe - xb then begin y := ya - xt; x := xb/dx; if x < 0 then x := - round(-x - 0.4999)*dx else if x < 1000000 then x := round(x + 0.5)*dx; while x <= xe do begin RLVEC(x, ya, x, y, 0.5); if global.intxax then INTNO(round(x), 5, x-yt*1.5, yy) else if dx > 0.08 then REALNO(x, 5, 1, x-yt, yy) else REALNO(x, 7, 3, x-yt*1.5, yy); x := x + dx end; if global.xticks > 1 then begin dx := dx/global.xticks; x := xb/dx; y := ya - xt*0.7; if x < 0 then x := - round(-x - 0.49999)*dx else x := round(x + 0.5)*dx; while x <= xe do begin RLVEC(x, ya, x, y, 0.2); x := x + dx end end end; if global.cross then xa := 0 else xa := xb; yy := xa - yt*4; if dy <= ye - yb then RLVEC(xa, yb, xa, ye, 1); if dy < ye - yb then begin x := xa - yt; y := yb/dy; if y < 0 then y := - round(-y - 0.4999)*dy else y := round(y + 0.5)*dy; while y <= ye do begin RLVEC(xa, y, x, y, 0.5); if global.intyax then INTNO(round(y), 5, yy, y) else if dy > 0.08 then REALNO(y, 5, 1, yy, y) else REALNO(y, 7, 3, yy, y); y := y + dy end; if global.yticks > 1 then begin dy := dy/global.yticks; y := yb/dy; x := xa - yt*0.7; if y < 0 then y := - round(-y - 0.49999)*dy else y := round(y + 0.5)*dy; while y <= ye do begin RLVEC(xa, y, x, y, 0.2); y := y + dy end end end; end; (* KOORD *) procedure CURVE(var XX, YY : vektor; ib, ie : integer; width : real); var i : integer; begin writeln(ptfile, 'newpath'); MOVE(XX[ib], YY[ib]); for i := ib+1 to ie do CONNPT(XX[i], YY[i]); if width = 0 then writeln(ptfile, ' closepath fill'); if width < 0 then begin write(ptfile, ' closepath '); width := - width end; if width > 50 then width := 50; if width > 0 then writeln(ptfile, width:5:2, ' setlinewidth stroke ') end; (* CURVE *) procedure MARK(x, y, mm, width : real; ind : integer); var xt, yt : real; begin xt := 150/25.4*mm/global.xxxscal; yt := 150/25.4*mm/global.yyyscal; case ind of 0 : begin (* 0 = SQUARE *) RLVEC(x-xt, y-yt, x+xt, y-yt, width); RLVEC(x+xt, y+yt, x+xt, y-yt, width); RLVEC(x+xt, y+yt, x-xt, y+yt, width); RLVEC(x-xt, y-yt, x-xt, y+yt, width) end; 1 : begin (* 1 = NABLA *) RLVEC(x-xt, y+yt, x, y-yt, width); RLVEC(x, y-yt, x+xt, y+yt, width); RLVEC(x+xt, y+yt, x-xt, y+yt, width) end; 2 : begin (* 2 = TRI *) RLVEC(x-xt, y-yt, x, y+yt, width); RLVEC(x, y+yt, x+xt, y-yt, width); RLVEC(x+xt, y-yt, x-xt, y-yt, width) end; 3 : begin (* 3 = PLUS *) RLVEC(x-xt, y, x+xt, y, width); RLVEC(x, y-yt, x, y+yt, width) end; 4 : begin (* 4 = KRYDS *) RLVEC(x-xt, y-yt, x+xt, y+yt, width); RLVEC(x+xt, y-yt, x-xt, y+yt, width) end; otherwise begin (* 5 = DIAMOND *) RLVEC(x-xt, y, x, y+yt, width); RLVEC(x, y+yt, x+xt, y, width); RLVEC(x+xt, y, x, y-yt, width); RLVEC(x, y-yt, x-xt, y, width) end end end; (* MARK *) procedure SQUARE(x, y, width : real); begin MARK(x, y, 3, width, 0) end; (* SQUARE *) procedure NABLA(x, y, width : real); begin MARK(x, y, 3, width, 1) end; (* NABLA *) procedure TRI(x, y, width : real); begin MARK(x, y, 3, width, 2) end; (* TRI *) procedure PLUS(x, y, width : real); begin MARK(x, y, 3, width, 3) end; (* PLUS *) procedure KRYDS(x, y, width : real); begin MARK(x, y, 3, width, 4) end; (* KRYDS *) procedure DIAMOND(x, y, width : real); begin MARK(x, y, 3, width, 5) end; (* DIAMOND *) procedure DOT(x, y, mm : real); begin RLVEC(x, y, x+mm*300/25.4/global.xxxscal, y, mm*72/25.4) end; (* DOT *) procedure SCALE(var xyzvar : xyzrec; var FUNC : matrix; var XX, YY : vektor; ib, ie, jb, je : integer); var min, max, v : real; i, j : integer; begin min := FUNC[ib, jb]; max := min; for i := ib to ie do for j := jb to je do begin v := FUNC[i,j]; if min > v then min := v; if max < v then max := v end; with xyzvar do begin xb := XX[ib]; xe := XX[ie]; yb := YY[jb]; ye := YY[je]; zb := min; ze := max; dx := 1; dy := 1; dz := 1; if (xe - xb) < 1.5 then dx := 0.1; if (ye - yb) < 1.5 then dy := 0.1; if (ze - zb) < 1.5 then dz := 0.1; vx := xe*2 - xb; vy := yb*2 - ye; vz := ze*2 - zb end end; (* SCALE *) procedure KOORD3D(xyzvar : xyzrec); var x, xx, x1, x2, xt, xxb, xxe, z, y, yy, y1, y2, yt, yr, zzb, zze : real; begin with xyzvar do with global do begin if vy > yb then vy := yb*2 - ye; yr := (yb - vy)/(ye - vy); xxb := xb; xxe := xe; zzb := zb; zze := ze; if vz > ze then zze := (ze - vz)*yr + vz; if vz < zb then zzb := (zb - vz)*yr + vz; if vx > xe then xxe := (xe - vx)*yr + vx; if vx < xb then xxb := (xb - vx)*yr + vx; xxxorig := xxb; xxxscal := xxxmax/(xxe - xxb); yt := 40/xxxscal; yyyorig := zzb; yyyscal := yyymax/(zze - zzb); xt := 40/yyyscal; if vz < zb then y := ze else begin y := zb; xt := - xt end; yy := y + xt; y1 := (yy - y)*2.5 + y; if dx <= xe - xb then begin RLVEC(xb, y, xe, y, 1); x := xb/dx; if x < 0 then x := - round(-x - 0.49999)*dx else x := round(x + 0.49999)*dx; while x <= xe do begin RLVEC(x, y, x, yy, 0.5); if global.intxax then INTNO(round(x), 5, x-yt*1.5, y1) else if dx > 0.08 then REALNO(x, 5, 1, x-yt, y1) else REALNO(x, 7, 3, x-yt*1.5, y1); x := x + dx end; if global.xticks > 1 then begin dx := dx/global.xticks; x := xb/dx; yy := y + xt*0.7; if x < 0 then x := - round(-x - 0.49999)*dx else x := round(x + 0.5)*dx; while x <= xe do begin RLVEC(x, y, x, yy, 0.2); x := x + dx end end end; if dz <= ze - zb then begin if vx >= xb then begin x := xb; yr := 1 end else x := xxb; y1 := (zb - vz)*yr + vz; y2 := (ze - vz)*yr + vz; RLVEC(x, y1, x, y2, 1); x1 := x - yt*4; z := zb/dz; if z < 0 then z := - round(-z - 0.49999)*dz else z := round(z + 0.49999)*dz; yy := (y2 - y1)*dz/(ze - zb); x2 := z; y := (z - vz)*yr + vz; while x2 <= ze do begin RLVEC(x-yt, y, x, y, 0.5); if global.intzax then INTNO(round(x2), 5, x1, y) else if dz > 0.08 then REALNO(x2, 5, 1, x1, y) else REALNO(x2, 7, 3, x1, y); x2 := x2 + dz; y := y + yy end; y2 := y - yy; if global.zticks > 1 then begin dz := dz/global.zticks; yt := yt*0.7; yy := yy/global.zticks; z := zb/dz; if z < 0 then z := - round(-z - 0.49999)*dz else z := round(z + 0.5)*dz; y := (z - vz)*yr + vz; while y < y2 do begin RLVEC(x-yt, y, x, y, 0.2); y := y + yy end end end; if dy <= ye - yb then begin if ((vz-zb)*(vz-ze) <= 0) and ((vx-xb)*(vx-xe) <= 0) then else begin if vz > zb then y1 := zb else y1 := ze; y2 := (y1 - vz)*(yb - vy)/(ye - vy) + vz; xt := 40/yyyscal; yt := 40/xxxscal; if vx > xb then begin x1 := xe; x2 := xxe; xt := 0; xx := yt*1.5 end else begin x1 := xb; x2 := xxb; xt := -xt*1.1; yt := -yt; xx := yt*3 end; RLVEC(x1, y1, x2, y2, 1); yy := yb/dy; if yy < 0 then yy := - round(-yy - 0.49999)*dy else yy := round(yy + 0.49999)*dy; while yy <= ye do begin yr := (yb - vy)/(yy - vy); x := (x1 - vx)*yr + vx; y := (y1 - vz)*yr + vz; RLVEC(x, y, x+yt, y, 0.5); if intyax then INTNO(round(yy), 5, x+xx, y+xt) else if dy > 0.08 then REALNO(yy, 5, 1, x+xx, y+xt) else REALNO(yy, 7, 3, x+xx, y+xt); yy := yy + dy end; if yticks > 1 then begin dy := dy/yticks; yy := yb/dy; yt := yt*0.7; if yy < 0 then yy := - round(-yy - 0.49999)*dy else yy := round(yy + 0.5)*dy; while yy <= ye do begin yr := (yb - vy)/(yy - vy); x := (x1 - vx)*yr + vx; y := (y1 - vz)*yr + vz; RLVEC(x, y, x+yt, y, 0.2); yy := yy + dy end end end end end end; (* KOORD3D *) procedure FLADE(xyzvar : xyzrec; var FUNC : matrix; var XX, YY : vektor; ib, ie, jb, je, code : integer; width : real); var ZX, ZY : matrix; X, Y : vektor; yr : real; i, i1, i2, j : integer; flag : boolean; begin with xyzvar do begin for j := jb to je do begin yr := YY[j] - vy; yr := (yb - vy)/yr; for i := ib to ie do begin X[i] := (XX[i] - vx)*yr + vx; ZX[i,j] := X[i]; Y[i] := (FUNC[i,j] - vz)*yr + vz; ZY[i,j] := Y[i] end end; if (code mod 4) <> 2 then begin i1 := ib; i2 := ie; flag := false; if (code mod 8) >= 4 then begin flag := true; if vx > xe then i2 := i2 + 1 else if vx < xb then i1 := i1 - 1 end; for j := jb to je do begin yr := YY[j] - vy; yr := (yb - vy)/yr; for i := ib to ie do begin X[i] := ZX[i,j]; Y[i] := ZY[i,j] end; X[i1] := ZX[ib,j]; X[i2] := ZX[ie,j]; if flag then begin if vx > xe then Y[i2] := (zb - vz)*yr + vz else if vx < xb then Y[i1] := (zb - vz)*yr + vz end; CURVE(X, Y, i1, i2, width) end end; if vz < zb then yr := ze else yr := zb; if (code mod 4) >= 2 then begin flag := false; i1 := jb; if code >= 8 then begin flag := true; i1 := jb - 1; Y[i1] := yr end; for i := ib to ie do begin for j := jb to je do begin X[j] := ZX[i,j]; Y[j] := ZY[i,j] end; if flag then X[i1] := X[jb]; CURVE(X, Y, i1, je, width) end end end end; (* FLADE *) procedure ENDPL; begin writeln(ptfile, 'showpage') end; (* ENDPL *) (* syntaks version 1.0 15.10.99 *) procedure START(ib : integer; txt : tekst; ltx : integer); var dx, cdx, sdx : real; is : integer; begin dx := arctan(1)*4/nc; CKX[0] := 0; CKY[0] := -ht; cdx := cos(dx); sdx := sin(dx); for is := 1 to nc do begin CKX[is] := CKX[is-1]*cdx - CKY[is-1]*sdx; CKY[is] := CKY[is-1]*cdx + CKX[is-1]*sdx end; BEGINPL(ib); AREA(21, 30); x := 20; KOORD(0, 220, 210, 0, 310, 300); y := 270; TIM(pt); MESSAGE(txt, ltx, x, y); y := y - 15; end; (* START *) procedure LEFT(xp, yp : real); var ip : integer; begin for ip := 0 to nc do begin CLX[ip] := ht - CKX[ip] + xp; CLY[ip] := CKY[ip] + yp end; CURVE(CLX, CLY, 0, nc, tk) end; (* LEFT *) procedure RIGHT(xp, yp : real); var ip : integer; begin for ip := 0 to nc do begin CLX[ip] := CKX[ip] - ht + xp; CLY[ip] := CKY[ip] + yp end; CURVE(CLX, CLY, 0, nc, tk) end; (* RIGHT *) procedure RD(var xx : real; yy, ls : real; txt : tekst; ltx : integer); var x2 : real; begin LEFT(xx, yy); x2 := xx + ls; RLVEC(xx+ht, yy+ht, x2-ht, yy+ht, tk); RLVEC(xx+ht, yy-ht, x2-ht, yy-ht, tk); MESSAGE(txt, ltx, xx + tx, yy - ty); xx := x2; RIGHT(xx, yy) end; (* RD *) procedure RECTANGLE(x1, y1, x2, y2, y3 : real); var ir : integer; begin for ir := 0 to 5 do begin RXA[ir] := x1; RYA[ir] := y1 end; RXA[2] := x2; RXA[3] := x2; RYA[1] := y2; RYA[2] := y2; RYA[3] := y3; RYA[4] := y3; CURVE(RXA, RYA, 0, 5, tk) end; (* RECTANGLE *) procedure SQ(var xx : real; yy, ls : real; txt : tekst; ltx : integer); begin RECTANGLE(xx, yy, xx+ls, yy+ht, yy-ht); MESSAGE(txt, ltx, xx + tx, yy - ty); xx := xx + ls end; (*SQ *) procedure AR(var xf, yf : real; xt, yt : real; pil : integer); var xa, xb, ya, yb : real; begin RLVEC(xf, yf, xt, yt, tp); if pil = 1 then begin if xt <> xf then begin if xt > xf then xa := xt - spx else xa := xt + spx; ya := yt + spy; yb := yt - spy; xb := xa end else begin if yt > yf then ya := yt - spx else ya := yt + spx; xa := xt + spy; xb := xt - spy; yb := ya end; RLVEC(xa, ya, xt, yt, tp); RLVEC(xb, yb, xt, yt, tp); end; xf := xt; yf := yt end; (* AR *) procedure ARX; begin AR(x, y, x+pl, y, 1) end; (* ARX *)

1 0

bugreport
by Ole Osterby 04 Nov '99

04 Nov '99

DAIMI, 4.11.1999 Dear sirs For a little over a year I have been using the gpc compiler with a reasonable degree of success. Yesterday I had the opportunity to test the latest (according to our systems programmer, Benedict Lofstedt) release of gpc. This gave rise to four comments: 1. The attached program `arraytest' checks subrange types and subscripted variables. There seems to be no check of exceeding the limits. See the attached output which is identical for the old and new version of gpc. 2. The attached program `arraytest2' checks what happens to the surroundings. When one assigns values outside the subscript range. I have declared var X, Y, Z : vektor and have exceeded the subscript range in Y. The latest release of gpc destroys the contents of Z whereas the old one destroys X 3. Program `virker' which includes `alfaplot' and `syntaks' is sent by separate mail. The program works well with the old gpc, but with the new release I get: 10> gpc virker.p In file included from virker.p:17: alfaplot: In function `Mark': alfaplot:299: Internal compiler error in `emit_library_call_value', at calls.c:3198 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. 4. If one omits the semicolon in line 63 (an error, I know, but one that did occur) of `syntaks', the second line of procedure AR var xa, xb, ya, yb : real <-- the old compiler produces so many lines of diagnostics, that I had a hard time finding the first (and only important) one. This is just one example, that gpc has problems recovering after an error. program arraytest(output); (* test of overflow in subrange and array-index. gpc allows the following program, pc does not *) type small = 0..100; vektor = array [small] of integer; var X, Y : vektor; A : array [0..5, 0..5] of integer; i, n : small; begin n := 98; for i := 1 to 7 do begin n := n + 1; X[n] := n+6; A[i,n] := i + n; writeln(n:4, X[n]:4, A[i,n]:5) end end. 4> gpc arraytest.p 5> a.out 99 105 100 100 106 102 101 107 104 102 108 106 103 109 108 104 110 110 105 111 112 program arraytest2(output); (* test of consequenses of overflow in array-index *) type small = 0..5; vektor = array [small] of integer; var X, Y, Z : vektor; i, n : small; begin for i := 0 to 5 do begin X[i] := i+10; Y[i] := i+30; Z[i] := i+50 end; for i := 0 to 5 do writeln(i:3, X[i]:5, Y[i]:5, Z[i]:5); for i := 1 to 10 do Y[i] := i+100; for i := 0 to 5 do writeln(i:3, X[i]:5, Y[i]:5, Z[i]:5) end. 7> gpc arraytest2.p 8> a.out 0 10 30 50 1 11 31 51 2 12 32 52 3 13 33 53 4 14 34 54 5 15 35 55 0 10 30 106 output using the new release of gpc 1 11 101 107 2 12 102 108 3 13 103 109 4 14 104 110 5 15 105 55 10> a.out 0 10 30 50 1 11 31 51 2 12 32 52 3 13 33 53 4 14 34 54 5 15 35 55 0 106 30 50 output using the old one 1 107 101 51 2 108 102 52 3 109 103 53 4 110 104 54 5 15 105 55 Sincerely Ole Osterby Department of Computer Science Aarhus University

1 0

latest snapshot using 2.95
by Russ Whitaker 04 Nov '99

04 Nov '99

Hi into directory src: downloaded latest gpc snapshot; then downloaded gcc-2.95.2 tar -vxzf the two files found the directory structure of gcc-2.95 is different from 2.8. so mv gpc/p gcc-2.95.2/gcc cd gcc-2.95.2/gcc patch -s -p1 < p/diffs/gcc-2.95.diff next followed the recomendation in the gcc install literature cd ../.. mkdir gcc cd gcc ../configure --enable-languages=pascal make bootstrap make install and you're done hopes this helps Russ <russwhit(a)mind.net>

1 0

Re: BGI, BGI2GRX and... What Else?
by Frank Heckenbach 04 Nov '99

04 Nov '99

Sven Hilscher wrote: > > girardi@ux(tty2)/home/girardi/nnibbles# gpc -g --automake -o nnibbles > > main.pas flib.o: > > you have to use the -l switches for the librarys > > gpc -g -- automake main.pas -onnibbles flib.o -lbcc2 -lgrx20 I think under Linux, you need some more libs, in particular -lvga, and depending on how your svgalib was built, perhaps some more libs (with my version: -ljpeg, -ltiff and -lz). (And if you want the X11 version, you need -lgrx20X and -lX11 instead.) Rather than giving them on the command line each time you compile a program, you can also insert `$L' statements into the graph unit (like we do for the other units that use libraries -- but in the case of the graph unit, we are not permitted to distribute a modified version): {$ifdef MSDOS} {$L bcc2,grx20} {$elif defined (X11)} {$L bcc2,grx20X,X11} {$else} {$L bcc2,grx20,vga,jpeg,tiff,z} {$endif} Then you should be able to just do `gpc -g --automake -o nnibbles main.pas flib.o' (add `-DX11' if you want the X11 version). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 2

`make LANGUAGES=pascal' vs. `./configure --enable-languages=pascal'.
by Niels Kristian Bech Jensen 03 Nov '99

03 Nov '99

I must admit that I haven't tried `make LANGUAGES=pascal'. I only followed the GCC documentation. This is the relevant part of gcc-2.95.2/install/BUILD: If you used the flag --enable-languages=... to restrict the compilers to be built, only those you've actually enabled will be built. This will of course only build those runtime libraries, for which the particular compiler has been built. Please note, that re-defining LANGUAGES when calling `make bootstrap' _*does not*_ work anymore! -- Niels Kristian Bech Jensen -- nkbj(a)image.dk -- http://www.image.dk/~nkbj/ ----------->> Stop software piracy --- use free software! <<-----------

2 1

Re: BGI, BGI2GRX and... What Else?
by Peter Gerwinski 03 Nov '99

03 Nov '99

Hello, Nicola! Better reply to the list rather than just to my person. Nicola Girardi wrote: > ok, just a thing: i found BGI2GRX (on agnes) but i'm looking for > GRX. if you could tell me where to get it, it'd be simpler Just search for DJGPP (or look at http://www.delorie.com/djgpp/ for an FTP server). GRX is in the `v2tk' subdirectory. While DJGPP is a programming environment for DOS, GRX is a portable library that works well under Linux and AFAIK under other Unices as well. Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

1 0

BGI, BGI2GRX and... What Else?
by Nicola Girardi 03 Nov '99

03 Nov '99

hi all in the mailing list ;) i'm here to ask you some questions because there's a thing i cannot deal with. i've written a cool little game for DOS with BGI drivers. (it's a kinda GNibbles) the thing is that i've done it for DOS & BGI just because i didn't know how to deal with graphics under Linux and *possibly* the X Window System. as a beginner, i'd like to get something that can compile the program under linux wrapping BGI calls to Svgalib calls or something similar. and i heard of BGI2GRX, but it's not clear for me what it really does. my aim is to deal with graphics first outside X, then i'd like to use X and Gtk (wrapping C functions with appropriate definitions) ... please light my way ... thanks in advance again, -- Nicola Girardi a.k.a. nikke <girardi(at)keycomm.it>

3 3

no subject (file transmission)
by S. Achterop IWI-120 3932 03 Nov '99

03 Nov '99

Hello, Building the new gpc-19991030-snapshot with gcc-2.95.2 on HPUX-10.20 regrettably failed. The build was done in a different objdir then srddir, as adviced by gcc. The configuration as described by config.status : #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: ../gcc-2.95.2/configure --with-gcc-version-trigger=/wing3/home1/users/sietse/gcc-2.95.2/gcc/version.c --host=hppa1.1-hp-hpux10.20 --prefix=/opt/gcc-2.95.2 --enable-shared --with-gnu-as --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --norecursion # using "mh-frag" and "mt-frag" FIRST a small problem 1 Using the option --with-as=/usr/local/bin/gas with configure is NOT obeyed by xgcp. xgpc also does not use $PATH of the caller of the make which would be a symbolic link to gas. And here the MAIN problem, which (I guess) is another example of the known HPUX bug as triggered with "p/test/knownbugs/sietse1u.pas". 2 The "gmake bootstrap" ends in: ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -O2 -g -O2 -DRTS_RELEASE_STRING="'__GPC_RTS_VERSION_`cat /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/rts_release`__'" -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts --automake /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/files.pas /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/string2.pas: In function `Getenv': /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/string2.pas:193: internal error--unrecognizable insn: (insn 15 14 17 (set (zero_extract:SI (reg:SI 97) (const_int 32 [0x20]) (const_int 0 [0x0])) (reg:SI 98)) -1 (insn_list 12 (insn_list 14 (nil))) (expr_list:REG_DEAD (reg:SI 98) (nil))) gpc1: ../.././xgpc exited with status 1 /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/files.pas:30: module/unit `string2' could not be compiled make[3]: *** [files.o] Error 1 make[3]: Leaving directory `/wing3/home1/users/sietse/hpux-gcc/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/wing3/home1/users/sietse/hpux-gcc/gcc' make[1]: *** [bootstrap] Error 2 make[1]: Leaving directory `/wing3/home1/users/sietse/hpux-gcc/gcc' make: *** [bootstrap] Error 2 It looks like the knownbug from "p/test/knownbugs/sietse1u.pas". Locally defining the TString-type in string2.pas as was done earlier in filename.pas helps. BUT NOW: /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/filename.pas: In function `Gettempdirectory': /wing3/home1/users/sietse/gcc-2.95.2/gcc/p/rts/filename.pas:513: internal error--unrecognizable insn: (insn 54 53 56 (set (zero_extract:SI (reg:SI 111) (const_int 32 [0x20]) (const_int 0 [0x0])) (reg:SI 112)) -1 (insn_list 51 (insn_list 53 (nil))) (nil)) This can be "removed" by removing the complete if-statement from Gettempdirectory. Simplifying the boolean expressing also helps. BUT NOW such an error shows up in the function BraceExpand. So something's wrong on HPUX, and it is more than suggested from the earlier bug exposed in knownbugs/sietse1u.pas I'm not familiar with the internals of gcc/gpc and I don't now how to proceed next. But hopefully this description makes some sense. Sietse Achterop P.S. The GNU-pascal side still suggests that mail for the mailing list is to be send to gpc(a)fut.fi instead of gpc(a)gnu.de.

1 0

Re: `make LANGUAGES=pascal' vs. `./configure --enable-languages=pascal'.
by Frank Heckenbach 03 Nov '99

03 Nov '99

"Dr A Olowofoyeku" wrote: > On 3 Nov 99, at 9:53, Niels Kristian Bech Jensen <nkbj(a)image.dk> wrote: > > > I must admit that I haven't tried `make LANGUAGES=pascal'. I only followed > > the GCC documentation. This is the relevant part of > > gcc-2.95.2/install/BUILD: > > > > If you used the flag --enable-languages=... to restrict the compilers > > to be built, only those you've actually enabled will be built. This > > will of course only build those runtime libraries, for which the > > particular compiler has been built. Please note, that re-defining > > LANGUAGES when calling `make bootstrap' _*does not*_ work anymore! > > Well, I have just been building the latest snapshot today (under > Cygwin32) - and 'make LANGUAGES=pascal' works. > > Perhaps the change is prospective? I don't know since I haven't done much with gcc-2.95, but "does not work" can simply mean that the parameter is ignored and all languages installed will be built -- including Pascal, of course, when it was present at configure time. Anyway, someone (who knows gcc-2.95 better than I do) should probably amend the instructions in GPC's INSTALL file according to gcc-2.95's new installation procedure... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

RE: New GPC snapshot
by Mason Ip 03 Nov '99

03 Nov '99

Thanks, it works. I must admit that I did not read every thing under gcc-2.95.1/install/*; I only read gcc-2.95.1/p/INSTALL which says Â“make languages=pascalÂ”. I think the latter (p/INSTALL) should be updated to match gcc-2.95.1/install/*. ---------- From: Niels Kristian Bech Jensen [SMTP:nkbj@image.dk] <mailto:[SMTP:nkbj@image.dk]> Sent: Tuesday, November 02, 1999 10:08 PM To: Mason Ip Cc: 'gpc(a)hut.fi' Subject: RE: New GPC snapshot make LANGUAGES=<xxx> is not supported anymore. You have to use the --enable-languages=<xxx> flag when you run configure. In you case: ./configure --enable-languages=pascal Read the documentation in the install directory in the gcc-2.95.1 source.

1 0

New GPC snapshot
by Peter Gerwinski 03 Nov '99

03 Nov '99

Hello, folks, a new GPC snapshot is available: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19991030.tar.gz As usual: Source only; nothing guaranteed. Main changes since the last snapshot (19990813): * Works with gcc-2.95.x. * In preparation for a integration into GCC, most patches to the GCC backend have been obsoleted and removed. The remaining ones will either vanish, too, or be integrated into GCC. * The set-handling routines have been re-written. Set operations are handled in the RTS and should be more stable now. * Some problems with packed arrays on big-endian machines have been solved. * `-dY' is now `--debug-source'. * New options `--[no-]transparent-file-names'. * ... and much more. Have fun, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

2 1

RE: New GPC snapshot
by Mason Ip 03 Nov '99

03 Nov '99

Just tried it but could not compile on 32-bit Sparc Solaris 7. I used GCC-2.95.1 src (from www.sunfreeware.com), merged gpc/p to gcc-2.95.1, and patched GCC with p/diffs/gcc-2.95.1.diff. Upon Â“make LANGUAGES=pascalÂ”, it failed and complained of not knowing how to make target Â‘pascalÂ’. Note the failing dir was gcc-2.95.1/gcc/. I expected Â“makeÂ” should cd to ../p and Â“make pascalÂ” there. Anyone know how to fix it? gcc-2.95.1> make LANGUAGES=pascal make all-recursive Making all in intl Making all in lib Making all in makeinfo (cd intl && make all) make: Fatal error: Don't know how to make target `pascal' Current working directory /export/home/mip/tmp/gcc-2.95.1/gcc *** Error code 1 make: Fatal error: Command failed for target `all-gcc' gcc-2.95.1> ---------- From: Peter Gerwinski [SMTP:peter@gerwinski.de] Sent: Monday, November 01, 1999 12:47 PM To: gpc-announce(a)gnu.de Subject: New GPC snapshot Hello, folks, a new GPC snapshot is available: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19991030.tar.gz As usual: Source only; nothing guaranteed. Main changes since the last snapshot (19990813): * Works with gcc-2.95.x. * In preparation for a integration into GCC, most patches to the GCC backend have been obsoleted and removed. The remaining ones will either vanish, too, or be integrated into GCC. * The set-handling routines have been re-written. Set operations are handled in the RTS and should be more stable now. * Some problems with packed arrays on big-endian machines have been solved. * `-dY' is now `--debug-source'. * New options `--[no-]transparent-file-names'. * ... and much more. Have fun, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

3 2

new GPC snapshot
by Robert Payne 02 Nov '99

02 Nov '99

Hello, Just installed the latest GPC snapshot on a SUN ultra 5 workstation running Solaris 7. The gcc is 2.8.1 In util.c and function pascal_init() I had to comment out the following or I got compile errors: /* set_word_size = LONG_TYPE_SIZE; set_alignment = LONG_TYPE_SIZE; set_words_big_endian = 0; */ These variables didn't seem to be used anywhere? The failed tests from the test directory: -n TEST chris4.pas: failed -n TEST chris5.pas: failed Foo: 37 42 53 58 137 150 195 196 197 198 199 200 201 202 203 204 205 206 207 208 2 09 210 211 212 213 214 215 216 217 218 219 220 Bar: 13 51 52 53 54 55 115 116 117 118 119 153 171 172 173 174 186 188 189 212 220 221 222 224 234 Baz: 53 58 150 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 -n TEST dialec5.pas: failed -n TEST dialec6.pas: failed -n TEST dnull1.pas: -n TEST fjf3.pas: failed -n TEST fjf32.pas: failed -n TEST ian1.pas: failed -n TEST jj2.pas: failed (2) failed (3) failed (4) failed (5) /0-n TEST kevin8.pas: failed -n TEST pack1.pas: failed -n TEST sets9.pas: failed -n TEST sizeofs.pas: failed: 64 16 You have fixed the "round" problem since the last release. But still have: -n TEST fjf226c.pas: Segmentation Fault - core dumped -n TEST fjf226d.pas: Segmentation Fault - core dumped Robert R. Payne, Systems Software Specialist SAIC/NCI-FCRDC P.O. Box B Bldg 430 Frederick, MD 21702 email: payner(a)ncifcrf.gov phone: 301-846-5496 fax: 301-846-5762

2 1

Sun Sparc Solaris 2.6 binaries
by Super-User 02 Nov '99

02 Nov '99

There is a precompiled GNU Pascal for Sun Sparc Solaris 2.6 in pkgadd format (native Solaris installation package) at: ftp://mizar.uwb.edu.pl/pub/misc/gpc-19990118-Solaris2.6-sparc.pkg.tgz Regards Mariusz Zynel mariusz(a)math.uwb.edu.pl

1 0

Agnes might be unreachable on this weekend
by Peter Gerwinski 29 Oct '99

29 Oct '99

Hello, from tomorrow (Friday), 15:00 until Sunday, 20:00 o'clock, parts of the network of the University of Essen will be switched off. It might be that agnes.dida.physik.uni-essen.de will be unreachable until Monday. Just in case you wonder ... Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

1 2

Has someone a Sun workstation for me? 8-)
by Peter Gerwinski 29 Oct '99

29 Oct '99

Hello, I wanted to finish some work on the most recent (alpha) GPC on a Sun workstation. Unfortunately, the one I have access to is affected by the power hole on this weekend. If someone can give me an account on a Sun with ~100MB of free disk space I can guarantee to leave a current GPC there. :-) Thanks in advance, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

1 1

Cannot install gpc
by Ariel Bendersky 29 Oct '99

29 Oct '99

Hi! I'm trying to install the binary package gpc-19990607-djgpp.zip and after uncompressing it into my djgpp directory I got the following while trying to compile: ************** C:\Ariel>gpc test.pas c:\utils\gcc\bin\ld.exe: cannot open -lgcc: No such file or directory (ENOENT) *************** I've read on the list an e-mail with a similar problem, but I do have installed gcc (version 2.95), and still get the same error. By the way, the test.pas is as simple as: *************** program test; begin writeln('test'); end. *************** Thank you, Ariel. --- Ariel Bendersky bender(a)einstein.com.ar ICQ 1914963

2 1

Re: Third Step
by Frank Heckenbach 27 Oct '99

27 Oct '99

I wrote: > Nicola Girardi wrote: > > > [...] Of course, my reply also shouldn't have gone to the list. Sorry. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Third Step
by Frank Heckenbach 27 Oct '99

27 Oct '99

Nicola Girardi wrote: > the editor is really what i was looking for, and i appreciate your work. Thanks. > i have something to say, anyway (i hope you'll find these as good > suggestions) > > 1) perhaps you should work on the syntax highlighting, i mean, you > should make both "BeGin" and "begin" highlighted, because pascal is > case insensitive Right. Will do so. (I always write my keywords in lower-case, so I didn't notice.) > 2) again for syntax hig. perhaps there should be a gray comment-highlight, > that doesn't seem to be present. No, it isn't there yet. As I said, the highlighting currently is a bit primitive. In particular, it only works per line. I have plans to do real highlighting, including multi-line comments, support for different languages and more, but it's not on the top of my priority list... So, what I could do now easily would be highlighting for comments within a single line, but I'm not sure if it's useful. What do you think? > 3) the date in the window title bar!! : > /home/girardi/typing/math3.pas 27.10.1999 > it is absolutely ugly :) You can turn the time and/or date off under Options/Environment/Clock, but for the next release, I've already changed the default to time only. > 4) some colors are a bit eye-breaking ;) You can change all the colors under Options/Colors, but if you tell me which ones you don't like and what you'd prefer, I might change the defaults. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Third Step
by Frank Heckenbach 27 Oct '99

27 Oct '99

Nicola Girardi wrote: > i worked it out :) > > [...] For those who wonder: This was a reply to a private mail, mistakenly posted to the list. If anyone has become curious about the editor, just stay tuned for a few days... ;-) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

FreeBSD port
by Marc van Woerkom 27 Oct '99

27 Oct '99

Dear GNU Pascal developers, had another read of the GPC pages but I am still uncertain about your development model. At present I can spot source tarballs only and miss a CVS server badly. Is it possible to get access to the latest sources? It would help me considerably to arrange things with our folks responsible for the compiler. Regards, Marc

2 1

Re: Unit Printer
by Peter Gerwinski 27 Oct '99

27 Oct '99

Russ Whitaker wrote: > > 1) How do I pass '-Praw' to PrinterArguments? Like this: (Thanks, Frank!) program Foo; uses GPC, Printer; var Printer : Text; begin (* New (PrinterArguments, 1);*) getmem(printerarguments,8);{$w-}word(pointer(printerarguments)^):=1; PrinterArguments^[1] := NewString ('-Praw'); AssignPrinter (Printer, null); Rewrite (Printer); Writeln (Printer, 'foo') end. Unfortunately, there is a problem with schema types transported through units, so we need the workaround with `getmem'. I am currently working on this problem, so you will be able use the correct `New' in future releases of GPC. > 2) Any particular reason why PrinterArguments isn't just a string? When you are passing arguments to the program you already know their structure, so it's easy for you to decomposite them. If `PrinterArguments' were just a string, the `pipe' unit would have to do the decomposition before passing the parameters to the subprocess. Not a real problem, but it would be some unnecessary waste of resources. Hope this helps, Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

1 0

Re: Installation problems?
by Peter Gerwinski 27 Oct '99

27 Oct '99

Jawaad Ahmad wrote: > Great! Thanx a lot...I was finally able to compile the simple Hello World > program. However, those GCC-related files take up 4 MB. Now they're taking > up 8 MB b/c they're in two different directories. I'm willing to live with > that, but there's gotta be a better way. If I install something that > assumes I have version 2.5, and another thing that wants version 2.0, will I > have to waste 12 MB? Anyway, thanx...the program compiles and runs! The next alpha snapshot of GPC will work with current versions of GCC, so this problem will vanish. > However, if I have a USES statement, e.g., USES Crt, or USES Gpc in the > sample PI.PAS program, I get the following message once again: > > > > [Win95] C:\TEMP\pas>gpc -Wall pi.pas > > pi.pas:35: warning: `{' within comment > > pi.pas:35: warning: `}' within comment > > pi.pas:26: module/unit interface `Gpc' could not be imported gpc -Wall --automake pi.pas Have fun, Peter PS: For such GPC-related questions of general interest, it's better to ask them on the GPC mailing list rather than to contact me personally. -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

2 2

gpc-19990813 with gcc-2.95 on solaris2.{6,7} and irix6.5 - anyone?
by Benedict Lofstedt 27 Oct '99

27 Oct '99

Hi, Has anyone out there managed to build gpc-19990813 with gcc-2.95 on solaris2.{6,7} and irix6.5 ? I have managed to get past a few hurdles: 1) gpc/p/config-lang.in uses test unknown on solaris [ -e $srcdir/p/Make-lang.in ] must be replaced by [ -r $srcdir/p/Make-lang.in ] --- gpc.orig/p/config-lang.in Tue Aug 3 00:18:13 1999 +++ gpc/p/config-lang.in Wed Oct 27 15:32:44 1999 @@ -43,10 +43,10 @@ echo "#define EGCS" > gcc-version.h echo "#define EGCS92" >> gcc-version.h echo "#define EGCS95" >> gcc-version.h - if [ -e $srcdir/p/Make-lang.in ] \ + if [ -r $srcdir/p/Make-lang.in ] \ && cmp -s $srcdir/p/Make-lang-2.95.in $srcdir/p/Make-lang.in; then true; else cp $srcdir/p/Make-lang-2.95.in $srcdir/p/Make-lang.in; fi - if [ -e $srcdir/p/Makefile.in ] \ + if [ -r $srcdir/p/Makefile.in ] \ && cmp -s $srcdir/p/Makefile-2.95.in $srcdir/p/Makefile.in; then true; else cp $srcdir/p/Makefile-2.95.in $srcdir/p/Makefile.in; fi else @@ -58,10 +58,10 @@ else echo "/* empty */" > gcc-version.h fi - if [ -e $srcdir/p/Make-lang.in ] \ + if [ -r $srcdir/p/Make-lang.in ] \ && cmp -s $srcdir/p/Make-lang-old.in $srcdir/p/Make-lang.in; then true; else cp $srcdir/p/Make-lang-old.in $srcdir/p/Make-lang.in; fi - if [ -e $srcdir/p/Makefile.in ] \ + if [ -r $srcdir/p/Makefile.in ] \ && cmp -s $srcdir/p/Makefile-old.in $srcdir/p/Makefile.in; then true; else cp $srcdir/p/Makefile-old.in $srcdir/p/Makefile.in; fi fi 2) gpc/p/gpc-decl.c needs declaration of nonlocal_goto_handler_slot --- gpc.orig/p/gpc-decl.c Wed Jul 28 03:31:23 1999 +++ gpc/p/gpc-decl.c Wed Oct 27 15:35:49 1999 @@ -54,6 +54,7 @@ #include <ctype.h> extern rtx tail_recursion_reentry; /* in function.c */ +extern rtx nonlocal_goto_handler_slot; /* in function.c */ /* for language specific parts of the tree_node */ extern struct obstack permanent_obstack; 3) An ugly hack to make two object files available [reported by Alexander Sokolov <robocop(a)amur.rosnet.ru> Fri, 20 Aug 1999 20:02:51 +1100 (VLAST) - if there was an answer, I missed it.] # An ugly hack ... rm -f gcc/choose-temp.o; ln -s ../libiberty/choose-temp.o gcc rm -f gcc/pexecute.o; ln -s ../libiberty/pexecute.o gcc 4) Comes to a grinding halt: The hacks&patches above get the build going, until gcc -c -DIN_GCC -DGPC -g -O2 -I. -I.. -I. -I./.. -I./../config -I./../.. /include gpc-lang.c gpc-lang.c: In function `lang_decode_option': gpc-lang.c:50: argument `p' doesn't match prototype ../tree.h:2078: prototype declaration gpc-lang.c:50: number of arguments doesn't match prototype ../tree.h:2078: prototype declaration where the symbol EGCS should be defined to get past this one, but if I do, then the next hurdle is: gcc -c -DIN_GCC -DGPC -DEGCS -I. -I.. -I. -I./.. -I./../config -I./../../include gpc-lex.c In file included from gpc-lex.c:41: gbe.h:79: conflicting types for `fatal' ../system.h:394: previous declaration of `fatal' In file included from gpc-lex.c:46: util.h:174: conflicting types for `concat' ../../include/libiberty.h:48: previous declaration of `concat' gpc-lex.c: In function `yyerror': gpc-lex.c:1158: argument `string' doesn't match prototype ../c-lex.h:84: prototype declaration gmake[2]: *** [gpc-lex.o] Error 1 Anyone with some help & advice out there? --- benedict

1 0

Re: Third Step
by Nicola Girardi 27 Oct '99

27 Oct '99

> > 2) i download the appropriate binary, and here's the result: > > ./peng: error in loading shared libraries > > : undefined symbol: __register_frame_info i worked it out :) the editor is really what i was looking for, and i appreciate your work. i have something to say, anyway (i hope you'll find these as good suggestions) 1) perhaps you should work on the syntax highlighting, i mean, you should make both "BeGin" and "begin" highlighted, because pascal is case insensitive 2) again for syntax hig. perhaps there should be a gray comment-highlight, that doesn't seem to be present. 3) the date in the window title bar!! : /home/girardi/typing/math3.pas 27.10.1999 it is absolutely ugly :) 4) some colors are a bit eye-breaking ;) anyway, i'm going to use it, you've been doing a good work -- Nicola Girardi girardi(at)keycomm.it Key fingerprint = CD 7D 57 C2 52 73 67 B5 13 48 AA 8C 3E 7F 13 DC

1 0

Re: Third Step
by Nicola Girardi 27 Oct '99

27 Oct '99

> > 1) why weren't there the sources ready to be compiled? > > I'm not releasing the sources yet, perhaps at some later time. > Currently, the sources are not in a shape that I want to release > them, sorry... oh, i was afraid u weren't going to release them at all :( > > 2) i download the appropriate binary, and here's the result: > > ./peng: error in loading shared libraries > > : undefined symbol: __register_frame_info > > This is a problem with glibc and programs compiled under SuSE Linux > (as PENG was) running under other distributions. Thanks for pointing > it out. > > Under http://sdb.suse.de/sdb/de/html/kukuk_regframe.html, they > provide a solution. Since the page seems to be available only in > German, I append below a translation made by the Alta Vista > translator (the language is a bit funny, but mostly readable ;-). > > The URL given is also wrong. The correct one is > ftp://ftp.suse.com/pub/suse_update/6.1/a1/regframe.rpm > > You can also wait a few days for the next release. I will link that > version statically to avoid such kinds of problems. i'll try to work it out. anyway, when the next release will be ready, i'll try it again. thanks, -- Nicola Girardi girardi(at)keycomm.it Key fingerprint = CD 7D 57 C2 52 73 67 B5 13 48 AA 8C 3E 7F 13 DC

1 0

Re: RHIDE problem
by Frank Heckenbach 25 Oct '99

25 Oct '99

Adam Naumowicz wrote: > Hello, > I know that probably it is not the best list to write about it, > but I know that most of GPC programmers use RHIDE, so I decided > to ask you. I use RHIDE on Linux successfully, but trying to install > it for my friend on RedHat 6.0 I encountered RTE at the first > attempt to start the editor. There was a message like 'segmentation fault, > unable to connect to a terminal' or something like that. Maybe it is a > known problem, maybe there is some work-around. My friend uses RIVA TNT > grafic card - maybe that is the problem ? Is the TERM variable set up correctly? Try `echo $TERM' in the shell -- it should say linux when on the console, or xterm, rxvt or something like that in an X terminal. If that's ok, it might be that rhide doesn't find the terminfo directories. Search for a file whose name is the TERM value in a directory whose name is only the first letter of that value below a directory like /usr/share/terminfo, /usr/lib/terminfo, /usr/local/share/terminfo /usr/local/lib/terminfo, e.g. /usr/lib/terminfo/l/linux. If you find it, set the main directory to the TERMINFO variable (`setenv TERMINFO /usr/lib/terminfo' in (t)csh; `export TERMINFO=/usr/lib/terminfo' in bash), or (as root) set a symlink to the directory where rhide expects it (I don't know which one, probably one of the above). If you don't find it at all, you might have to install the package containing terminfo (usually ncurses), though I can't imagine it hasn't been installed... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc