Gpc July 2001

gpc@gnu.de

41 participants
71 discussions

Re: Error with asmname
by Frank Heckenbach 11 Jul '01

11 Jul '01

Gloria, Jing wrote: > I would appreciate any assistance to the following problem. > > The following 2 lines of code result in error during compilation: > > Var > Testcode: integer; asmname 'testcode'; > > Error: > try_hello.pas:3: parse error before character constant > try_hello.pas:5: comma missing after identifier `Asmname' > try_hello.pas:5: parse error before `;' > > Note: Line 3 is the line with asmname keyword. > > I am using: > GNU Pascal version 2.95 19990728 (release) (i386-pc-solaris2.7) > compiled by GNU C version 2.95.1 19990816 (release). > > If I remove the asmname 'testcode' from line 3, then the > compilation goes through without any errors. > > Thanks in advance for any assistance. This part of the syntax was changed recently. What you describe is the new syntax, but your compiler version requires the old syntax like this: Var Testcode: __asmname__ 'testcode' integer; Testcode: integer; Note that's a non-external variable with a specified asmname. If you mean an external variable, the old syntax is: Var Testcode: __asmname__ 'testcode' integer; and the new one: Var Testcode: integer; external; asmname 'testcode'; So, use the old syntax or upgrade GPC (if you're doing such things a lot, you might want to upgrade now, since you'll probably do it sometime, anyway, and then you'd habve to change everything). Frank PS: Please turn off HTML! -- 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

Error with asmname
by Gloria, Jing 09 Jul '01

09 Jul '01

I would appreciate any assistance to the following problem. The following 2 lines of code result in error during compilation: Var Testcode: integer; asmname 'testcode'; Error: try_hello.pas:3: parse error before character constant try_hello.pas:5: comma missing after identifier `Asmname' try_hello.pas:5: parse error before `;' Note: Line 3 is the line with asmname keyword. I am using: GNU Pascal version 2.95 19990728 (release) (i386-pc-solaris2.7) compiled by GNU C version 2.95.1 19990816 (release). If I remove the asmname 'testcode' from line 3, then the compilation goes through without any errors. Thanks in advance for any assistance. Jing Gloria Texas Instruments

1 0

Re: gpc asks for djgpp.ver?
by Toby Ewing 09 Jul '01

09 Jul '01

Hi, folks, Maurice Lombardi wrote: > Toby Ewing wrote: > > I downloaded gpc version 20010623, based on 2.95.3 20010315, and unzipped it > > into my existing c:/djgpp directory (I'm running under win98). Then I started > > up RHIDE, loaded my program, and tried to compile. > > > > The compilation quickly stopped with the error: > > djgpp.ver: no such file or directory (ENOENT). > > > > Sure enough, I find no djgpp.ver anywhere. Where do I get this file? Was it > > there before, and deleted during the upgrade? > > You probably have gcc-2.95.2 with your old setup. > this file djgpp.ver (in the lib directory) appeared when going from 2.95.2 to 2.95.3 > So upgrade gcc from gcc2952b.zip to gcc2953b.zip. > > Maurice That was it! thanks, Maurice. Toby

1 0

gpc asks for djgpp.ver?
by Toby Ewing 09 Jul '01

09 Jul '01

Hello, all I've been running into a strange bug, and hoping that it had been corrected in a more recent version of the compiler, I decided to upgrade. Perhaps this was a mistake... I downloaded gpc version 20010623, based on 2.95.3 20010315, and unzipped it into my existing c:/djgpp directory (I'm running under win98). Then I started up RHIDE, loaded my program, and tried to compile. The compilation quickly stopped with the error: djgpp.ver: no such file or directory (ENOENT). Sure enough, I find no djgpp.ver anywhere. Where do I get this file? Was it there before, and deleted during the upgrade? Toby soil scientist, Iowa State University

1 0

Building GPC on sparc-solaris
by Kocherlakota Harikrishna 09 Jul '01

09 Jul '01

Hello we previously had built the compiler on Linux with the sources from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha site. Now we are trying to use the same sources to build the compiler on solaris and while executing the command "make LANGUAGES=pascal" The following error is seen: make: Fatal error in reader: Makefile, line 2219: Unexpected end of line seen Current working directory /home/users/gcc-2.95.2/gcc *** Error code 1 make: Fatal error: Command failed for target `all-gcc' Please help us how to proceed further . Thanks and kind Regards hari

1 0

Solaris 8 install & post-install problems
by Kev Buckley 09 Jul '01

09 Jul '01

Hello, I have been trying, on behalf of one of our researchers here, to install the gpc-20010623 on a Solaris 8 (8-04) SunBlade. I had install problems buth using Sun's "extra" gcc-2.95.2 sources as the base and using the gcc-core distribution from the GPC ftp site. Mainly, these difficulties appear to arise because things like xmalloc and concat were being multiply defined. So, by a good deal of guesswork, I ended up adding: -DEGCS -DEGCS92 -DEGCS95 to be defined when doing the make. It compiled. However when I try to compile a "hello word" I get the following at the linker stage Undefined first referenced symbol in file _p_eq /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/libgpc.a(string.o) ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status I guess this is a Pascal thing. Anyone had any success with GPC under Solaris 8 ? Anyone shed any light ? Full gpc -v helo.pas output is Reading specs from /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20010605, based on gcc-2.95.2 19991024 (release) /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/gpcpp -lang-pascal -v -famtmpfile=/var/tmp/cc4YaaNX -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010605 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) hello.pas /var/tmp/cc5YaaNX.i GNU Pascal Compiler PreProcessor version 20010605, based on gcc-2.95.2 19991024 (release) (sparc) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/packages/gcc-2.95.2/sparc-sun-solaris2.8/include /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include /usr/include End of search list. /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/gpc1 /var/tmp/cc5YaaNX.i -quiet -dumpbase hello.pas -version -famtmpfile=/var/tmp/cc4YaaNX -o /var/tmp/cc5YaaNX.s GNU Pascal version 2.95.2 19991024 (release) (sparc-sun-solaris2.8) compiled by GNU C version 2.95.2 19991024 (release). GNU Pascal version is actually 20010605, based on gcc-2.95.2 19991024 (release) /usr/ccs/binås -V -Qy -s -o /var/tmp/cc5YaaNX1.o /var/tmp/cc5YaaNX.s /usr/ccs/binås: Sun WorkShop 6 99/08/18 /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/crt1.o /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/crti.o /usr/ccs/lib/values-Xa.o /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/crtbegin.o -L/usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/packages/gcc-2.95.2/lib /var/tmp/cc5YaaNX1.o -lgpc -lm -lgcc -lc -lgcc /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/crtend.o /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/crtn.o ld: Software Generation Utilities - Solaris-ELF (4.0) Undefined first referenced symbol in file _p_eq /usr/local/packages/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/libgpc.a(string.o) ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status -- Regards, ---------------------------------------------------------------------- * Kevin M. Buckley e-mail: K.Buckley(a)lancaster.ac.uk * * * * Systems Administrator * * Computer Centre * * Lancaster University Voice: +44 (0) 1524 5 93718 * * LANCASTER. LA1 4YW Fax : +44 (0) 1524 5 25113 * * England. * * * * My PC runs Linux/GNU, you still computing the Bill Gate$' way ? * ----------------------------------------------------------------------

2 1

AssignFile -> Assign
by Preben Mikael Bohn 09 Jul '01

09 Jul '01

Hi all I'm just trying to convert a Delphi program (non-visual) into GPC. I thought it would be much harder, but actually it's very easy. I have one problem though: In Delphi they use AssignFile instead of Assign. I have defined a unit rtlib, where all Delphi-specific procedures are defined. I first defined AssignFile as procedure assignFile(var f : TextFile; fileName : string ); begin assign(f,filename); end; { assignFile } However now I also need to define it with typed files. Is there a way to have more than one definition? Best regards Preben Bohn PS. Yes, I could just replace AssignFile with Assign... :-) ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

2 2

moveleft?
by Oldham, Adam 07 Jul '01

07 Jul '01

Hello people, Again, I didn't see this in any FAQs or in the Bug List, so I am going to post the question. The Moveleft and Moveright functions should basically take a source and destination and copy the length number of bytes (from the left or right respectively), correct? That is how it worked with the old compiler I had, but I think we have come to the conclusion that it is horribly nonstandard, and since there are no help files on moveleft and moveright on the GPC page, I have to ask, and then ask if this is a bug. My sample source is this: TYPE AnyStr = STRING[40]; AnyStrPtr = ^AnyStr; VAR TestVar1 : AnyStrPtr; TestVar2 : AnyStrPtr; TestVar3 : AnyStr; TestVar4 : AnyStr; BEGIN TestVar3 := 'TEST1'; TestVar1 := AnyStrPtr(@TestVar3); TestVar4 := 'TEST3'; TestVar2 := AnyStrPtr(@TestVar4); writeln(TestVar1^); writeln(TestVar2^); MOVELEFT (TestVar1^, TestVar2^, (LENGTH(TestVar1^) + 1)); writeln(""); writeln("After"); writeln(TestVar1^); writeln(TestVar2^); END. { unit pSos } With GPC, the output is: TEST1 -> (TestVar1) TEST3 -> (TestVar2) After TEST1 -> (TestVar1 after MoveLeft) TEST3 -> (TestVar2 after MoveLeft) With my old compiler, the output is: TEST1 TEST3 After TEST1 TEST1 As it basically copies the length bytes of TestVar1 into TestVar2. Now, my question, does GPC work differently for this function, and if yes or no, is this a bug. Also, if you guys need some help finishing the GPC manual, let me know, I am willing to lend a hand. Adam Oldham ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

4 3

[Re: moveleft?]
by Maurice Lombardi 06 Jul '01

06 Jul '01

Oldham, Adam wrote: > TYPE > AnyStr = STRING[40]; > AnyStrPtr = ^AnyStr; > > VAR > TestVar1 : AnyStrPtr; > TestVar2 : AnyStrPtr; > TestVar3 : AnyStr; > TestVar4 : AnyStr; > > BEGIN > TestVar3 := 'TEST1'; > TestVar1 := AnyStrPtr(@TestVar3); > TestVar4 := 'TEST3'; > TestVar2 := AnyStrPtr(@TestVar4); > writeln(TestVar1^); > writeln(TestVar2^); > MOVELEFT (TestVar1^, TestVar2^, (LENGTH(TestVar1^) + 1)); > writeln(""); > writeln("After"); > writeln(TestVar1^); > writeln(TestVar2^); > END. { unit pSos } > > With GPC, the output is: > TEST1 -> (TestVar1) > TEST3 -> (TestVar2) > > After > TEST1 -> (TestVar1 after MoveLeft) > TEST3 -> (TestVar2 after MoveLeft) > > With my old compiler, the output is: > TEST1 > TEST3 > > After > TEST1 > TEST1 > > As it basically copies the length bytes of TestVar1 into TestVar2. Now, my > question, does GPC work differently for this function, and if yes or no, is > this a bug. Your old compiler was probably a Borland type, i.e. AnyStr are one byte [0] containing the length and 40 bytes containing the chars. This is why you moved length()+1 chars, 1 being for the zeroth char. In gpc String is different. It is defined as: type String (Capacity : Integer) = record Length : 0 .. Capacity; String : packed array [1 .. Capacity + 1] of Char end; When you moves 6 chars, you move mainly the Capacity and (part of) the Length field, this is why it seems you move nothing. The result would be even stranger if the two strings had different Capacity and/or Length. One solution if you want to move only the chars would be MOVELEFT (TestVar1^[1], TestVar2^[1], (LENGTH(TestVar1^))); i.e. addresses of the first chars and no more +1. This non pascal, C style or assembly style, kind of programming can work only if you know exactly the internals of your system, down to binary level. Otherwise it opens a can of worms and any porting from one system to another is a very efficient bug generator, as you have checked. For example If you tried to move also the Capacity and Length fields to solve your problem, the result would depend on undefined things like alignment of these fields: try to write SizeOf(AnyStr). On my system it is 52, instead of 40 + 1 + 2*SizeOf(integer) = 49: alignment on a four bytes (integer) boundary. String assignment is probably the right way of doing ! So this is definitely not a bug of gpc, rather a bug entailed by Borland style programming. 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

1 0

trouble reading postings
by toms＠ncifcrf.gov 06 Jul '01

06 Jul '01

In the last few days I have been getting this message for the summary of gpc postings: Seems that message/rfc822 data was corrupted. Has something changed on the list? Is someone putting weird stuff into their email messages? I use elm (old but a better design than mutt!!) to read my email. Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

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