Gpc October 2001

gpc@gnu.de

45 participants
80 discussions

Re: installation problems
by Oldham, Adam 19 Oct '01

19 Oct '01

Sorry Frank, here is the complete report: I link a rather large application (500+ Pascal files with 20 C files) into one executable. I precompile everything as objects and then perform the following commands to link: find /src -name '*.o' -exec echo -n {} " " \; > lnk.tmp echo -n /src/os/os.a " " >> lnk.tmp\ touch rds.map gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map The os.a is just a library I create from all the precompiled C stuff. I do not think any of this is a big deal, as I have done this successfully in the past, before the system had to be upgraded. My library paths should be fine (/lib /usr/lib/ /usr/local/lib /usr/C11R6/lib /usr/local/fpc/lib). Nothing unusual, and /usr/lib is where all the gcc/gpc libraries live. Using '-v' does not give much more info other than showing all the objects I am linking together. However, I can compile small test programs of 1 file or slightly more successfully using GPC on the command line (--automake). They will run with no problems. Someone needs to write these companies like Mandrake, Redhat, Suse and get them to stop using these bad compilers. People have been complaining about this 'v2.96' compiler for 2 years now and they are still distributing them. It's a real pain and trying procedure to get that compiler off and still have their stock programs run correctly (because of library dependencies). Thanks guys! Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 7:20 PM To: gpc(a)gnu.de Subject: Re: installation problems Oldham, Adam wrote: > I am using Mandrake Linux with kernel 2.4.8. It had the wonderful version > of gcc 2.96 installed on it stock. I've since downgraded to gcc 2.95.3. > I've downloaded gpc-20010924, and installed it the regular old way I've > installed all the other version of GPC I've gotten the past 2 years. It > installs fine, into /usr just like gcc. > > I can compile files with no problem as well. I compile all my pascal files > to only create object files, no other parameters from the command line. > When linking all these objects together statically, I get a few errors like > this: > /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o): In function > `_p_Real_Sin': > /v/oldham/gcc-2.95.3/gcc/p/rts/rts.c:642: undefined reference to `sin' > > I get the same thing for the functions cos, log, pow, sinl, cosl, logl, > expl, powl, sinh, cosh. I've researched this some, and linking the -lm > (math library) while performing my link does not help this. Can anyone help > at all with this in particular? How you do link? Do you call gpc, gcc, or ld directly? What command line? Does it work if you just compile and link with GPC (--automake)? Does the linker command line you see with `-v' help you? ... I think I mentioned once or twice in the past few days that I'd prefer complete reports ... :-( > Should GPC have linked -lm while it was building? No, it's not the gpc executable, but your program executable that needs -lm. Marco van de Voort wrote: > > Should GPC have linked -lm while it was building? And if so, can someone > > help me find where that is. I've been looking at this for hours now. > > Sounds like not linked with libgcc, or wrong (out of sync) version. No, libm is quite independent of libgcc. 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

strings & fillchar
by Oldham, Adam 19 Oct '01

19 Oct '01

Another question from the documentation: Section 6.12: "GNU Pascal knows Borland Pascal's procedures FillChar and Move. However, their use can be dangerous because it often makes implicit unportable assumptions about type sizes, endianness, internal structures or similar things. Therefore, avoid them whenever possible. E.g., if you want to clear an array of strings, don't `FillChar' the whole array with zeros (this would overwrite the Schema discriminants, see section 8.13.14 BP compatibility: Strings), but rather use a `for' loop to assign the empty string to each string. In fact, this is also more efficient than `FillChar', since it only has to set the length field of each string to zero." What is your recommended fix if you call FillChar on a record, and that record contains the string. Even if you do a for loop to fill the record with 0's, you will still overwrite the schema, correct? Are there any recommended workarounds for that? Thanks, Adam ----------------------------------------------------------------------- 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. -----------------------------------------------------------------------

2 1

installation problems
by Oldham, Adam 19 Oct '01

19 Oct '01

I am using Mandrake Linux with kernel 2.4.8. It had the wonderful version of gcc 2.96 installed on it stock. I've since downgraded to gcc 2.95.3. I've downloaded gpc-20010924, and installed it the regular old way I've installed all the other version of GPC I've gotten the past 2 years. It installs fine, into /usr just like gcc. I can compile files with no problem as well. I compile all my pascal files to only create object files, no other parameters from the command line. When linking all these objects together statically, I get a few errors like this: /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o): In function `_p_Real_Sin': /v/oldham/gcc-2.95.3/gcc/p/rts/rts.c:642: undefined reference to `sin' I get the same thing for the functions cos, log, pow, sinl, cosl, logl, expl, powl, sinh, cosh. I've researched this some, and linking the -lm (math library) while performing my link does not help this. Can anyone help at all with this in particular? Should GPC have linked -lm while it was building? And if so, can someone help me find where that is. I've been looking at this for hours now. Thanks, Adam ----------------------------------------------------------------------- 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. -----------------------------------------------------------------------

3 2

