Gpc July 2001

gpc@gnu.de

41 participants
71 discussions

GPC Build Error
by Gloria, Jing 13 Jul '01

13 Jul '01

I am trying to install the latest version (20010623) of GPC. However, during the make I get the following error: -------------------------------------------- In file included from /usr/pgmdev/gcc-2.95.2/gcc/p/gpc-common.c:35: /usr/pgmdev/gcc-2.95.2/gcc/p/util.h:196: conflicting types for `concat' /usr/pgmdev/gcc-2.95.2/gcc/p/../../include/libiberty.h:48: previous declaration of `concat' make[1]: *** [gpc-common.o] Error 1 -------------------------------------------- in include\libiberty.h:48 - extern char *concat PARAMS ((const char *, ...)); in gcc-2.95.2/gcc/p/util.h:196 - extern char *concat PARAMS ((char *, ...)); Pls advise which one is correct. Or is there a switch/directive to disregard this error? I am installing on an Intel x86/Solaris 7 platform using GCC 2.95.2. I pulled down the GCC source from the Sunfreeware site and the GPC source from the GPC site. Pls advise also if there are other potential problems that have already been reported and addressed. By the way the link to the GPC mailing list archive http://www.gnu.de/archive/wilma.cgi/gpc is broken. Regards, Jing Gloria Texas Instruments

3 2

Re: GPC Build Error
by Gloria, Jing 13 Jul '01

13 Jul '01

Maurice, you say that the prototypes in both files are the same. Is it: extern char *concat PARAMS ((char *, ...)); or is it the one with ((const char *, ...));? My util.h also has the ifndef EGCS92 test. Regards, Jing Gloria Texas Instruments

2 1

GNU Pascal Coding Standards
by Nicola Girardi 13 Jul '01

13 Jul '01

Hi GPC'ers! Just the link for those not subscribed to gpc-doc(a)gnu.de: http://adele.gerwinski.de/~nicola/pascal-standards/ NB: We're sorry for the long HTML file, but if we use texi2html to split the files we get many links pointing to the same document instead of pointing to the GNU Coding Standards, to which we refer often. Greetings, Frank Heckenbach <frank(a)pascal.gnu.de> Peter Gerwinski <peter(a)gerwinski.de> Nicola Girardi <nikke(a)swlibero.org>

1 0

GNU Pascal Coding Standards
by Nicola Girardi 12 Jul '01

12 Jul '01

Hi GPC'ers! In the next days the GNU Pascal Coding Standards will be released to the public. As it will be the first public release, there may be some discussions on the several issues raised by the manual. So please join the gpc-doc@ mailing list if you'd like to see and/or take part in the discussions, rather than starting a thread here. The aim of the GNU Pascal Coding Standards is extending the GNU Coding Standards with specific information relating Pascal programming. Of course there are topics that can be shared between the two manuals, and we have taken this into account. Greetings, Frank Heckenbach <frank(a)pascal.gnu.de> Peter Gerwinski <peter(a)gerwinski.de> Nicola Girardi <nikke(a)swlibero.org>

2 1

Re: Boolean problem
by jallan 12 Jul '01

12 Jul '01

If your example was: procedure testshift; VAR shift_cor :boolean; begin shift_cor := true; writeln('shift_cor: ',shift_cor); { shift_cor: True } if shift_cor=true then Shift_correction; end; then it would work as you expect Jamie ----- Original Message ----- From: jallan To: Casper ter Kuile ; gpc Sent: Friday, July 13, 2001 1:44 AM Subject: Re: Boolean problem Casper, The example you've given does not set the value of shift_cor at all. It simply displays text and the value TRUE. You have to set shift_cor initially before it will have a value to test upon. ----- Original Message ----- From: Casper ter Kuile To: gpc(a)gnu.de Sent: Friday, July 13, 2001 1:07 AM Subject: Boolean problem Hi, I encounter a stange problem. The boolean variable "shift_cor" is "true" shift_cor :boolean; writeln('shift_cor: ',true); { shift_cor: True } if shift_cor=true then Shift_correction; But the if statement does not work out to be "true" as the procedure "Shift_correction" does not run. Anyone an idea what is wrong here? Thanks! Casper. Casper ter Kuile, Lab. for Radiation Research (LSO), National Institute of Public Health and the Environment (RIVM) PO box 1, NL-3720 BA, Bilthoven, the Netherlands Phone +(31)-30-2742647 or +(31)-30-2742515 E-mail: casper.ter.kuile(a)rivm.nl Web: http://www.rivm.nl

1 0

Boolean problem
by Casper ter Kuile 12 Jul '01

12 Jul '01

