Gpc July 2000

gpc@gnu.de

35 participants
109 discussions

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

using C routines in pascal
by Nathalie Jarosz 27 Nov '00

27 Nov '00

Hello all, Is someone could help me about using C routines in pascal? I think I am close to the right solution but I can't manage to get it!... So I will try to summurize all I made until now... 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/ In src, I have compiled com.c, linpack.c and randlib.c and put them in a library lirandlib.a Then, I have move librandlib.a into /usr/local/lib and randlib.h in /usr/local/include. Actually, I would like to use a fonction named "genbet" in the randlib.c. For that, I have made a little program beta.pas: unit beta; interface {$L /usr/local/include/randlib.h} function genbet(x,y:shortreal):shortreal;C; implementation end. and test.pas: uses beta; begin writeln(genbet(100,150)); end. When I compile the first one, the following message appears: Undefined first referenced symbol in file main /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/ 2.95.2/crt1.o ld: fatal: Symbol referencing errors. No output written to beta collect2: ld returned 1 exit status And for the second one: test.p:4: object file `/usr/local/include/randlib.o' not found test.p:4: object file `/usr/local/include/randlib.o' not found "extern float genbet(float aa,float bb)" is in randlib.h and the program is written in randlib.c. I really need your help, Nathalie ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

6 6

Re: test results
by Frank Heckenbach 21 Sep '00

21 Sep '00

Russ Whitaker wrote: > > Could you please post the complete error message (only one if > > they're all the same)? > > edited output to one msg: > > TEST abso1.pas: > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/libgpc.a(randfile.o): > In function `do_seek': > /usr/local/src/gcc-2.95.2/gcc/p/rts/randfile.c:327: > the `llseek' function may be dangerous; use `lseek64' instead. > OK Thanks. I'll look into it. For a quick fix, you can try inserting the line: #undef HAVE_LLSEEK into rts/rts.h, after the line: #include "rts-config.h" This will disable 64 bit file access, until we can do this right. 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 4

Linking Fortran (Lapack)
by Mike Reid 04 Aug '00

04 Aug '00

Dear gpc list, I have tried searching through the archives and my conclusion is that I will have difficulty linking Fortran into my pascal programs on Linux/Intel. However, any clues would be most welcome. This is my situation: I am using the current linux gpc rpms on intel systems (RedHat 6.1) as well as using it on an Alpha. The main thing I'm needing to do with my (rather old) pascal programs involves matrix diagonalization, which is blindingly fast on Alpha with the optimized BLAS and Lapack. On the Alpha (running True64 Unix, i.e. Digital (AKA Compaq :-()) I can link the Fortran routines just fine. However, on intel I can't link the gnu fortran libraries successfully, presumably because gpc is based on one version of gcc and our current g77 is based on another. I don't particularly care about efficiency (the Alpha code is 10x faster due to the optimized matrix libraries) but it would be very useful to be able to develop and check the programs on my Linux boxes. So any clues as to how to just make it run would be very much appreciated. Since the primary platform is the Alpha Lapack/BLAS the obvious alternative of using the C version of Lapack is not really a solution. -- Dr. Michael F. Reid, M.Reid(a)phys.canterbury.ac.nz Physics and Astronomy, University of Canterbury Christchurch, New Zealand. Phone: + 64 3 364 2548 Fax: + 64 3 364 2469

2 1

Re: packed types and comparison operators bugs
by Couperin 31 Jul '00

31 Jul '00

Maurice Lombardi wrote : >> I can't compile this little program : >> -------------------------------------------- >> Program Bug05; >> Const >> XValMax : Byte = 125; >> Type >> T_XVal = Packed 0..XValMax; >> Var >> X : T_XVal = 64; >> Begin >> End. >> -------------------------------------------- >> Here is the output : >> >> Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs >> gpc version 20000727, based on 2.95.2 19991024 (release) >> [...] >> Bug05.pas:8: constant out of range >??? For me it works ??? >I have the same version of the compiler and djgpp I don't understand what happened earlier today : now it compiles without problems. A possible explanation (?) : I write my programs under Windows, in a text editor, I have a lot of programs opened at the same time, and I run GPC in a DOS window : maybe the source wasn't fully saved... (but I made several tries...) He also wrote : > I suppose that you have indeed found a bug. > To understand what is going on I have added a declaration > > var Y: byte absolute X; > > which enables to examine the binary contents of X. > It is the same (at least for x=64) > and all tests work as expected if you replace X by Y > > ??? I made another attempt : I wrote X into a File [ XFile : File Of T_XValue; ] : there is no problem, it wrote a byte with value 64 (40h). But I tried to read this value back into a program [ Read(XFile,X); ], the output is always the same [ 64 < 63 :-( ]. -- "Couperin" Unrelated P.S. Great thanks for your work on GRX. I downloaded it and installed it : everything is fine.

1 0

RE: GRX and gpc
by Mason Ip 27 Jul '00

27 Jul '00

OK, Maurice, my apology; I didn't clean up the old objects before I rebuild the lib. After a clean rebuild of libgrx20X.a, those grx sample app's ( blt_test, modetest, etc) were built OK and run OK. I just ignore my (still) failure to build the dynamic lib. Thank you so much > ---------- > From: Mason Ip > Sent: Thursday, July 27, 2000 11:40 AM > To: 'Maurice Lombardi' > Subject: RE: GRX and gpc > > OK, I put INCLUDE_GPC_SUPPORT=y into makedefs.gnu and rebuilt the > libraries. > The static lib was built OK, the dynamic lib couldn't be built with > numerous un-resolved symbols like these. > > _gr_selectmode 0x930 vdrivers/vd_xwin.o > _gr_selectmode 0x9d4 vdrivers/vd_xwin.o > _XGrWindow 0x4 vdrivers/vd_xwin.o > _XGrWindow 0x8 vdrivers/vd_xwin.o > > Anyway, put the static lib to my gcc lib and used the static lib to buid > those examples, as in: > gpc --automake -g -o blt_test blt_test.pas /opt/gcc-2.95.2/lib/libgrx20X.a > -lX11 > > They still all dumped cores. > > grx-2.3.2/pascal> blt_test > Segmentation Fault (core dumped) > > Have you tried on Sun Sparc? > > ---------- > From: Maurice Lombardi[SMTP:Maurice.Lombardi@ujf-grenoble.fr] > Sent: Thursday, July 27, 2000 10:47 AM > To: Mason Ip > Subject: Re: GRX and gpc > > Mason Ip a Ã©crit : > > > > I used makefile.x11 instead; it had the flag turned on already. > > > > grx-2.3.2> grep INCLUDE_GPC * > > makedefs.gnu:INCLUDE_GPC_SUPPORT=n > > makefile.dj2:ifeq ($(INCLUDE_GPC_SUPPORT),y) > > makefile.dj2:ifeq ($(INCLUDE_GPC_SUPPORT),y) > > makefile.lnx:ifeq ($(INCLUDE_GPC_SUPPORT),y) > > makefile.lnx:ifeq ($(INCLUDE_GPC_SUPPORT),y) > > makefile.x11:ifeq ($(INCLUDE_GPC_SUPPORT),y) > > makefile.x11:ifeq ($(INCLUDE_GPC_SUPPORT),y) > > No the test ifeq in makefile.x11 checks the value of > INCLUDE_GPC_SUPPORT to make a decision. > Since it is set to n (it is only set in makefefs.gnu), it decides > not to include the gpc support. And this cause > problems because two files gpc_init and gpc_test (contained in > grx232/src/bgi) are not compiled / included in the > library libgrx20 > > Hope this helps > > Maurice > >

1 0

closer
by Robert P. Ewing 27 Jul '00

27 Jul '00

Hello, all Thanks for the input. I'm getting very close now. I can compile taste.pas at the command line, but not within RHIDE. At the command line, I give gpc --automake -v -o taste.exe taste.pas -lgrx20 and it works fine. Within RHIDE, I have set options/libraries #0 to [x] grx20, and also [x] Standard Libraries. The message window reads: Compiling c:/djgpp/contrib/grx232/pascal/taste.pas Ignoring Automake options '-I../contrib/grx232/include'; (Using automake options '-L../contrib/grx232/lib/dj2 -I../contrib/grx232/include') taste.pas: undefined reference to Init_grx20 ld returned 1 exit status There were some errors How can I alter RHIDE to give me the full output (-v) on the message screen? That would give me more to work with. Why isn't RHIDE doing as well as the command line? What interfering message is creeping in to spoil the compilation? Or what options do I need to set that I haven't? I checked my djgpp.env file against Maurice's, and except for his name, ours are (and were) identical. An aside for those (!) win9x experts out there: why is the PATH command in the autoexec.bat file ignored? I set path c:\djgpp;c:\djgpp\bin, but when I open a DOS shell and ask for the path, it is c:\; c:\windows; c:\windows\command. (yes, I can feel linux in my future, but not at work :-( ) Toby

2 1

fuller output
by Robert P. Ewing 27 Jul '00

27 Jul '00

Hello, all. Using bash, I can capture the full output :-) I think bash and I are going to be friends. Toby Reading specs from c:/gpc/lib/gcc-lib/djgpp/2.952/specs gpc version 20000725, based on 2.95.2 19991024 (release) c:/gpc/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -famtmpfile=c:/gpc/tmp\ccaan0li -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20000725 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/gpc/lib/../include/sys/version.h -remap taste.pas c:/gpc/tmp\ccban0li.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/gpc/lang/pascal c:/gpcinclude c:/gpc/contrib/grx20/include /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/gpc/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/gpc/tmp\ccban0li.i -quiet -dumpbase taste.pas -version -famtmpfile=c:/gpc/tmp\ccaan0li -o c:/gpc/tmp\ccban0li.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/gpc/bin/as.exe -o c:/gpc/tmp\ccban0li1.o c:/gpc/tmp\ccban0li.s c:/gpc/lib/gcc-lib/djgpp/2.952/collect2.exe -o taste.exe c:/gpc/lib/crt0.o -Lc:/gpc/lib -Lc:/gpc/lib/gcc-lib/djgpp/2.952 -Lc:/gpc/bin -Lc:/gpc/lib c:/gpc/tmp\ccban0li1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/gpc/tmp\ccban0li1.o(.text+0x839):taste.pas: undefined reference to `GrBlack' c:/gpc/tmp\ccban0li1.o(.text+0x841):taste.pas: undefined reference to `GrWhite' c:/gpc/tmp\ccban0li1.o(.text+0x875):taste.pas: undefined reference to `GrTextXY' c:/gpc/tmp\ccban0li1.o(.text+0x904):taste.pas: undefined reference to `GrSetMode' c:/gpc/tmp\ccban0li1.o(.text+0x916):taste.pas: undefined reference to `GrBlack' c:/gpc/tmp\ccban0li1.o(.text+0x91e):taste.pas: undefined reference to `GrWhite' c:/gpc/tmp\ccban0li1.o(.text+0x92f):taste.pas: undefined reference to `GrTextXY' c:/gpc/tmp\ccban0li1.o(.text+0x937):taste.pas: undefined reference to `GrMouseDetect' c:/gpc/tmp\ccban0li1.o(.text+0x947):taste.pas: undefined reference to `GrMouseEventMode' c:/gpc/tmp\ccban0li1.o(.text+0x94f):taste.pas: undefined reference to `GrMouseInit' c:/gpc/tmp\ccban0li1.o(.text+0x954):taste.pas: undefined reference to `GrMouseDisplayCursor' c:/gpc/tmp\ccban0li1.o(.text+0x988):taste.pas: undefined reference to `GrMouseGetEvent' c:/gpc/tmp\ccban0li1.o(.text+0x9cb):taste.pas: undefined reference to `init_Grx20' collect2: ld returned 1 exit status

