Gpc July 2000

gpc@gnu.de

35 participants
109 discussions

digest version of mailing list?
by John Oram 07 Jul '00

07 Jul '00

Is there a digest version of this mailing list? I'm looking for a single email once every 24-hour instead of multiple email's per day. Thanks in advance, John Oram Sacramento, CA

2 1

Re:
by Frank Heckenbach 06 Jul '00

06 Jul '00

J. David Bryan wrote: > On 6 Jul 2000, at 16:06, xp2 wrote: > > > The GNU Pascal documentation is also availeble as "pdf", "doc", ASCII file > > or not ? > > As far as I know, the documentation is available only in GNU Texinfo format > as part of the source distribution. You can convert Texinfo to PDF or > Postscript with MiKTeX: It's also available in GNU Info (mostly ASCII, but with markup and cross-references) in source and binary distributions. DVI, PostScript and HTML versions will be made available on the WWW home page starting from the next release. 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

grx-2.3.1 and gpc 20000705
by Mason Ip 06 Jul '00

06 Jul '00

I have some problems compiling some grx-2.3.1 pascal sample test programs using the latest gpc 20000705. My system is Sun Sparc Solaris 7. Currently I have two versions of gpc on my system. A) Old GPC (and GCC) /opt/GCC2951/bin/gpc -v Reading specs from /opt/GCC2951/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/specs gpc version 19991030, based on 2.95.1 19990816 (release) B) New GPC (and GCC) /opt/GCC2952/bin/gpc -v Reading specs from /opt/GCC2952/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gpc version 20000705, based on 2.95.2 19991024 (release) I have fetched GRX (Graphics) source from the URL below. http://www.gnu.de/software/GRX/download/grx-2.3.1.tar.gz. grx-2.3.1 were compiled and (manually) installed to the "Old" and "New" dir's using "Old" and "New" GCC respectively; so far no problem. Problems come when building the sample pascal programs under grx-2.3.1's pascal directory. grx-2.3.1/pascal> ls ./ build-examples* modetest.pas vir_test.pas ../ grx20.gpi taste.pas bgi/ grx20.o txt_test* blt_test.pas grx20.pas txt_test.pas Here I have my tiny script "build-examples" to build the *.pas. grx-2.3.1/pascal> cat build-examples #!/bin/sh for pgm in `echo blt_test modetest taste txt_test vir_test` do echo compiling $pgm echo /opt/GCC2952/bin/gpc -o $pgm $pgm.pas /opt/GCC2952/lib/libgrx20X.a -lX11 /opt/GCC2952/bin/gpc -o $pgm $pgm.pas /opt/GCC2952/lib/libgrx20X.a -lX11 echo ----- done If I use the "Old" gpc from the script (keeping /opt/GCC2952/lib/libgrx20X.a the same), building were OK. With the "New" gpc, *no pascal programs were built*; the following were the script output (see below). I have no idea why the "init_Grx20" sysmol was not resolved by the "New" gpc, using the *same* library (/opt/GCC2952/lib/libgrx20X.a). <-- logging begin ---> compiling blt_test /opt/GCC2952/bin/gpc -o blt_test blt_test.pas /opt/GCC2952/lib/libgrx20X.a -lX11 blt_test.pas:26: type name expected, identifier `Grfont' given blt_test.pas:27: warning: type defaults to `int' in declaration of `F' ----- compiling modetest /opt/GCC2952/bin/gpc -o modetest modetest.pas /opt/GCC2952/lib/libgrx20X.a -lX11 Undefined first referenced symbol in file init_Grx20 /var/tmp/ccsjaOcV1.o ld: fatal: Symbol referencing errors. No output written to modetest collect2: ld returned 1 exit status ----- compiling taste /opt/GCC2952/bin/gpc -o taste taste.pas /opt/GCC2952/lib/libgrx20X.a -lX11 Undefined first referenced symbol in file init_Grx20 /var/tmp/ccXDaydV1.o ld: fatal: Symbol referencing errors. No output written to taste collect2: ld returned 1 exit status ----- compiling txt_test /opt/GCC2952/bin/gpc -o txt_test txt_test.pas /opt/GCC2952/lib/libgrx20X.a -lX11 txt_test.pas:28: type name expected, identifier `Grfont' given txt_test.pas:29: warning: type defaults to `int' in declaration of `F' txt_test.pas: In function `pascal_main_program': txt_test.pas:51: missing `^' in indirect function call txt_test.pas:51: called object is not a procedure or function txt_test.pas:61: assignment from incompatible pointer type txt_test.pas:65: missing `^' in indirect function call txt_test.pas:65: called object is not a procedure or function ----- compiling vir_test /opt/GCC2952/bin/gpc -o vir_test vir_test.pas /opt/GCC2952/lib/libgrx20X.a -lX11 vir_test.pas: In function `pascal_main_program': vir_test.pas:140: called object is not a procedure or function -----