Hi, I encounter a stange problem. The boolean variable "shift_cor" is "true" shift_cor :boolean; writeln('shift_cor: ',true); { shift_cor: True } if shift_cor=true then Shift_correction; But the if statement does not work out to be "true" as the procedure "Shift_correction" does not run. Anyone an idea what is wrong here? Thanks! Casper. Casper ter Kuile, Lab. for Radiation Research (LSO), National Institute of Public Health and the Environment (RIVM) PO box 1, NL-3720 BA, Bilthoven, the Netherlands Phone +(31)-30-2742647 or +(31)-30-2742515 E-mail: casper.ter.kuile(a)rivm.nl Web: http://www.rivm.nl

2 1

size of executables / sourcecode as string-parameter?
by michael paap 12 Jul '01

12 Jul '01

Hello, I am not familiar with the GPC, but i will have to rewrite a Java-application, which calls a Pascal-compiler and executes the new-built program afterwords to work with GPC instead of Turbo-Pascal. So I have two questions, for which I request Your help: 1. There is a really big difference in the size of executables made by TPC under Dos ans those made by GPC under LINUX. Is this normal, or is there any possibility, to decrease the size of the executables made by GPC? 2. Is there any possibility, to give the Sourcecode to GPC as a string-parameter instead of using a file? I would like to call GPC from the Java-Program this way, if possible. Greetings, Michael Paap

1 0

collect2
by Nicola Girardi 12 Jul '01

12 Jul '01

Hi GPC'ers!! I was trying to set up a cross compiler on a Linux host to generate Windoze executables. I succeeded using the usual --target=...-mingw32 but when I run i...-mingw32-gpc I get a message about collect2 missing. And in fact, it is missing. Only symlinking ld to collect2 works smoothly. Why does that happen? Thanks in advance. Nick

3 4

crashing while killing list
by Toby Ewing 12 Jul '01

12 Jul '01

Hi, all I just upgraded to a more recent version of GPC, 2001something. I don't know if that's the root cause, but I'm having trouble killing a linked list. I get a page fault or a GPF (I'm running under win98) when trying to delete the last or next to last record. I've marked the line named in the call traceback. I took my Linsert and Lwipe procedures and put them into a test program (see below). It runs perfectly. But when I run them in the program I'm actually working on -- the program I took the procedures from -- it crashes in Lwipe. Nothing else in the big program even refers to the list. Any suggestions? It's frustrating to be stopped on such an elementary problem. Lists and I have been friends for years, and I'm supposed to be stuck on much more interesting problems! Toby _____________________________ Program ListTest; type PRec = ^Rec; Rec = record ri : integer; Next : PRec; end; var Root : PRec; i : integer; {----------} Procedure LWipe(var Root : PRec); var point : PRec; begin while (Root^.next <> Nil) do begin {<<== program crashes on this line} write('deleting ', root^.ri, ' '); point := Root; Root := Root^.next; Dispose(point); end; if Root <> Nil then begin write('deleting ', root^.ri); Dispose(Root); Root := Nil; end; end; {----------} Procedure LInsert(var num : integer; var Root : PRec); {insert a new record at the *front* of the list} var Site : Rec; temp : PRec; begin with Site do begin ri := num; next := Nil; end; if Root = Nil then begin {starting the list} New(Root); Root^ := Site; end else begin {list already exists} New(temp); {get new memory} temp^ := Site; {move memory} temp^.next := Root; {repoint pointers} Root := temp; end; end; {LInsert} {----------} Begin for i := 1 to 100 do LInsert(i, Root); LWipe(Root); End.

2 1

Fwd: crashing while killing list
by Toby Ewing 11 Jul '01

11 Jul '01

*Groan* once again, programing is primarily a lesson in humility. rpewing(a)lbl.gov wrote: > I just upgraded to a more recent version of GPC, 2001something. I don't > know if that's the root cause, but I'm having trouble killing a linked > list. I get a page fault or a GPF (I'm running under win98) when trying > to delete the last or next to last record. I've marked the line named > in the call traceback. .. I forgot to initialize the pointer to Nil. I think BP did this for me, so I got out of the habit. A corrected version is below. Toby > _____________________________ > > Program ListTest; > > type > PRec = ^Rec; > Rec = record > ri : integer; > Next : PRec; > end; > > var > Root : PRec; > i : integer; > {----------} > > Procedure LWipe(var Root : PRec); > var point : PRec; > begin > while (Root <> Nil) do begin > write('deleting ', root^.ri, ' '); > point := Root; > Root := Root^.next; > Dispose(point); > end; > end; > {----------} > > Procedure LInsert(var num : integer; > var Root : PRec); > {insert a new record at the *front* of the list} > var > Site : Rec; > temp : PRec; > begin > with Site do begin > ri := num; > next := Nil; > end; > if Root = Nil then begin {starting the list} > New(Root); > Root^ := Site; > end else begin {list already exists} > New(temp); {get new memory} > temp^ := Site; {move memory} > temp^.next := Root; {repoint pointers} > Root := temp; > end; > end; {LInsert} > {----------} > > Begin Root := Nil; {<< the line I forgot} > for i := 1 to 100 do LInsert(i, Root); > LWipe(Root); > End. >

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 July 2001