Gpc

gpc@gnu.de

5400 discussions

dos and intr
by Opie Pecheux 02 Dec '99

02 Dec '99

Hi, I use the Pascal gnu on a PC-i386 machine (with rhide), with gpc-19990430-i386-pc-djgppv202 (i have the same problem with the version 19990813 or 19991030). I want to use the function intr, but in the dos unit, there is only a comment about it and i didn't find the definition. For now, i use my own intr with a asmname ?__dpmi_int', but i want to know if there is a unit how do this. Second question: how can i access directly to the screen (address a0000)? Thanks. Opie

2 1

Re: Problem with strings in record imported/exported from/to modules
by Frank Heckenbach 26 Nov '99

26 Nov '99

David James wrote: > Thank you, that seems to do everything I need at present. I can see I > need to read gpc.pas more carefully to see what other nice features > are in there. :-) And we should document them better... 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: CRT Unit
by Frank Heckenbach 26 Nov '99

26 Nov '99

Opie Pecheux wrote: > Now, the curse23.zip file have disappeared, and i recommend > pdcurs24.beta.zip . At first i install pdcurs24 on my pc, and it was > working. But i didn't delete all my files before. > If i try to install from the beginning, i have the message "curspriv.h: > no such file or directory (ENOENT)." with rhide or in line. Oh yeah... I used curspriv.h in some GPC versions, but not in the current one, so I didn't notice the problem when I uploaded pdcurs24. So, in order to use pdcurs24 you have two choices: - Get the most recent GPC alpha (though I'm not sure if there are DJGPP binaries available), or - get curspriv.h from the PDCurses sources (ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/libs/pdcurs24.beta.22-May-99.zip) > What we have to do? I send all the file at the end. Note: i don't know > how to use -v in gpc, all the messages go on the screen. How can i get > them in a file? DJGPP contains the redir utility for that purpose, e.g.: redir -eo gpc -v ... > logfile (But the screen dump below is also fine, apart from the line breaks...) 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: test results
by Frank Heckenbach 26 Nov '99

26 Nov '99

"Dr A Olowofoyeku" wrote: > > > dialec3.pas failed > > IIRC this is okay under Cygwin but fails under Mingw, with > complaints about undefined references to 'pipe' and 'fork' (or > something like that - Frank will remember because I reported the > problem to him (it was an RTS problem)). dialec[356] basically test all units (only for compileability). The pipe/fork problem occurred under mingw, in this case the problems reported were: : /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function : `_p_pipe': : /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): : multiple definition of `_p_pipe' : pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first : defined here : /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in : /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o Which means that GPC does not always recognize differently written identical file names... 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: Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 26 Nov '99

26 Nov '99

In message <0CE9572A.19991123110923.FOO-4A5F.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > [snip] > > However what I really want to do is to put this record into shared > > memory, so I moved to daj4u and dajunit4, attached. This fails. > > [snip] > > My question is really what is the recommended way to do this: is it > > to set the string's capacity, or should I be calling some other > > function to initialise the record proerly after I shmat the shared > > memory? I assume that new(record_pointer) is initialising string > > capacities within the record, somehow. > > Oh, I see. That's a completely new thing, something which hasn't > been tried with GPC yet. So, let's see, what would be a good > solution here... > [snip > - You could use some lower-level hooks into GPC's memory manager. > These hooks already exist in the gpc unit (originally introduced > to implement some BP compatible stuff in the system unit). They > allow you to redirect any raw memory de-/allocations to > user-defined routines, while GPC will still do all the > initializations of strings, schemata, files, objects, etc. Thank you, that seems to do everything I need at present. I can see I need to read gpc.pas more carefully to see what other nice features are in there. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

test results
by Russ Whitaker 25 Nov '99

25 Nov '99

Hi Frank Ran make in directory test today: These failed: constovfl.pas failed: failed 0 dialec3.pas failed fjf149.pas failed: 64 fjf83.pas failed: Failed goto4.pas failed These Err messeges appeared just before dialec3.pas: /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function `_p_pipe': /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): multiple definition of `_p_pipe' pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first defined here /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o collect2: ld returned 1 exit status /tmp/cc0y2DBt.s: Assembler messages: /tmp/cc0y2DBt.s:110: Error: operands given don't match any known 386 instruction Are the results what you expected? Thanks, Russ

2 1

Re: test results
by Frank Heckenbach 25 Nov '99

25 Nov '99

"Russ Whitaker" wrote: > Hi Frank > > Ran make in directory test today: > > These failed: > > constovfl.pas failed: failed 0 > dialec3.pas failed > fjf149.pas failed: 64 > fjf83.pas failed: Failed > goto4.pas failed > > These Err messeges appeared just before dialec3.pas: > > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function > `_p_pipe': > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): > multiple definition of `_p_pipe' > pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first > defined here > /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o > collect2: ld returned 1 exit status > /tmp/cc0y2DBt.s: Assembler messages: > /tmp/cc0y2DBt.s:110: Error: operands given don't match any known 386 > instruction > > > Are the results what you expected? Not really. Generally, we expect all tests in that directory to succeed. But I'll have to leave this to Peter who can tell if these are new bugs or only problems in connection with the new GCC versions... 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: test results
by Peter Gerwinski 25 Nov '99

25 Nov '99

"Russ Whitaker" wrote: > > constovfl.pas failed: failed 0 > fjf83.pas failed: Failed > goto4.pas failed These are "known bugs" in a GPC that works with gcc-2.95.x. I did not move them to the `knownbugs' subdirectory because I was hoping to have them fixed within days after the alpha release. :-I > fjf149.pas failed: 64 This is not really a bug but a change in the way `BitSizeOf' works. I am still unsure wheter we should keep the current behaviour, so I did not yet adapt the test program. > dialec3.pas failed This one should not occur - and does not occur on all systems I have access to. > These Err messeges appeared just before dialec3.pas: > > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o: In function > `_p_pipe': > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o(.text+0x0): > multiple definition of `_p_pipe' > pipec.o:/usr/local/src/gcc-2.95.2/gcc/p/test/./../units/pipec.c:40: first > defined here > /usr/bin/ld: Warning: size of symbol `_p_pipe' changed from 490 to 599 in > /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/units/pipec.o > collect2: ld returned 1 exit status Very strange. It seems as if the test compilation uses `pipec.c' twice from two different directories. It would be useful to see the output of `gpc -v' here, but currently I cannot promise to handle it with high priority. :-( Sorry for that.) > /tmp/cc0y2DBt.s: Assembler messages: > /tmp/cc0y2DBt.s:110: Error: operands given don't match any known 386 > instruction Doesn't this belong to `goto4'? Peter -- http://home.pages.de/~Peter.Gerwinski/ - G-N-U GmbH: http://www.g-n-u.de Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 GnuPG key fingerprint: 9E7C 0FC4 8A62 5536 1730 A932 9834 65DB 2143 9422 keys: ftp://ftp.gerwinski.de/pub/keys/ - AntiSpam: http://spam.abuse.net

2 1

binaries for gpc on win98/NT platforms
by Scott Brown 24 Nov '99

24 Nov '99

I'm having trouble getting GPC up and running on my home pcs. It would make things very much easier if I could get some binaries instead of source code (as I haven't got the c/c++ compiler either!). Does anyone know where I can find a download site for such things? Do they even exist? Thanks. Scott.

2 1

Re: CRT Unit
by Frank Heckenbach 24 Nov '99

24 Nov '99

"Ariel Bendersky" wrote: > > Did you install the required libraries (see the comments in the CRT > > unit)? > > I have just installed the pdcurse, but the version 2.4, because I > haven't found the 2.3. Anyway, it still gives the same error. 2.4 is fine. The comment referring to 2.3 was a little old (I'll change it). > > Which system do you use? In the case of Dos, you might need to use > > --autobuild because of the automake bugs. > > I'm on DOS, with djgpp. And I tried with the --autobuild, but I still > get the same error. Or in some cases I get a "cannot compile CRT > unit". That's strange. I can reproduce the problem under DJGPP with --automake, but it vanishes with --autobuild. To be sure, please remove all compiled crt*.o and crt*.gpi files once and try again. Did you try it on the command line, or only under rhide? If it works on the command line, but not in rhide, you'll have to edit rhide's settings (this was discussed on this list some time ago, but if you don't have the mails, I could find them). If it doesn't work on the command line either, please compile with `-v' (verbose), and send a complete log of the output. 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

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