Re: Is this a bug that is planning to be fixed (from documentatio
by Oldham, Adam 19 Oct '01

19 Oct '01

Frank, So, once this bug is fixed, will function declarations in the interface and function bodies in implementation sections of different files be allowed, like they are today? And if not, can the bug sort of be left for compatibility with other Pascal Languages that do utilize this method? Say with maybe a command line parameter? Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 3:00 PM To: gpc(a)gnu.de Subject: Re: Is this a bug that is planning to be fixed (from documentation)? Oldham, Adam wrote: > I have a question about something that is stated below > > "Note that GPC does not yet check whether all interface declarations are > resolved in the same unit. Procedures and functions which are in fact not > used may be omitted, and/or procedures and functions may be implemented > somewhere else, even in a different language. However, relying on a GPC bug > (that will eventually be fixed) is not a good idea, so this is not > recommended." > > In the Programmer's Guide -> Source Structures -> Modules and Unites -> > Units > > > The comment about ..."relying on a GPC bug (that will eventually be > fixed) is not a good idea, so this is not recommended.", what is > the GPC bug and which part of its paragraph does it apply to? That GPC does not yet check whether all interface declarations are resolved in the same unit (like they should by definition of both EP modules and BP units). > 1 - "...Procedures and functions which are in fact not used may > be omitted, " I.e., you can declare a routine, never implement it, and as long as it's not actually called, GPC will not complain (but it should). > 2 - "...Procedures and functions may be implemented somewhere else, > even in a different language." You can declare a routine in the normal way and provide the implementation, say, in a C file. GPC should also complain here, unless you declare them as `external' (which, BTW, is the answer to the problem described; I'll add it to that paragraph in the manual). > I a, a bit confused as to what this bug is. I looked in the list of known > bugs and didn't seem to see anything that directly related to this. I don't find it there either, so I'm adding it now ... 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

Is this a bug that is planning to be fixed (from documentation)?
by Oldham, Adam 18 Oct '01

18 Oct '01

I have a question about something that is stated below "Note that GPC does not yet check whether all interface declarations are resolved in the same unit. Procedures and functions which are in fact not used may be omitted, and/or procedures and functions may be implemented somewhere else, even in a different language. However, relying on a GPC bug (that will eventually be fixed) is not a good idea, so this is not recommended." In the Programmer's Guide -> Source Structures -> Modules and Unites -> Units The comment about ..."relying on a GPC bug (that will eventually be fixed) is not a good idea, so this is not recommended.", what is the GPC bug and which part of its paragraph does it apply to? 1 - "...Procedures and functions which are in fact not used may be omitted, " 2 - "...Procedures and functions may be implemented somewhere else, even in a different language." I a, a bit confused as to what this bug is. I looked in the list of known bugs and didn't seem to see anything that directly related to this. Thanks, Adam ----------------------------------------------------------------------- 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. -----------------------------------------------------------------------

2 1

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 18 Oct '01

18 Oct '01

Correct. Conformant arrays are optional, so that isn't the *real* change to the language ... It is this : When you have a procedure or function (A), as a formal parameter of another procedure or function (B), you must declare it's (A) formal parameters (as shown in example 6 in section 6.11.6 of ISO-10206; there's probably a similar example given in ISO-7185, although haven't looked for it). This (declaring the formal parameter of a formal parameter ;-) wasn't required in the original language definition, in the "User Manual and Report". "Otherwise" was a common and useful extension to the language, but *non-standard*, prior to ISO-10206 (of course, Borland recycled the word "else", just to be different!). Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, October 18, 2001 7:43 AM > To: cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > CBFalconer wrote: > > > > > "Classic" is a perfect description of ISO-7185 (thanks, > Prospero), > > > > since it corresponds exactly (well, with just one change, > suggested > > > > by Wirth) to the language originally defined in the 'User > Manual > > > > and Report' published by Jensen and Wirth, in 1974. > > > > > > What is this one change, BTW? > > > > Conformant arrays. Also some tightening up. The existance of any > > change was a big battle between the US and the world, circa 1980, > > resulting in level 0 and level 1 as a compromise. OTHERWISE was > > in the earlier drafts too. > > Conformant arrays are the only difference between 7185 level 0 and > 1, aren't they? So level 0 is completely equivalent to original > Wirth Pascal? Or did Wirth Pascal contain `otherwise'? > > 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: compiler bug
by da Silva, Joe 18 Oct '01

18 Oct '01

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, October 17, 2001 9:28 PM > To: cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: compiler bug > > CBFalconer wrote: > > > I vote against any such sweeping change. It is enough to say the > > --standard-pascal refers to ISO-1. > > Opinions seem to be divided on what to do. Until and unless there's > an agreement, I'll do nothing about it. ;-) > [Joe da Silva] The best approach, as someone here suggested, is to first introduce a new flag, such as "--classic-pascal", which is equivalent to the present flag "--standard-pascal" flag, with the recommendation to use this new flag to specify ISO-7185. This way, we are no longer (strongly) inferring that ISO-7185 is the only standard. Later, if most people have adopted the new flag, we can drop the old flag or give a warning that the flag is ambiguous. In any case, we can definitely do the first part of this change without adversely affecting anyone, so I see no reason not to proceed at least that far. > > What is the status of the Extended Pascal (10206) standard? Is it > > an official standard, or in the proposed state. I just downloaded > > the postscript version, and that is a monster to handle on this > > machine. Ghostview takes forever, can't backup, etc. > > Yep, they removed the PostScript DSC comments, apparently for no > good reason. I'm probably not allow to distribute a version with > them added again, but the attached script (requires bash and GNU > awk) will do it on your local copy). This will allow gs to backup > and to jump to arbitrary pages. > > > I haven't even the vaguest idea of how to talk to the printer. It > > is a Samsung Laser, which comes with drivers, but not a word about > > the interface at the plug. Can it accept postscript (which is > > really text)? I don't know, but I doubt it. Can it accept text > > with terminal cr/lf, I don't know. Are there ESC sequences to do > > whatever? I still don't know. I can't even find anything from > > their website - it rejected any attempts to download anything > > midway for unknown reasons. Multiple times. Bah humbug. > > > > Compilers are nice and simple. They have a gozinta and a > > comesouta. > > Yeah, I know this problem. Most modern printers (except PostScript > printers which are quite a bit more expensive) have a proprietary > interface and only come with a Windoze driver (and if you're lucky, > a Linux driver), but no documentation of the interface ... > [Joe da Silva] Yes, it's very annoying! Obviously, there aren't enough of us "bugging" the printer manufacturers for this information, so we should pester them some more! On a more positive note, I think a lot of these printers tend to emulate "industry standard" printers/protocols, such as PCL (Hewlett Packard). Since these major printer protocols are "published", you can experiment with these, to see if your particular printer understands them, and to what extent. Not an ideal solution, but sometimes worthwhile. > 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 << File: > ps2dsc >>

