Gpc November 2000

gpc@gnu.de

25 participants
31 discussions

StringUtils, FileUtils
by Frank Heckenbach 31 May '02

31 May '02

Hi, in the current GPC version, I've included a StringUtils unit for general string handling routines (on a higher level than the built-in and RTS routines). Up to now, it only contains routines for a string hash table, but I'm planning to add some more routines. Perhaps some of you also have some routines to contribute (or features to request). Conditions for inclusion into this unit should be, IMHO: - Generally useful (not meant specifically for a certain program or something), - self-contained (not relying on an external library etc.), - new functionality compared to the existing routines (whereas the same or similar functionality under a different interface for compatibility purposes should go into other units, like GPCUtil for compatibility to `Turbo Power' units), - and, of course, compilable with the current GPC version, portable, bug-free, etc. ;-) The same goes for the FileUtils unit which has been there for some months already. 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 10

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

Re: Memory use problem
by david＠tcs01.demon.co.uk 07 May '01

07 May '01

In message <Pine.LNX.4.21.0011240232590.265-100000(a)rusty.russwhit.com> Russ Whitaker writes: > > Hi > > suggestion: a script to take a snapshot of the /proc filesystem > so you can find what's growing > > take a look at > dir /proc > and cat /proc/<ID>/status > or cat /proc/<ID>/maps The application has been running for some 21 hours now, and I've been taking occasional snapshots both of status and maps. status shows VmSize and VmRSS growing. maps shows the end of the rwxp region that starts at 08171000 growing - can I deduce anything more from this? (for example is it likely to be Pascal heap space or something else?). Both status and maps snapshots follow. Any further suggestions will be gratefully received ... status ====== Name: webmake.e State: S (sleeping) Pid: 27006 PPid: 31555 Uid: 500 500 500 500 Gid: 500 500 500 500 Groups: 500 VmSize: 110776 kB VmLck: 0 kB VmRSS: 108340 kB VmData: 107944 kB VmStk: 84 kB VmExe: 1172 kB VmLib: 1360 kB SigPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 800000000000a006 SigCgt: 0000000008094000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 maps ==== 08048000-0816d000 r-xp 00000000 03:07 32300 /var/rally/bin/webmake.e 0816d000-08171000 rw-p 00124000 03:07 32300 /var/rally/bin/webmake.e 08171000-0e9d0000 rwxp 00000000 00:00 0 40000000-40013000 r-xp 00000000 03:05 34138 /lib/ld-2.1.3.so 40013000-40014000 rw-p 00012000 03:05 34138 /lib/ld-2.1.3.so 40014000-40015000 rw-p 00000000 00:00 0 40015000-40016000 r--p 00000000 03:06 94 /usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES 40016000-40017000 r--p 00000000 03:06 96660 /usr/share/locale/en_US/LC_MONETARY 40017000-40018000 r--p 00000000 03:06 96662 /usr/share/locale/en_US/LC_TIME 40018000-40019000 r--p 00000000 03:06 96661 /usr/share/locale/en_US/LC_NUMERIC 4001a000-4001b000 rwxs 00000000 00:00 0 4001b000-4001e000 r-xp 00000000 03:06 96925 /usr/lib/libpanel.so.4.0 4001e000-4001f000 rw-p 00002000 03:06 96925 /usr/lib/libpanel.so.4.0 4001f000-40054000 r-xp 00000000 03:06 96923 /usr/lib/libncurses.so.4.0 40054000-4005d000 rw-p 00034000 03:06 96923 /usr/lib/libncurses.so.4.0 4005d000-40061000 rw-p 00000000 00:00 0 40061000-4007d000 r-xp 00000000 03:05 34156 /lib/libm-2.1.3.so 4007d000-4007e000 rw-p 0001b000 03:05 34156 /lib/libm-2.1.3.so 4007e000-4016b000 r-xp 00000000 03:05 34145 /lib/libc-2.1.3.so 4016b000-4016f000 rw-p 000ec000 03:05 34145 /lib/libc-2.1.3.so 4016f000-40174000 rw-p 00000000 00:00 0 40174000-4017c000 r--p 00000000 03:06 96658 /usr/share/locale/en_US/LC_COLLATE 4017c000-40192000 r--p 00000000 03:06 96659 /usr/share/locale/en_US/LC_CTYPE 40192000-401cc000 rwxs 00000000 00:00 0 401cc000-40292000 rwxs 00000000 00:00 0 bffeb000-c0000000 rwxp fffec000 00:00 0 -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

5 11

Getting started ...
by j.logsdon＠lancaster.ac.uk 22 Dec '00

22 Dec '00

Hi This is always the most difficult part! I am porting a very old Pascal program written originally in Prospero Pro-Pascal and I want to use a (relatively) platform independent compiler. Hence gpc. So a few questions - I have already searched in the info pages (aka the 400+ page manual) and found the answers to some of my questions but: 1 A simple program like: program t(Input,Output); var s:string[20]; begin read(s); writeln(s); end. when compiled (and it works) still gives a message: /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/libgpc.a(randfile.o): In function `do_seek': /home/elug/pascal-wochenende-20000729/gcc-2.95.2/gcc/p/rts/randfile.c:327: the `llseek' function may be dangerous; use `lseek64' instead. I may be running this at the weekend (RH 6.2 but gpc --version gives 2.95.2 19991024 (release) rather than anything like 20000729) but is this possibly an installation problem? 2 Is there a way of taking the command line arguments into a program? eg for a program foo.pas that compiles to a.out, I want to access argument 1 as 'something' in: ./a.out something Is the whole command line available (like $0)? I saw the demo getopt but when I tried to compile this, I was told that it couldn't find GPC (from uses GPC). Does this mean that I haven't installed it properly? gpc is in the default place (/usr/local/bin/gpc etc) Hope my questions are clear TIA John

5 12

strange bug in test gpc20001122 / djgpp
by Maurice Lombardi 06 Dec '00

06 Dec '00

Hi After seing the message of Russ I have also run the tests for this snapshot. (djgpp v2.03 in W98 DOS box). No problem with gpctest.pas (the unmodified one). Two skipped as usual: longr2 (no long real in djgpp OK), fjf165a (no german locale OK). But six failed, whereas last time I did it (one or two month ago IIRC) none failed: fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas After cleaning everything, rebooting (W98 you know), I obtain simplified test by booting bash and running directly test_run as ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >ta i.e. on all failing test program and one successfull test program. The result is GPC-TEST-BEGIN ========================== TEST fieldw.pas: c:/djgpp/tmp\ccbq0vjj1.o: In function `pascal_main_program': fieldw.pas:11: undefined reference to `_p_writestr' fieldw.pas(.text+0x5e): undefined reference to `_p_inoutres' fieldw.pas(.text+0x66): undefined reference to `_p_check_inoutres' fieldw.pas:16: undefined reference to `_p_writestr' fieldw.pas(.text+0xb8): undefined reference to `_p_inoutres' fieldw.pas(.text+0xc0): undefined reference to `_p_check_inoutres' fieldw.pas:18: undefined reference to `_p_stdout' fieldw.pas(.text+0xe3): undefined reference to `_p_write' fieldw.pas(.text+0xec): undefined reference to `_p_inoutres' fieldw.pas(.text+0xf4): undefined reference to `_p_check_inoutres' fieldw.pas:20: undefined reference to `_p_stdout' fieldw.pas(.text+0x116): undefined reference to `_p_write' fieldw.pas(.text+0x11f): undefined reference to `_p_inoutres' fieldw.pas(.text+0x127): undefined reference to `_p_check_inoutres' fieldw.pas:22: undefined reference to `_p_atexit' fieldw.pas(.text+0x182): undefined reference to `_p_initialize' fieldw.pas(.text+0x191): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed TEST fjf101a.pas: c:/djgpp/tmp\ccbycwjj1.o: In function `pascal_main_program': fjf101a.pas:6: undefined reference to `O' fjf101a.pas:7: undefined reference to `K' fjf101a.pas(.text+0x2b): undefined reference to `init_Fjf101au' fjf101a.pas(.text+0x30): undefined reference to `init_Fjf101av' fjf101a.pas(.text+0x3d): undefined reference to `_p_atexit' fjf101a.pas(.text+0x66): undefined reference to `_p_initialize' fjf101a.pas(.text+0x75): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed <snip same for others> TEST abso1.pas: OK ========================== GPC-TEST-END All fail at link stage and this is bogus since all other test succeed to find these functions. I then played with the options by typing e.g. PFLAGS="--autobuild -g -O3 -Wall -Werror" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tb This changes nothing since there are the default PFLAGS. But I found then that things go wrong only if I have exactly _five_ PFLAGS, what they may be (I have always included --autobuild, but tried e.g. -g -g -g -g), and succeed for four or six (or any number I have tried). So I replace the fifth by -v, typing PFLAGS="--autobuild -g -O3 -Wall -v" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tb The output is: GPC-TEST-BEGIN ========================== TEST fieldw.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccaakjgj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -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) -D__OPTIMIZE__ -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./fieldw.pas c:/djgpp/tmp\ccbakjgj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbakjgj.i -quiet -dumpbase fieldw.pas -g -O3 -Wall -version -famtmpfile=c:/djgpp/tmp\ccaakjgj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbakjgj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbakjgj1.o c:/djgpp/tmp\ccbakjgj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbakjgj1.o -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/tmp\ccbakjgj1.o: In function `pascal_main_program': fieldw.pas:11: undefined reference to `_p_writestr' fieldw.pas(.text+0x5e): undefined reference to `_p_inoutres' fieldw.pas(.text+0x66): undefined reference to `_p_check_inoutres' fieldw.pas:16: undefined reference to `_p_writestr' fieldw.pas(.text+0xb8): undefined reference to `_p_inoutres' fieldw.pas(.text+0xc0): undefined reference to `_p_check_inoutres' fieldw.pas:18: undefined reference to `_p_stdout' fieldw.pas(.text+0xe3): undefined reference to `_p_write' fieldw.pas(.text+0xec): undefined reference to `_p_inoutres' fieldw.pas(.text+0xf4): undefined reference to `_p_check_inoutres' fieldw.pas:20: undefined reference to `_p_stdout' fieldw.pas(.text+0x116): undefined reference to `_p_write' fieldw.pas(.text+0x11f): undefined reference to `_p_inoutres' fieldw.pas(.text+0x127): undefined reference to `_p_check_inoutres' fieldw.pas:22: undefined reference to `_p_atexit' fieldw.pas(.text+0x182): undefined reference to `_p_initialize' fieldw.pas(.text+0x191): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed <snip> TEST abso1.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccayplgj -fautobuild -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -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) -D__OPTIMIZE__ -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./abso1.pas c:/djgpp/tmp\ccbyplgj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbyplgj.i -quiet -dumpbase abso1.pas -g -O3 -Wall -version -famtmpfile=c:/djgpp/tmp\ccayplgj -fautobuild -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbyplgj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbyplgj1.o c:/djgpp/tmp\ccbyplgj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbyplgj1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/bin/stubify.exe -v a.out stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: a.out -> a.000 -> a.exe OK ========================== GPC-TEST-END On inspection, in the linking stage (collect2) -lgpc -lm are not inserted in the failing cases, whereas they do are in the successfull case. To check I type (only four PFLAGS) PFLAGS="--autobuild -g -O3 -v" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tc and the result is GPC-TEST-BEGIN ========================== TEST fieldw.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccaaqypj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -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) -D__OPTIMIZE__ -g -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./fieldw.pas c:/djgpp/tmp\ccbaqypj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbaqypj.i -quiet -dumpbase fieldw.pas -g -O3 -version -famtmpfile=c:/djgpp/tmp\ccaaqypj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbaqypj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbaqypj1.o c:/djgpp/tmp\ccbaqypj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbaqypj1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/bin/stubify.exe -v a.out stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: a.out -> a.000 -> a.exe OK <snip> all other succeed and you see that -lgpc -lm are there ! I cannot say more, especially if it is only a gpc bug, of if djgpp plays a role. Hope this helps. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 2

