Gpc

gpc@gnu.de

5400 discussions

Validity check before downcasting / exception handling?
by Markus Gerwinski 18 Mar '01

18 Mar '01

Hello folks! When downcasting object pointers, I often wish there was a way to check the cast before. Peter has already told, in one of the next alpha releases of GPC there will be a new downcast-operator named 'as' firing a runtime error in case of an invalid downcast; like this: ... tBar = object ( tFoo ) ...; ... foo: pFoo; ... with foo^ as tBar do (* if "foo^" isn't a tBar actually, the 'as' *) ... (* interrupts the program with a runtime error. *) Nevertheless I'd like to have a way to check the validity _before_ casting, thus preventing the runtime error in cases where I don't want the program to be interrupted. Currently, I'd suggest the following additional functions in GPC itself: Function getObjectType ( obj: object ): "type"; Function isOfObjectType ( obj: object; runtimeType: "type" ): boolean; Example: ... p: pObject; ... p:= new ( pBar, init ); ... getObjectType ( p^ ) ... (* returns "tBar" *) ... ... isOfObjectType ( p^, pFoo ) ... (* returns "true", since tBar *) (* is derived from tFoo. *) For downcasting, I'd only need the latter one, but the first function seems useful to me, too. Alternatively, I could need a mechanism to absorb the runtime error fired by "as" before it interrupts the program. Something like this: foo: pFoo; ... with foo^ as tBar do ...; catchRuntimeError ( @procedureToHandleRuntimeError, parameters ); Anyway, when implementing a catchRuntimeError mechanism in GPC, it would not seem reasonable to me to just do it for this special kind of runtime error; thus, here we'd need a general exception handling mechanism to catch and handle _any_ runtime error without interrupting the program. Hope this description of my ideas wasn't too confuse... Yours Markus -- http://www.gerwinski.de/~markus/

4 4

Re: Rép. : Re: gpc en Mac OS X.
by Frank Heckenbach 17 Mar '01

17 Mar '01

Blady wrote: > <flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;0L;</param>Hi, > > [...] First of all: Your mail is *very* hard to read because of all these tags (they don't even appear to be HTML... what is it???). Please, when posting to this list, turn off all such tags, and use a reasonable line length (68 or 72 characters), thanks. > <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: undeclared identifier `$f' (first use in this routine) > > <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:650: undeclared identifier `$10' (first use in this routine) > > <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:897: undeclared identifier `$deadbeef' (first use in this routine) Whoa, Borland-style hex numbers are mistaken as identifiers... > then I type this that fix it: > > make CFLAGS="-O -DMACOSX -g -fno-dollars-in-identifiers" I see. The option `--dollars-in-identifiers' enables `$' in identifiers, thereby breaking Borland-style hex numbers. Usually it is off by default, but apparently for some reason it's on by default in Max OS X (perhaps for GCC because there are system routines with `$' in them or something). Well, turning it off, as you did, fixes the problem. I'm now making `-fno-dollars-in-identifiers' the default for GPC on all platforms. General questions: Is this option useful at all? Does someone (or some other Pascal compiler) use `$' in identifiers, so we should retain this for compatibility, or is it just a GCC relic that we can drop? > By default the libm.a library is include in the ld command line so I disable it, since the library is not provided. > > Modifiction of gpc.c : > > << #define MATH_LIBRARY "-lm" > > -- > > > //#define MATH_LIBRARY "-lm" > > > #define MATH_LIBRARY "" AFAIR, the same holds for MS-Windows (at least Mingw, not sure about CygWin). I think the setting of MATH_LIBRARY in ../config/i386/mingw32.h makes sure that -lm is not linked there without haveing to change gpc.c. The same should be possible for Mac OS X, I guess, in the appropriate config file. If you find it, you can send us that change, so we can include it... > 3) link error : > > /usr/bin/ld -arch ppc -dynamic -lcrt1.o /var/tmp/cc0003231.o -lgpc = > -lcc_dynamic -framework System > > /usr/bin/ld: /usr/lib/libgpc.a(error.o) has external relocation entries = > in non-writable section (__TEXT,__text) for symbols: > > _memcpy > > _strlen > > Is there an explanation for that ? It seems to have something to do with GPC using `__builtin_strlen' and `__builtin_memcpy' for some CString operations. Apparently, they don't work well here. Try replacing `__builtin_strlen' (3 times in rts.c) and `__builtin_memcpy' (once in util.c) by simply `strlen' and `memcpy', then rebuild GPC, and let me know if this works. 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

4 5

GNU Pascal Manual
by Clive Rodgers 17 Mar '01

17 Mar '01

A long-standing problem (irritation?) that maybe noone has mentioned is that the index link on every page (that I have tried) takes you to section 9.114 Index (under construction) rather than to section D. GPC Index. Clive ----------------------------------------------------------------------------- Atmospheric, Oceanic and Planetary Physics +44-1865-272905 (desk) Clarendon Laboratory +44-1865-272923 (fax) Parks Road Oxford OX1 3PU c.rodgers(a)physics.ox.ac.uk U.K. http://www.atm.ox.ac.uk/user/rodgers/ MIME, NeXTMail and SunMail attachments welcomed. HTML attachments tolerated Proprietary document formats (especially WORD) binned. Use rtf instead -----------------------------------------------------------------------------

2 1

fail to install gpc on Linux
by Johanna Johnston 17 Mar '01

17 Mar '01

I downloaded gpc-20010315.tar.gz (and per instructions, gcc-2.95.2.tar.gz) and followed the gpc INSTALL instructions with great success, (including "/home/jj/gcc-2.95.1/configure --enable-languages=pascal"and /home/jj/gpc-build/gcc/make) until I came to the install: "make install.pascal" This failed with make: *** No rule to make target `pascal.install'. Stop. I was unable to figure what I had done wrong. Any advice? There is no reference to "pascal" in my Makefile, I don't know where it should come from. My config.status file looks like this: #!/bin/sh # This file was generated automatically by configure. Do not edit. # This directory was configured as follows: /home/jj/gcc-2.95.2/configure --with-gcc-version-trigger=/home/jj/gcc-2.95.2 /gcc/version.c --host=i686-pc-linux-gnu --enable-languages =pascal --norecursion # using "mt-frag" Thank you, Johanna ********************************* * Johanna Johnston * * Bay Computer Associates * * johanna(a)baycomp.com * * http:// www.baycomp.com * *********************************

4 3

Re: const isn't constant?
by Prof. A Olowofoyeku (The African Chief) 17 Mar '01

17 Mar '01

On 16 Mar 2001, at 13:00, Eike Lange wrote: > Hi! > With the following program, I get the error > storage size of 'Bar' isn't constant > Whats wrong? > Is there another way to tell the compiler the storage > size of a const value? > > > program test; > const > Foo : integer = 4; > var > Bar:array[1..foo] of integer; > begin > end. What you have done is to "misuse" an initialized variable as a constant (I think that BP calls them "typed constants"). While that may be accepted (with a warning under GPC) for some uses, it cannot be used as a constant value in declaring data types. Why? Because, as a typed constant, its value can be changed - then what happens to your array? The compiler needs a value that is truly constant (i.e., that cannot be changed) for these purposes. This is what you want; program test; const Foo = 4; var Bar:array[1..foo] of integer; begin end. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.24 for Win32 Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

2 1

PACKED ARRAYS (was Re: Has class become a reserved word?)
by david＠tcs01.demon.co.uk 17 Mar '01

17 Mar '01

In message <20010310012841.A3478(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > David James wrote: > > Have there been any changes in the packing of data in records or > > packed records between 19991030 and 20010306? Or any changes in the > > data transfer between variables and typed files (is that the correct > > name? I mean FILE OF Twhatever, where Twhatever is a TYPE defined in > > the source)? > > I am not aware of any. > > But do not rely too much on such things since they might change, for > instance, when new types of processors show up. My need is that I have FILEs of Twhatever that have been written by executables compiled under GPC 19991030 and I now want to read them using executables compiled under GPC 20010306. Now I'd like to report a difference in this area (actually in the in-memory usage) between GPC19991024 and GPC20010306: The following program: program test9(input,output); const maxnum=4; TYPE T1=RECORD a1:array[1..maxnum] of byte; END; T2=RECORD a2:packed array[1..maxnum] of byte; END; T3=RECORD a3:packed array[1..maxnum] of 0..255; END; T4=RECORD a4:array[1..maxnum] of 0..255; END; begin writeln('t1: ',sizeof(t1):1); writeln('t2: ',sizeof(t2):1); writeln('t3: ',sizeof(t3):1); writeln('t4: ',sizeof(t4):1); end. gives t1: 4 t2: 4 t3: 16 t4: 16 under GPC20010306, and gives 4,4,4,16 under GPC19991030. That is the PACKED ARRAY of 0..255 occupied 4 bytes under the old version and now occupies 16 bytes. Whilst I clearlyu have a workaround by switching from 0..255 to byte, that behaviour doesn't seem right to me. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

4 6

Re: "mallinfo" in GPC?
by Prof. A Olowofoyeku (The African Chief) 16 Mar '01

16 Mar '01

On 16 Mar 2001, at 8:13, Tomasz Kowaltowski wrote: > In gcc one can use the function "mallinfo()" in order to know, among > other things, the amount of dynamic storage currently allocated by the > program through "malloc()". I use it to check for program memory leaks. > > I would like to know whether there is anything similar for gpc? Try "AllocMemSize" in the SYSTEM unit (only in the more recent snapshots). Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro v5.24 for Win32 Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

1 0

const isn't constant?
by Eike Lange 16 Mar '01

16 Mar '01

Hi! With the following program, I get the error storage size of 'Bar' isn't constant Whats wrong? Is there another way to tell the compiler the storage size of a const value? program test; const Foo : integer = 4; var Bar:array[1..foo] of integer; begin end. Eike

1 0

Rép. : Re: gpc en Mac OS X.
by Blady 15 Mar '01

15 Mar '01

<flushleft><fontfamily><param>Helvetica</param><x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;0L;</param>Hi, I bring now more points on my use of gpc on Mac OS X. I use it with gcc 2.95 but I have still some questions. <bold><x-tabstops><param>72L;144L;216L;288L;360L;0L;</param>1) Dollars in error.pas : </x-tabstops></bold><x-tabstops><param>72L;144L;216L;288L;360L;0L;</param> make CFLAGS="-v -O -DMACOSX -g" ... ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -v -O -DMACOSX -g -DRTS_RELEASE_STRING="'`cat /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/rts-version`'" --unit-path=/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts --automake /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas Reading specs from ../.././specs Reading specs from /usr/libexec/ppc/specs Apple Computer, Inc. version cc-2, based on gpc version 20010115, based on gcc-2.95.2 19991024 (release) gcc version 2.95.2 19991024 (release) ../.././gpcpp -lang-pascal -v -I. -famtmpfile=/var/tmp/cc000268 -funit-path=/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts -fautomake -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010115 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__OPTIMIZE__ -g -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -D__STDC__ -D__APPLE_CC__=912 -D__DYNAMIC__ -D__OPTIMIZE__=1 -DMACOSX -DRTS_RELEASE_STRING='20010115' /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas /var/tmp/cc000268.i GNU Pascal Compiler PreProcessor version 20010115, based on gcc-2.95.2 19991024 (release) #include "..." search starts here: #include <<...> search starts here: . /usr/local/include/c++ /usr/local/include /System/Library/Frameworks/System.framework/Headers /usr/include End of search list. ../.././gpc1 /var/tmp/cc000268.i -fforce-mem -Wno-four-char-constants -quiet -dumpbase error.pas -g -O -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -version -famtmpfile=/var/tmp/cc000268 -funit-path=/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts -fautomake -o /var/tmp/cc000268.s GNU Pascal version 2.95.2 19991024 (release) (powerpc-apple-macosx) compiled by GNU C version 2.7.2.1. GNU Pascal version is actually 20010115, based on gcc-2.95.2 19991024 (release) Reading specs from ../.././specs Reading specs from /usr/libexec/ppc/specs Apple Computer, Inc. version cc-2, based on gpc version 20010115, based on gcc-2.95.2 19991024 (release) gcc version 2.95.2 19991024 (release) ../.././gpcpp -lang-pascal -v -I. -fautomake -funit-path=/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts -famtmpfile=/var/tmp/cc000268 -fdelphi-comments -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010115 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__OPTIMIZE__ -g -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -D__STDC__ -D__APPLE_CC__=912 -D__DYNAMIC__ -D__OPTIMIZE__=1 -DMACOSX -DRTS_RELEASE_STRING='20010115' /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/internal.pas -o /var/tmp/cc000271 GNU Pascal Compiler PreProcessor version 20010115, based on gcc-2.95.2 19991024 (release) #include "..." search starts here: #include <<...> search starts here: . /usr/local/include/c++ /usr/local/include /System/Library/Frameworks/System.framework/Headers /usr/include End of search list. Reading specs from ../.././specs Reading specs from /usr/libexec/ppc/specs Apple Computer, Inc. version cc-2, based on gpc version 20010115, based on gcc-2.95.2 19991024 (release) gcc version 2.95.2 19991024 (release) ../.././gpcpp -lang-pascal -v -I. -fautomake -funit-path=/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts -famtmpfile=/var/tmp/cc000268 -fdelphi-comments -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010115 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__OPTIMIZE__ -g -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -D__STDC__ -D__APPLE_CC__=912 -D__DYNAMIC__ -D__OPTIMIZE__=1 -DMACOSX -DRTS_RELEASE_STRING='20010115' /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/string.pas -o /var/tmp/cc000271 GNU Pascal Compiler PreProcessor version 20010115, based on gcc-2.95.2 19991024 (release) #include "..." search starts here: #include <<...> search starts here: . /usr/local/include/c++ /usr/local/include /System/Library/Frameworks/System.framework/Headers /usr/include End of search list. /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas: In function `Returnaddr2hex': <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: undeclared identifier `$f' (first use in this routine) </bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: (Each undeclared identifier is reported only once /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: for each routine it appears in.) /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: subrange bounds are not of the same type /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:642: ordinal type expected /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:643: incompatible types in initialization /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:643: initial value is of wrong type <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:650: undeclared identifier `$10' (first use in this routine) </bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:654: subscripted object is not an array or string /Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas: In procedure `Signalhandler': <bold>/Users/pascal/Documents/GCC2/gcc-2/gcc/p/rts/error.pas:897: undeclared identifier `$deadbeef' (first use in this routine) </bold>make[1]: *** [error.o] Error 1 make: *** [pascal.rts] Error 2 then I type this that fix it: make CFLAGS="-O -DMACOSX -g -fno-dollars-in-identifiers" <bold>2) lib error : </bold> By default the libm.a library is include in the ld command line so I disable it, since the library is not provided. Modifiction of gpc.c : << #define MATH_LIBRARY "-lm" --- > //#define MATH_LIBRARY "-lm" > #define MATH_LIBRARY "" <bold> 3) link error : </bold> [localhost:~/Documents/CC/essais] pascal% more essai.p program Essai; begin Writeln('Hello World again.'); end. [localhost:~/Documents/CC/essais] pascal% gpc -v essai.p Reading specs from /usr/libexec/ppc/2.95.2/specs Reading specs from /usr/libexec/ppc/specs Apple Computer, Inc. version cc-2, based on gpc version 20010115, based on gcc-2.95.2 19991024 (release) gcc version 2.95.2 19991024 (release) gpcpp -lang-pascal -v -famtmpfile=/var/tmp/cc000323 -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010115 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__STDC__ -D__APPLE_CC__=912 -D__DYNAMIC__ essai.p /var/tmp/cc000323.i GNU Pascal Compiler PreProcessor version 20010115, based on gcc-2.95.2 19991024 (release) #include "..." search starts here: #include <<...> search starts here: /usr/local/include/c++ /usr/local/include /System/Library/Frameworks/System.framework/Headers /usr/include End of search list. gpc1 /var/tmp/cc000323.i -Wno-four-char-constants -quiet -dumpbase essai.pas -version -famtmpfile=/var/tmp/cc000323 -o /var/tmp/cc000323.s GNU Pascal version 2.95.2 19991024 (release) (powerpc-apple-macosx) compiled by GNU C version 2.7.2.1. GNU Pascal version is actually 20010115, based on gcc-2.95.2 19991024 (release) /usr/libexec/ppc/as -arch ppc -o /var/tmp/cc0003231.o /var/tmp/cc000323.s /usr/bin/ld -arch ppc -dynamic -lcrt1.o /var/tmp/cc0003231.o -lgpc -lcc_dynamic -framework System /usr/bin/ld: /usr/lib/libgpc.a(error.o) has external relocation entries in non-writable section (__TEXT,__text) for symbols: _memcpy _strlen By this step, I have no more idea. <x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;0L;</param> Is there an explanation for that ? Thank's for your reply, and best whishes for continuation, Pascal Pignard. -------------------------- Le Mardi, Décembre 19, 2000, à 02:36 PM, Frank Heckenbach a écrit : <italic>Hello,</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> thank's for your reply.</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> I choose gpc 2.0 release cause of the background release of my cc that is</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> 2.7.2.1.</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>Yes, this version isn't supported anymore. I.e., you can (probably)</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>compile GPC with gcc-2.7.2.1, but you need the sources of gcc-2.8.1</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>or 2.95.x. Because of increasing internal differences between the</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>gcc versions, we had to drop 2.7.x at some point (and will probably</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>drop 2.8.x sometime next year).</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> I agree with the fact of using the last release then it becomes more</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> difficult to</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> port both cc 2.95 or 3.0 and last gpc.</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> Though, what are the ports on Mac OS X or Darwin (the unix open souce</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>> layer) ?</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>I'm afraid, I'm not aware of any such ports. If the systems are</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>mostly POSIX compliant (I heard Mac OS X is, and I suppose Darwin is</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>as well), and the backend supports the processor (I'm quite sure it</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>does), and the binutils and system libraries and headers are</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>available (I hope they are), it should not be too difficult to</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>compile the current GCC/GPC versions from sources. There may be</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>problems caused by little incompatibilities, but such problems can</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>usually be sorted out rather easily when you post the error</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>messages. I can't say more at this time...</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>Frank</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>-- </italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>Frank Heckenbach, frank(a)g-n-u.de</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>http://fjf.gnu.de/</italic><color><param>0000,0000,0000</param> <italic></italic></color><italic>PGP and GPG keys: http://fjf.gnu.de/plan</italic><color><param>0000,0000,0000</param> <x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</param></x-tabstops></color><x-tabstops><param>28L;56L;84L;112L;140L;168L;196L;224L;252L;280L;308L;336L;</param> </x-tabstops></x-tabstops></x-tabstops></x-tabstops></fontfamily></flushleft> F

1 0

Re: Where to place units from the RTS
by david＠tcs01.demon.co.uk 15 Mar '01

15 Mar '01

In message <64B83BAE.20010309232630.FOO-38E5.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > > > Suppose I have a program that 'uses gpc' (one of the units from the > > GPC RTS). Where should gpc.o and gpc*.gpi be (this is under Linux)? > > And should they have been placed there by the make install when I > > built the compiler? > > > > I'd like to be able to say gpc prog.p and have it automatically find > > the gpc unit at compile time and at link time. At the moment I've > > put gpc.o and gpc*.gpi in the same directory as the program, and am > > specifying gpc.o in the command line, but there must be a neater way > > of doing it ... > > The source of the units should remain in the directory where they're > installed, i.e. <prefix>/lib/gcc-lib/<target>/<gcc-version>/units. That's /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units in my case. > If GPC was built correctly, it should find them there automatically > (try `gpc --print-file-name=units' if not). which shows the directory above. [snip] > --automake > compile units when necessary and link their object files > automatically, so you won't have to specify gpc.o on the command > line Removing gpc.pas, gpc*.o, and gpc*.gpi from my own source directory and using --automake allows the compile and link to succeed. > > --unit-path=DIR:DIR:... > search path for other units, i.e. not those shipped with GPC (they > should be found automatically) and not in the current directory -- I still have a problem here ... for me GPC (20010306) is not finding units in the current directory at link-time. For example: helunit.p ========= unit helunit; interface procedure writeit; implementation procedure writeit; begin writeln('Hello from unit'); end; end. ======== useunit.p ========= program useunit(output); uses helunit; begin writeln('Hello world, and now ... from the unit'); writeit; writeln(' ... and back in main'); end. ======== If I say gpc -c helunit.p and then gpc useunit.p I get: /tmp/cc2caGt51.o: In function `pascal_main_program': /tmp/cc2caGt51.o(.text+0x32): undefined reference to `Writeit' /tmp/cc2caGt51.o: In function `init_pascal_main_program': /tmp/cc2caGt51.o(.text+0x7f): undefined reference to `init_Helunit' collect2: ld returned 1 exit status >From what you say above, I would have expected this to work, and it *did* work with GPC 19991030. Is this the expected behaviour? (I could set --unit-path to include the current directory, but you seem to be saying that should not be necessary.) -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Jump to page:

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