3 4

RE: GRX and gpc
by Mason Ip 27 Jul '00

27 Jul '00

OK, thanks Peter, they all compiled OK. But .... they all dump cores :( grx-2.3.2/pascal> gpc -v Reading specs from /opt/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20000725, based on 2.95.2 19991024 (release) grx-2.3.2/pascal> modetest Segmentation Fault (core dumped) grx-2.3.2/pascal> vir_test Segmentation Fault (core dumped) grx-2.3.2/pascal> blt_test Segmentation Fault (core dumped) grx-2.3.2/pascal> taste Segmentation Fault (core dumped) grx-2.3.2/pascal> txt_test Segmentation Fault (core dumped) == They were OK when I used an earlier version of gpc. 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) Any clue? -----Original Message----- From: Peter Gerwinski [mailto:peter@gerwinski.de] Sent: Wednesday, July 26, 2000 3:41 PM To: 'gpc(a)gnu.de' Subject: Re: GRX and gpc Mason Ip wrote: > > grx-2.3.2/pascal% gpc -o blt_test blt_test.pas --automake (Or at least --autolink, if you have compiled `grx.pas' manually.) ((Or you can mention `grx.o' and `-lgrx' explicitly on the command line.)) Hope this helps,

1 0

GRX and gpc
by Mason Ip 27 Jul '00