2 1

FW: Errors and Standards (was: compiler bug)
by da Silva, Joe 18 Oct '01

18 Oct '01

Oops! Forgot to "fiddle" the send address again ... :-/ > -----Original Message----- > From: da Silva, Joe > Sent: Thursday, October 18, 2001 2:25 PM > To: 'J. David Bryan' > Subject: RE: Errors and Standards (was: compiler bug) > > Such systems as mentioned below, are non-compliant (which is > not surprising I guess, since it took such a long time for the first > official standard to be published). > > Any system that needs to use standard output for reporting errors, > needs to take care of such details transparently, just like systems > which have a separate "output channel" for errors (since there is > no requirement for the programmer to initialize this either, nor any > defined way to do so). > > Joe. > > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Thursday, October 18, 2001 3:53 AM > To: GNU Pascal List > Subject: Re: Errors and Standards (was: compiler bug) > > On 17 Oct 2001, at 10:32, da Silva, Joe wrote: > > > ...Peter Grogono (in his book 'Programming in Pascal') says words to the > > effect of.... > > Regrettably, though, books are not proof but at best only supporting > evidence. Grinding through the standard is the only way to be sure. > > Grogono also notes in section 7.1, "Sequential files," that: > > "Some Pascal systems also insist that the standard file 'output' is > mentioned in the program heading even if the program contains no call > to write, so that there is a destination for error messages." > > -- Dave

1 0

compiler bug
by Theo Carr-Brion 18 Oct '01

18 Oct '01

I am using gpc 20010924 with gcc 2.95.3 on UnixWare 7.1 and the following code does not work. Program Test(Input, Output); Type Str10 = String(10); LetterType = (AA, BB, CC, DD); MyRec = record LetterName: Array[LetterType] of Str10; end; procedure SetIt(var aStr1: String; const aStr2: String); begin aStr1:=aStr2; end; var ThisLetter: LetterType; ThisRec: MyRec; begin for ThisLetter:=AA to DD do SetIt(ThisRec.LetterName[ThisLetter], Chr(Ord(ThisLetter)+Ord('A'))); for ThisLetter:=AA to DD do WriteLn(ThisRec.letterName[ThisLetter]); for ThisLetter:=AA to DD do ThisRec.LetterName[ThisLetter]:=Chr(Ord(ThisLetter)+Ord('A')); for ThisLetter:=AA to DD do WriteLn(ThisRec.LetterName[ThisLetter]); end. The first set of WriteLn commands prints out A and B and then spaces. The second set prints out A to D as expected. Theo Carr-Brion

7 36

Re: Obscure error message
by Theo Carr-Brion 17 Oct '01

17 Oct '01

I was using --stack-checking and turning it off cures the problem, thanks. I am not using optimisation as I was fast compilation times and adding dummy variables did not work so it looks like the problem is in the stack checking. Theo Carr-Brion -----Original Message----- From: J. David Bryan [mailto:dbryan@bcpl.net] Sent: 16 October 2001 19:55 To: GNU Pascal List Subject: Re: Obscure error message On 15 Oct 2001, at 10:42, Theo Carr-Brion wrote: > Compiling some of our software with gpc 20010924 I get the following error > message: > > label `10' used before containing binding contour > > Can anyone explain to me what it means, please? -- Dave

3 2

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