Gpc September 1999

gpc@gnu.de

44 participants
93 discussions

Re: Re: GPC BUG: Problems with automake and autobuild
by pdietrich＠synstar.de 10 Sep '99

10 Sep '99

Frank, you are right, the problem vanishes when I'm using the "--unit-path=...". Thank you for your advise. Peter Frank Heckenbach <frank(a)g-n-u.de> am 09.09.99 00:05:51 An: gpc(a)gnu.de Kopie: (Blindkopie: Peter Dietrich/SYNSTAR/DE) Thema: Re: GPC BUG: Problems with automake and autobuild pdietrich(a)synstar.de wrote: > If a unit A is included in a USE clause which includes unit B, and B in turn > includes > unit A the compiler gets an error when it tries to compile A again. This is true > with > option --autobuild and option --automake. The error does not occur if all units > are in > the same directory. > Why does the compiler try to recompile A? Since I don't like "circular uses" very much, and therefore don't use them, I don't know exactly how well they're supported now and if there are any bugs. However, a utility which is planned for the nearer future should make their compilation easier... For now, perhaps the problem vanishes if you get the unit-path working and don't need the paths in the source. 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 ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

1 0

Additional linking for 'sin, cos' required?
by Matthias Friedrich 09 Sep '99

09 Sep '99

Hello, with the compiler-options 'gpc --automake -o .....' I get the following error on Solaris2.6 : Undefined first referenced symbol in file sinl maths.o cosl Stroem.o ld: fatal: Symbol referencing errors. No output written... although there is no 'sinl' or 'cosl' in the source code. Are there some special Linking-options (e.g. in C the -l option for mathmatical libraries) that I missed?? Hope, somebody can help me Thanks very much Matthias _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ - Matthias Friedrich - email: mafri(a)ipg.uni-freiburg.de

2 1

Re: GPC BUG: Problems with automake and autobuild
by Frank Heckenbach 08 Sep '99

08 Sep '99

pdietrich(a)synstar.de wrote: > If a unit A is included in a USE clause which includes unit B, and B in turn > includes > unit A the compiler gets an error when it tries to compile A again. This is true > with > option --autobuild and option --automake. The error does not occur if all units > are in > the same directory. > Why does the compiler try to recompile A? Since I don't like "circular uses" very much, and therefore don't use them, I don't know exactly how well they're supported now and if there are any bugs. However, a utility which is planned for the nearer future should make their compilation easier... For now, perhaps the problem vanishes if you get the unit-path working and don't need the paths in the source. 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 BUG? or how to use unit-path
by Frank Heckenbach 08 Sep '99

08 Sep '99