gpc-20001122 test results
by Russ Whitaker 30 Nov '00

30 Nov '00

Hi here's the test results here for latest snapshot: TEST fjf165a.pas: SKIPPED: only for German locale TEST gpctest.pas: 28800 -27900 943841988 True True 1999 1999 11 11 29 29 1 1 2 2 4 19 48 48 False Error in UnixTimeToTimeStamp: TEST regextest.pas: SKIPPED: librx not installed # of GPC tests 1290 # of GPC tests passed 1287 # of GPC tests skipped 2 # of GPC tests failed 1 good that's the best yet Russ

2 1

Re: using C routines in pascal
by Anuradha 28 Nov '00

28 Nov '00

Hello, Thankyou for the response. whe i link the library file, it gives me the following errors. $ gpc -L/usr/local/psql/lib -lbtrvif -DBTI_DEC_UNIX sqlnew2.pas reqsamp1.o: In function `__btrid': reqsamp1.o(.text+0x5e): undefined reference to `Handler' collect2: ld returned 1 exit status $ But a C program compiled like this works well. Can you tell me what the reason could be? Thanks and Regards, Anuradha eike.lange(a)uni-essen.de wrote: > Hi! > > On Mon, Nov 27, 2000 at 04:40:06PM +0530, Anuradha wrote: > > My problem is like this : > > I have the C procedure in a .so file. > > I have the prototype declaration in a header file. > > How should the declaration of the procedure be given in my pas file?What will > > be the types of the parameters(C or pascal)? > > Maybe you want to write a wrapper arround your C-Function: > > mycfunctions.c: > --------------- > #include <whatever you need> > int _p_myfunction(int x) > { > calls the routine, you want to use > ... > return (y); > } > > In your Pascal-Unit > myfunctions.pas: > ---------------- > ... > Interface > > Function myfunction(x : Integer) : Integer; > asmname '_p_myfunction'; > > ... > Implementation > > {$L mycfunctions.c} > {$L a library, where the routine used in _p_myfunction resides} > > Then write your Pascal-Program, using this unit: > myprogram.pas: > -------------- > Program myprogram; > Uses myfunction; > ... > Begin > z := myfunction(33); > End. > > And then call > gpc --automake myprogram.pas -L/path-to/Libs/ > -I/path-to/Includes/ -lused_libs > > If you need some more examples (and a source), > feel free to contact me. > > Eike -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