27 Jul '00

I had difficulties compiling the pascal demo files under grx-2.3.2. grx-2.3.2/pascal% gpc -v Reading specs from /opt/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20000725, based on 2.95.2 19991024 (release) grx-2.3.2/pascal% ls *pas blt_test.pas modetest.pas txt_test.pas grx20.pas taste.pas vir_test.pas grx-2.3.2/pascal% gpc -o blt_test blt_test.pas /opt/gcc-2.95.2/lib/libgrx20X.a -lX11 Undefined first referenced symbol in file init_Grx20 /var/tmp/cc7kaWFm1.o ld: fatal: Symbol referencing errors. No output written to blt_test collect2: ld returned 1 exit status grx-2.3.2/pascal% nm /opt/gcc-2.95.2/lib/libgrx20X.a | grep init_Grx20 <-- this return nothing! Basically, non of {blt_test, modest, txt_test, taste, vir_test} were built. I believe that grx-2.3.2 is still not working with the latest gpc :( > From: Maurice Lombardi [Maurice.Lombardi(a)ujf-grenoble.fr] > Sent: Wednesday, July 26, 2000 6:55 AM > To: gpc > Subject: GRX and gpc > Hi all, > I have uploaded to agnes slightly corrected versions of grx-2.3.2 > ftp://agnes.dida.physik.uni-essen.de/home/maurice/grx-2.3.2.tar.gz for unix

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