pdietrich(a)synstar.de wrote: > The --unit-path option does not work (or maybe I don't know, how it works). > The following program "mainprog" uses a unit in directory ..\test-units. I > tried: > > gpc --unit-path ..\test\units mainprog.pas There's an `=' missing after the `--unit-path'. (The GNU compilers treat their command-line arguments differently than most other GNU tools, so you can't omit the `=' after long options...) 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 BUG: Problems with automake and autobuild
by pdietrich＠synstar.de 08 Sep '99

08 Sep '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: If a unit A is included in a USE clause which includes unit B, and B in turn includes unit A the compiler gets an error when it tries to compile A again. This is true with option --autobuild and option --automake. The error does not occur if all units are in the same directory. Why does the compiler try to recompile A? Looking at the gpi file I found that only the filename is stored, not the full or relative path name. In the following test case replace A by "windows.pas" and B by "sysutils.pas": C:\Di\gp\uvw>gpc --autobuild -g -O0 --extended-syntax --short-circuit ..\lib\kernel32.a uvw.pas ..\\isidef\\isidefnt.pas:99: warning: identifiers should not contain two adjacent underscores ..\\isidef\\isidefnt.pas:137: warning: identifiers should not start with an underscore ..\\lib\\sysdef.pas:21: warning: identifiers should not start with an underscore ..\\lib\\sysdef.pas:46: warning: identifiers should not contain two adjacent underscores uvw_def.pas:13: module `windows' could not be compiled gpc1.exe: gpc exited with status 1 uvw.pas:44: module `uvw_def' could not be compiled C:\Di\gp\uvw>dir DatentrÃ¤ger in Laufwerk C: hat keine Bezeichnung. DatentrÃ¤gernummer: 18CF-0161 Verzeichnis von C:\Di\gp\uvw 08.09.99 14:37 <DIR> . 08.09.99 14:37 <DIR> .. 08.09.99 14:29 118.175 gpc.gpi 08.09.99 14:29 7.882 gpc.o 08.09.99 14:29 53.174 isidefnt.gpi 08.09.99 14:29 37.585 isidefnt.o 08.09.99 14:29 34.918 sysdef.gpi 08.09.99 14:29 6.140 sysdef.o 08.09.99 14:29 21.989 sysutils.gpi 08.09.99 14:29 13.331 sysutils.o 08.09.99 14:37 3.511 units.txt 08.09.99 13:44 169.401 uvw.pas 08.09.99 12:04 71.933 uvw_def.pas 08.09.99 14:29 19.733 windows.gpi 08.09.99 14:29 5.437 windows.o 15 Datei(en) 563.209 Bytes 683.836.416 Bytes frei C:\Di\gp\uvw>dir ..\lib DatentrÃ¤ger in Laufwerk C: hat keine Bezeichnung. DatentrÃ¤gernummer: 18CF-0161 Verzeichnis von C:\Di\gp\lib 08.09.99 14:18 <DIR> . 08.09.99 14:18 <DIR> .. 16.06.99 12:18 14.286 kernel32.a 16.06.99 12:18 293 kernel32.def 08.09.99 14:04 5.650 paslib.pas 08.09.99 13:58 32.315 ssvlib.pas 08.09.99 13:21 14.523 sysdef.pas 08.09.99 14:18 6.085 sysutils.pas 08.09.99 14:29 5.754 windows.pas 9 Datei(en) 78.906 Bytes 683.840.000 Bytes frei C:\Di\gp\uvw>dir ..\isidef DatentrÃ¤ger in Laufwerk C: hat keine Bezeichnung. DatentrÃ¤gernummer: 18CF-0161 Verzeichnis von C:\Di\gp\isidef 08.09.99 11:57 <DIR> . 08.09.99 11:57 <DIR> .. 21.04.99 11:46 469 iokeywords.pas 08.09.99 13:41 279.742 isidef.pas 21.06.99 12:27 78.592 isidefdt.pas 08.09.99 14:03 31.008 isidefmap.pas 10.06.99 13:28 43.015 isidefmap.pas.uvw 10.06.99 12:22 353 isidefmap_U.PAS 03.06.99 10:00 2.525 isidefmsg.pas 08.09.99 13:32 31.246 isidefnt.pas 17.06.99 15:26 1.388 test_isidef.pas 11 Datei(en) 468.338 Bytes 683.840.000 Bytes frei C:\Di\gp\uvw> Headers of program and units: ----------------------------- PROGRAM uvw ; {$IFDEF __GPC__} {$DEFINE GP} {$ELSE} {$DEFINE BP} {$LONGSTRINGS ON} {$APPTYPE CONSOLE} {$ENDIF} {$B-} USES {$IFDEF BP} Sharemem, Math, FileCtrl, SysUtils, sysdef, isidefnt, uvw_def; {$ELSE} sysutils in '..\lib\sysutils.pas', sysdef in '..\lib\sysdef.pas', isidefnt in '..\isidef\isidefnt.pas', uvw_def; {$ENDIF} -------- UNIT sysutils; INTERFACE USES GPC, windows in '..\lib\windows.pas'; -------- UNIT windows; INTERFACE USES GPC; -------- UNIT sysdef; {$IFDEF __GPC__} {$DEFINE GP} {$ELSE} {$DEFINE BP} {$LONGSTRINGS ON} {$ENDIF} INTERFACE USES {$IFDEF BP} Sharemem, isidefnt; {$ELSE} isidefnt in '..\isidef\isidefnt.pas'; {$ENDIF} -------- UNIT isidefnt; {$IFDEF __GPC__} {$DEFINE GP} {$ELSE} {$DEFINE BP} {$LONGSTRINGS ON} {$ENDIF} INTERFACE USES {$IFDEF BP} Sharemem, Math, FileCtrl, Windows, SysUtils; {$ELSE} GPC, windows in '..\lib\windows.pas', sysutils in '..\lib\sysutils.pas'; {$ENDIF} -------- UNIT uvw_def; INTERFACE USES {$IFDEF BP} Sharemem, Math, sysutils, sysdef, isidefnt; {$ELSE} sysutils in '..\lib\sysutils.pas', sysdef in '..\lib\sysdef.pas', isidefnt in '..\isidef\isidefnt.pas'; {$ENDIF} ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

1 0

GPC BUG? or how to use unit-path
by pdietrich＠synstar.de 08 Sep '99

08 Sep '99

Hello, The --unit-path option does not work (or maybe I don't know, how it works). The following program "mainprog" uses a unit in directory ..\test-units. I tried: gpc --unit-path ..\test\units mainprog.pas where mainprog.pas was: program mainprog; uses gpc, unit1; begin unitvar := 'Test ok'; writeln (unitvar); end. The compiler complained that it could not compile "unit1". Then I tried: gpc --autobuild mainprog.pas where mainprog.pas was: program mainprog; uses gpc, unit1 in '..\test-units\unit1.pas'; begin unitvar := 'Test ok'; writeln (unitvar); end. This worked, but I don't like to put pathnames into source code. Is there a better way to do compilations with units in different directories? Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 ________________________________________________________________________________________ This communication contains information which may be confidential. It is for the exclusive use of the intended recipient. If you are not the intended recipient, please note that any distribution, copying or use of this communication or the information in it is prohibited. If you have received this communication in error, please notify us by email or by telephone on ++49 6151 989 0 and then delete the email and any copies of it.

2 1

WHERE ARE THE INTERFACES - beginners doubt
by Rabay＠passos.uemg.br 06 Sep '99

06 Sep '99

Hi All, i have just installed the binary version of GPascal in a 586 linux machine. When I try to compile some demo, for instance power.pas I get this error message: power.pas :25: module/unit interface 'Gpc' could not be imported It seems a path problem - the compiler can not find any interface modules. Is there a place where they should be? I have read the documentation but I've found no hints. Could someone give me some help? Thanks in advance. Gualberto Rabay Univ. of Minas Gerais - Brazil to: IN:gpc@gnu.de cc: rabay

2 1

Re: Compiling GPC
by Frank Heckenbach 06 Sep '99

06 Sep '99

"Dr A Olowofoyeku" wrote: > Peter Gerwinski wrote: > > >The normal procedure is to type first `./configure' and then > >`make LANGUAGES=pascal' in the GCC directory that contains the > >GPC source in a subdirectory `p'. However I know that mingw32 > >needs special care. > > You are right. For one, there is no such program as "configure". This > must be a Linux thing, or am I missing something here? A configure script comes with the GCC sources (which you need to build GPC, anyway). However, I don't know if it runs under mingw (if bash runs under mingw, there might be a chance)... 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: CStrings getting corrupted on return from Modules.
by Frank Heckenbach 05 Sep '99

05 Sep '99

Just to clarify some points about CStrings which are really confusing... "Kevin A. Foss" wrote: > > Your program is doing exactly what you told it to do You defined a CString > > which begins byte1 = H, > > byte 2 = e, etc., disabled error detection with {$X+} and then called it a > > string: first 4 bytes is capacity, > > next 4 bytes current length, then the string bytes > [...] > > So take out the {$X+} and use functions CString2String and String2CString > > where you need them. > > Yes, this seems to be exactly what I need. Like I said in my original > message it was just a case of me misunderstanding how the different > string types cooperate -- and I mistakenly thought that straight > CString := String assignments worked in a previous gpc version. GPC does in fact support assignments of Pascal strings to CStrings and handles them correctly (i.e., sets the CString pointer to the beginning of the text in the string, not to the capacity field, and adds a #0 terminator). That was not the problem in your program. The problem was that a local variable is assigned to a CString, and the variable vanishes after the function returns, and a CString is only a pointer and therefore does not contain a *copy* of the text, but only points to the variable which is gone. This problem will *not* be solved if you use String2CString -- even though it might appear so, since it works a little different internally, the result is still undefined and could be wrong some day. Correct solutions are e.g. GetMem/FreeMem (or New/Dispose), or declaring the local variable static -- in this case it will not vanish, so the CString will remain valid after the function returns, but only until the local variable is changed (i.e., until the function is called again, in general). Something like this is in fact what some libc routines do, and this is considered quite problematic (more difficult to use from a program, not thread-safe, etc.), therefore also my advice: don't use CStrings here. :-) > Is there a guide to all of the different String functions for > conversion and what not? Not yet, I think, but I as far as CStrings are concerned, String2CString and CString2String should be all that's needed (and the former one only rarely, because of the automatic String 2 CString assignments). Also, the block of functions from CStringLength to CopyCString in the GPC unit deals with CStrings. When calling a routine (of the RTS or of some C library) that expects a CString parameter, don't worry, just pass it a Pascal string :-) -- unless the function will modify the CString, then things get more difficult... 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: Help! Nothing runs
by Frank Heckenbach 05 Sep '99

05 Sep '99

Some days ago, I sent the following message, but it did not seem to arrive for some reason. So, another try, sorry if anyone gets this twice... > > > internal error: duplicate constructor I'm still on vacation, therefore only a short answer. The message is produced by the RTS, but is harmless. You can simply comment it out in one of the files in the rts directory (don't have the sources handy, but you can easily grep for it). This has already been done in the current alpha versions. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 September 1999