2 small problems with compiler
by Sven Sahle 27 Nov '00

27 Nov '00

Hi, I use "gpc version 19991030, based on 2.95.2 19991024 (release)" on an Intel-Linux computer (suse 7.0) and have encountered the following problems: 1. When I accidentally have a pascal source code with a uses-statement that includes a unit with the name of the sourcecode file itself I get an endless loop when compiling it with --automake or --autobild. The compiler uses all memory available. example: A file called "test.pas" containing "uses test;" statement. 2. When I upgraded to the above mentioned version of the compiler I got an "Internal compiler error: program gpc1 got fatal signal 11" when I compiled without --autobuild and had old gpi- and object-files around. A more descriptive error message would be nice. Sven -- Z * Sven Sahle (tel ++49 721 8100 1002, fax ++49 721 8100 1139) K * Zentrum fuer Kunst und Medientechnologie M * Lorenzstr. 19, D-76135 Karlsruhe, Germany

2 1

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

Memory use problem
by Martin Liddle 24 Nov '00

24 Nov '00

This is not a bug report but just a heads up to see if anybody else has seen a similar problem. Some of our gpc programs are what I would term as server processes. By that I mean that they are intended to run in the background for several days at a time serving requests that are passed to them in various ways. We have recently realised that these programs are steadily increasing their memory usage with cpu time used such that the system, in the worst case, runs out of swap space. The problem may well be in our own code but we have not yet isolated it. I just wondered if there was any other possible explanation eg something in the run time system or whether anybody else had seen similar problems? Any advice on strategies for isolating the problem would also be appreciated. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324.

3 3

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 November 2000