1 0

Re: Calling GNU Pascal procedures from Fortran
by Frank Heckenbach 06 Jul '00

06 Jul '00

Marinier, M. Claude, G. wrote: > I am using GNU Pascal 2.1 (19991030) on Solaris 2.7 from a package. > > I am porting a graphics package from DEC Pascal on VMS to GNU Pascal on > Solaris. The package is used with many Fortran programs. The conversion is > almost complete. All five levels of the package compile and all the Pascal > test programs I have build so far run OK. I cannot get the Fortran test > programs to link. The linker cannot find the graphics package entry > points. For example > > 'undefined reference to init_' > > I have found a lot of information about calling from Pascal but nothing so > far that help me to call from Fortran to Pascal. > > Can someone point me to the appropriate documentation? In the upcoming release, the mechanism for including Pascal code into C programs is changed and documented with examples. For Fortran, it should be similar (if you know how to call C code from Fortran, you should get along -- I don't know Fortran, so I can't give any details). 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

fatal signal 6
by claude.marinier＠dreo.dnd.ca 05 Jul '00

05 Jul '00

Hi, I am trying to port a 3D graphics package from VMS/Alpha with DEC Pascal to Solaris 7 (a.k.a. Solaris 2.7). I have installed version 19990119 of gpc with version 2.8.1 of gcc. I have successfully compiled the first three levels of the graphics package. When compiling level4.pas, I get a 'fatal error 6' message, a .gpi file but no .o file. I systematically trimmed code (whole functions and procedures) off the end of the source file until is compiled. Most of the implementation section was gone at that point. I tried commenting out the same code with '(*' and '*)' with the same result: it compiled. I then tried to remove only the code on the border, i.e. the compilation failed, I removed another procedure, and it compiled; that last procedure is the one I removed from the full source. This was based on the assumption that some code triggered the failure. The compilation failed with the 'offending' code removed. I abandonned that avenue of research. Then I tried gcc debug options. I specifed '-da' and got about a dozen debug files (.sched2 & .dbr were empty). Specifying '-dJ' did not produce the expected .sched2 file. What is the next step? Try using the latest gcc as a base? Use Modules instead of Units? I would need documentation of those. Convert to Modula2? Is this even possible? How different are the languages? Is there a free compiler out there? Switch to C (use p2c, the Pascal to C translator) and abandon Pascal entirely? Help. Thanks. P.S. I joined the list a few minutes ago. To ensure that I get your reply, please 'cc' to me directly. Thanks. -- Claude Marinier, Information Technology Group claude.marinier(a)dreo.dnd.ca Defence Research Establishment Ottawa (DREO) (613) 998-4901 FAX 998-2675 3701 Carling Avenue, Ottawa, Ontario K1A 0Z4 http://www.dreo.dnd.ca

3 7

Re: Internal compiler error - bug
by Frank Heckenbach 05 Jul '00

05 Jul '00

