Gpc June 2004

gpc@gnu.de

21 participants
29 discussions

Re: porting Digital Pascal to Gnu Pascal -
by Mingeborg＠aol.com 13 Jun '04

13 Jun '04

Thank you for looking at this, and sorry if this question is really silly, but I don't understand your directions. If I make the following kind of changes to all modules: unit env; interface procedure proc1;external name 'proc1'; procedure proc2;external name 'proc2'; procedure proc3;external name 'proc3'; implementation end. unit unit3; interface uses env; procedure proc3; attribute (name = 'proc3'); implementation procedure proc3; begin writeln("running proc3"); proc1; proc2; end; end. In that case, I get this error message: >gpc --automake -o main main.p unit3.p:4: error: attributes in previously declared routines are not allowed gpc1: gpc exited with status 1 If I get rid of the env module, and try to do the following with all modules: unit unit1; interface uses unit2, unit3; procedure proc3; attribute (name = 'proc3'); implementation procedure proc1; begin writeln("running proc1"); end; end. In that case, I get the following error message: >gpc --automake -o main main.p unit2.p:4: error: checksum mismatch for interface 'unit2' (recompile interfaces in the right order) gpc1: gpc exited with status 1 What exactly should I have done? Thanks, - Inga In a message dated 6/13/2004 2:04:33 PM Eastern Daylight Time, ih8mj(a)fjf.gnu.de writes: > > Well, GPC can do the latter as well, but you have to tell it to > explicitly: > > [env] > procedure proc1; external name 'proc1'; > > [unit1] > procedure proc1; attribute (name = 'proc1'); > > I still don't consider it very nice. > > The "real" solution would, of course, be to declare all routines in > the interface of that unit which implements it, and get rid of your > `env' unit. > > Then, each unit can import (`uses') all other units (or only those > that it actually needs) in the implementation part, so you can > compile all interfaces first, then all implementations (or > use GP > which will do this automatically). > > Frank

2 1

Questions about pointers
by Neil Santos 13 Jun '04

13 Jun '04

While testing a few ideas with pointers, I bumped into a behavior not very clear to me. During the development of one of the modules I'll be using in a project of mine, there came a point where I decided I'll simply assign the address of a pointer variable passed as a paramater as the value of one of an object's fields. While writing the code for the said object's destructor, I decided to test what would happen to the variable, whose address I've assigned to an object's field, after I've applied Dispose() to the latter. Here's a sample of what I was trying to do: program BankTest; var BankCredit : PCredit; BankSample : PBank; begin New(BankCredit); BankCredit^ := 1000; New(BankSample, BankCredit); BankSample^.Destroy; writeln(BankSample^); Dispose(BankCredit); end. TBank.Create has this: constructor TBank.Create(amount : PCredit); begin New(Self.AccountBalance); Self.AccountBalance := amount; end; TBank.Destroy has this: destructor TBank.Destroy; begin Dispose(Self.AccountBalance); end; I get no errors or warnings (compiled with -O2 and -Wall), but when I try to run the resulting example, I get a `Segmentation fault' where writeln(BankSample^) is. Here are my questions: 1) Is this correct behavior according to the standards? I know that doing two New()'s on the same pointer is a recipe for disaster, but it is unclear to me whether the same applies to this scenario. 2) If this is correct (i.e., I'm doing something I shouldn't be doing), then why doesn't GPC catch it? If this is already planned, then I guess I should just be more careful; but if it isn't, would it be hard to implement this? I apologize for the long message, but all of the Pascal resources I have aren't very clear about this particular situation. Any clues as to where I should look (and/or help in general) would be greatly appreciated. TIA. -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

4 7

Re: porting Digital Pascal to Gnu Pascal - modules
by Mingeborg＠aol.com 13 Jun '04

13 Jun '04

Thank you for looking at this. I am enclosing a gzipped tar file of 5 very small example files, (test.tar.gz.) This is the example code: unit env; interface procedure proc1;external; procedure proc2;external; procedure proc3;external; implementation end. unit unit1; interface uses env; procedure proc1; implementation procedure proc1; begin writeln("running proc1"); end; end. unit unit2; interface uses env; procedure proc2; implementation procedure proc2; begin writeln("running proc2"); end; end. unit unit3; interface uses env; procedure proc3; implementation procedure proc3; begin writeln("running proc3"); proc1; proc2; end; end. program main; uses unit1, unit2, unit3; begin proc1; proc2; proc3; end. Digital Pascal allows this "structure" of the code via [global] modules, and this code worked in the last release. In the current release, I am getting the following error messages: > gpc --automake -o main main.p unit3.o(.text+0x52): In function `Proc3': : undefined reference to `proc1' unit3.o(.text+0x57): In function `Proc3': : undefined reference to `proc2' collect2: ld returned 1 exit status Before I start completely re-orgarnizing 3000+ modules, I would like to have confirmation that there currently is no alternative. Thanks, - Inga Mingeborg(a)aol.com wrote: > I have tried using the unit / uses syntax, (specifying that each unit âusesâ > this environment module,) but I still cannot get these units linked. The > compiler is complaining about several hundreds of âundefined referencesâI > am now assuming that it is expecting the âimportedâ modules to contain the > code for all of the procs/funcs called by each unit, rather than just the > âexternalâ definition. Is this correct, or might I be misunderstanding what > is happening? (I am currently running gpc-20040516, gcc-3.3.3, on Suse > Linux. I had previously run some tests using the last Gnu Pascal release > system running on cygwin.) > > I am hoping to avoid having to analyze dependencies and completely > re-organize the modules. Is there any other way? I don't know if you've already got an answer, so here's mine: Could you send a detailed error message from the compiler? It's especially interesting which references remain unresolved. My guess is that you are using some of the GPC standard units, and that you didn't add the according linking statements to the command line. For example, if you're compiling a source that "uses Crt", your command line will have to look like this: gpc foo.pas -o foo -lncurses -lpanel ... since crt.pas is based upon the shared libraries libncurses and libpanel. Regards, Markus

1 0

Re: threads status in GPC
by Paul Davidson 07 Jun '04

07 Jun '04

However, I'm currently working on a (pthread-based) standard unit for GPC multithreading, so if you aren't in a hurry, maybe I can offer you a solution within a few weeks. :-) Please!

1 0

--language=Pascal
by Adriaan van Os 03 Jun '04

03 Jun '04

The question rises whether Pascal is written with an uppercase "p" or not [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c --language=Pascal hello.pas [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c --language=pascal hello.pas gpc: language pascal not recognized So, gpc expects an uppercase "p". On the other hand: - ada, fortran and c are written in all lowercase (see the man pages for gcc) - gdb writes Pascal lowercase - gp writes "--pascal=OPTION" lowercase. Because of this, it came to a surprise to me that --language=pascal didn't work (and it took me some time to find out that --language=Pascal did). (can't remember if I reported this before) Regards, Adriaan van Os

3 3

Version information
by Frank Thomas Braun 03 Jun '04

03 Jun '04

Could anybody kindly uodate the Webpage http://www.gnu-pascal.de/gpc/Current-version.html#Current%20version Frank BraunFrank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de

2 1

GP
by Frank Heckenbach 03 Jun '04

03 Jun '04

I've put a new version of GP with the minor changes discussed here at <http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz>. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

13 45

Installation problem with gpc (djgpp, Windows XP)
by Frank Thomas Braun 01 Jun '04

01 Jun '04

I am working successfully with a gpc installation from 2002 and wanted to update to the current version. So I downloaded from "GNU Pascal download area: Current" / binaries / DJGPP (http://www.gnu-pascal.de/binary/djgpp/) all files. After unzipping and a successful installation (gpc -v is working) a try to compile even simple files results in: D:\xxy>gpc HALLO.PAS gpc.exe: Internal GPC problem: internal option `--amtmpfile' not given I read and followed any instructions of http://www.gnu- pascal.de/gpc/Installing-GPC-on-DJGPP.html set DJGPP=c:\gpc\djgpp.env Additions to djgpp are entered and correct. (My first installation of gpc together with djgpp was very problematic too and I succeeded to install a working compiler only after help from the mailing list. That is the reason, that I didn't update the compiler). Frank Braun Frank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de

3 7

Re: gpascal (was: cgp? (was: GP ;-))
by Tom Verhoeff 01 Jun '04

01 Jun '04

And what about gpascal This is slightly longer, but leaves (almost) nothing to the imagination. We don't need a c in the name for compiler, do we? Tom

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 June 2004