Clyde Meli wrote: > I'm compiling a PASCAL program under Solaris with gpc version > 19991030 based on gcc 2.95.2. > > > gpc --automake sgamain.pas > generate.pas: In function `Prescale': > generate.pas:33: Internal compiler error in `emit_library_call_value', at gcc-2. > 95.2/gcc/calls.c:3198 > Please submit a full bug report. > See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. > gpc1: gpc exited with status 1 > report.pas:9: module/unit `generate' could not be compiled > > The code which caused the problem looks like: > > Procedure Prescale(umax,uavg,umin:real;VAR a,b:real); > { Calculate scaling coefficients for linear scaling } > CONST > fmultiple = 2.0; { fitness multiple is 2 } > VAR > delta:real; { divisor } > Begin > if umin > (fmultiple * uavg - umax) / (fmultiple - 1.0) { Non-Negative Test } > > then > Begin { Normal Scaling } > Delta:=umax-uavg; > a:=(fmultiple - 1.0) * uavg / delta; > b:=uavg * (umax - real(2) {fmultiple} * uavg) / delta; > End else > > > I fixed the problem termporarily by commenting out (fmultiple - 1.0) as it is > equal to 1.0 currently, and by replacing fmultiple in the other > assignment (b:=uavg*(umax- etc.) by real(2) instead. It seems writing the > constant there triggered a problem with the compiler. Indeed, this was a GPC bug that has been fixed meanwhile. According to the `Fixed Bugs' section in the To-Do list <http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html>: 20000503: Sparc: division by reals (fjf237.pas, matt1.pas) or `Round (real_constant)' (chaput1.pas) make the compiler crash <199911040915.KAA11168@@humulus.daimi.au.dk> Unfortunately, there's been no GPC release since 2000-05-03, so please either wait for the next release, or use the type-casting workaround in the first assignment as well (this should work, I think -- can't verify it, since my development compiler doesn't have this bug anymore): a:= (Real (fmultiple) - 1.0) * uavg / delta; 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 4

Re: beta distribution
by Nathalie Jarosz 05 Jul '00

05 Jul '00

>From: Frank Heckenbach <frank(a)g-n-u.de> >To: gpc(a)gnu.de >Subject: Re: beta distribution >Date: Wed, 5 Jul 2000 13:22:37 +0200 > > >You need to link the C code. For a simple C file, you can insert > > >`{$L foo.c}' into the unit, and GPC will automatically compile the C > > >file. For a library libbar.a, you can use `{$L bar}' in the source > > >which is equivalent to `-lbar' on the command line. > > > > I am not sure to understand. Do I have to put {$L randlib.c} in beta.p >like > > this: > >If you have a self-contained file randlib.c. If randlib.c requires >other C files, say baz.c, add `{$L baz.c}' as well. However, if you >have librandlib.a instead, read on. > > > unit beta; > > interface > > {$L randlib.c} > > function genbet(x,y:shortreal):shortreal;C; > > implementation > > end. > > > > and keep my program called 'test' like this: > > > > program betadev; > > uses > > beta; > > begin > > writeln(genbet(100,150)); > > end. > > > > and after if I compile the first one, the following message appears: > > beta.p:5: file `randlib.c' not found > > > > and for the second one: > > Undefined first referenced > > symbol in file > > genbet /var/tmp/cc5OaGYv1.o > > ld: fatal: Symbol referencing errors. No output written to test > > collect2: ld returned 1 exit status > > > > When you say "For a library libbar.a, you can use `{$L bar}' in the >source > > which is equivalent to `-lbar' on the command line.", what is the source >in > > this case? > >GPC doesn't care. For libraries, it expects them to be compiled >already. I.e., if you have librandlib.a (a compiled library), add >`{$L randlib}' in the Pascal source. > >If you have the sources for librandlib, compile them first >(according to the (hopefully) accompanying instructions), to get >librandlib.a (or librandlib.so, a shared library, which can also be >used by `{$L randlib}'). So I will try to summurize all steps I made before still trying to be understood... At first, I have downloaded randlibc-1.3.tar.gz. After having unpacked this file, a randlib.c directory was created and it contains: HOWTOGET* README* doc/ src/ test/ I have received help from Maurice Lombardi to install this randlib routines: ------------------------------------------------------------------ > >From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> > >To: Nathalie Jarosz <jarosz_n(a)hotmail.com> > >CC: gpc(a)gnu.de > >Subject: Re: beta distribution > >Date: Fri, 30 Jun 2000 16:24:07 +0200 > > > >Have you read these two text files and those contained in the doc folder >? > >Usually they contain > >instructions on whet do do to install the package. >Yes of course but nothing clear to me: > > INSTALLATION > >Directory src contains the C source for most of the routines. The >files com.c and randlib.c constitute RANDLIB. The file randlib.h >contains prototypes for the RANDLIB routines that should be used (and >not for a few internal routines). The C code from these directories >should be compiled and placed in a library. Directory test contains >three test programs for this code. The file randlib.h in directory >test is a copy of that in src. > > >Where have you gotten randlibc-1.3.tar.gz from ? >I get from: >http://odin.mdacc.tmc.edu/anonftp/page_2.html#RANDLIB Well it is simple enough to be made by hand (there are no dependencies). With GNU tools type: cd src gcc -c -O2 com.c gcc -c -O2 linpack.c gcc -c -O2 randlib.c # ^uppercase: meand Optimize # at this point you have created com.o linpack.o randlib.o # to put them in a library librandlib.a type: ar -rv librandlib.a com.o linpack.o randlib.o ranlib librandlib.a # ^ no d: it is a system function #then move librandlib.a into a system wide library directory e.g. /usr/local/lib # randlib.h include /usr/local/include #to check the result cd ../test gcc -O2 -o tstbot tstbot.c -lrandlib ^lowercase: means output ./tstbot #etc..." ----------------------------------------------------------------------- So I did all this but I still don't understand how to use the famous betadev function I would like to use in a pascal program and which is in these randlib routines written in C... Thanks in advance for your help, Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

Re: beta distribution
by Nathalie Jarosz 05 Jul '00

05 Jul '00

>From: Frank Heckenbach <frank(a)g-n-u.de> >To: gpc(a)gnu.de >Subject: Re: beta distribution >Date: Fri, 30 Jun 2000 20:35:04 +0200 >You need to link the C code. For a simple C file, you can insert >`{$L foo.c}' into the unit, and GPC will automatically compile the C >file. For a library libbar.a, you can use `{$L bar}' in the source >which is equivalent to `-lbar' on the command line. I am not sure to understand. Do I have to put {$L randlib.c} in beta.p like this: unit beta; interface {$L randlib.c} function genbet(x,y:shortreal):shortreal;C; implementation end. and keep my program called 'test' like this: program betadev; uses beta; begin writeln(genbet(100,150)); end. and after if I compile the first one, the following message appears: beta.p:5: file `randlib.c' not found and for the second one: Undefined first referenced symbol in file genbet /var/tmp/cc5OaGYv1.o ld: fatal: Symbol referencing errors. No output written to test collect2: ld returned 1 exit status When you say "For a library libbar.a, you can use `{$L bar}' in the source which is equivalent to `-lbar' on the command line.", what is the source in this case? Thanks in advance, Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

Re: beta distribution
by Frank Heckenbach 05 Jul '00

05 Jul '00

Nathalie Jarosz wrote: > >You need to link the C code. For a simple C file, you can insert > >`{$L foo.c}' into the unit, and GPC will automatically compile the C > >file. For a library libbar.a, you can use `{$L bar}' in the source > >which is equivalent to `-lbar' on the command line. > > I am not sure to understand. Do I have to put {$L randlib.c} in beta.p like > this: If you have a self-contained file randlib.c. If randlib.c requires other C files, say baz.c, add `{$L baz.c}' as well. However, if you have librandlib.a instead, read on. > unit beta; > interface > {$L randlib.c} > function genbet(x,y:shortreal):shortreal;C; > implementation > end. > > and keep my program called 'test' like this: > > program betadev; > uses > beta; > begin > writeln(genbet(100,150)); > end. > > and after if I compile the first one, the following message appears: > beta.p:5: file `randlib.c' not found > > and for the second one: > Undefined first referenced > symbol in file > genbet /var/tmp/cc5OaGYv1.o > ld: fatal: Symbol referencing errors. No output written to test > collect2: ld returned 1 exit status > > When you say "For a library libbar.a, you can use `{$L bar}' in the source > which is equivalent to `-lbar' on the command line.", what is the source in > this case? GPC doesn't care. For libraries, it expects them to be compiled already. I.e., if you have librandlib.a (a compiled library), add `{$L randlib}' in the Pascal source. If you have the sources for librandlib, compile them first (according to the (hopefully) accompanying instructions), to get librandlib.a (or librandlib.so, a shared library, which can also be used by `{$L randlib}'). 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:
by Nathalie Jarosz 05 Jul '00

05 Jul '00

>From: Frank Heckenbach <frank(a)g-n-u.de> >To: gpc(a)gnu.de >Subject: Re: >Date: Tue, 4 Jul 2000 19:33:48 +0200 > > Here is the routine which is involved: > > > > function travel(djk:real;md:mat;A:minitable;Ak:real;ns,j:integer):real; > > {probability of an individual leaving patch j to reach patch k} > > const > > alpha = 4.910; > > zim = 0.263; > > lambda = 0.175; > > var > > Sj,t : real; > > begin > > Sj:=connect(md,A,ns,j); > > t:=(exp(-alpha*djk)*pow2(Ak,zim))/((lambda/Sj)+Sj); > > travel:=t; > > end; > >This is exactly the same GPC bug that Clyde Meli has just reported. >As I wrote last night, this bug has been fixed meanwhile. According >to the `Fixed Bugs' section in the To-Do list ><http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html>: > >20000503: Sparc: division by reals (fjf237.pas, matt1.pas) or >`Round (real_constant)' (chaput1.pas) make the compiler crash ><199911040915.KAA11168@@humulus.daimi.au.dk> > >(Sparc is the processor used in Sun's machines.) > >Until there is a new GPC release with this bug fixed, you can work >around by type-casting the constants to Real: > >const > alpha = Real (4.910); > zim = Real (0.263); > lambda = Real (0.175); Ok, but I need these true values, so?... Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

2 1

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 2000