Gpc

gpc@gnu.de

5400 discussions

Create DLL
by Danuta Burnicka 04 Aug '99

04 Aug '99

Hello, I have to make 16-bit DLL library under OS/2. The head of the functions in this library must be Pascal-like. Could you help me how to do it. Danuta Burnicka ------------------------------------------ Nicholas Copernicus University Library D.Burnicka(a)bu.uni.torun.pl ul. Gagarina 13, 87-100 Torun, Poland tel: +48 (56) 6114475 http://www.bu.uni.torun.pl ------------------------------------------

3 2

Re: Installation trouble
by Frank Heckenbach 03 Aug '99

03 Aug '99

Dimitrios Bartzos wrote: > I managed to get the mbchar.* files from a newer gcc version and copied > them into the gcc source directory and it looks like we got past that point. > > Well, only to get this: > > ../../xgpc -B../../ -c -Wall -Wpointer-arith -Wmissing-prototypes > -Wmissing-declarations -g -O2 `if [ x@with_shared@ == xyes ] ; then echo -fPIC; > fi` --unit-path=/ece2/eeof/egcs-1.1.2/gcc/p/rts --automake > /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas > /bin/sh: ==: A test command parameter is not valid. > /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas: In function `Ioselect': > /ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas:162: internal error--unrecognizable > insn: > (insn 286 283 288 (set (zero_extract:SI (reg:SI 223) > (const_int 32) > (const_int 0)) > (reg:SI 222)) -1 (insn_list 283 (insn_list 285 (nil))) > (expr_list:REG_DEAD (reg:SI 222) > (nil))) > ../../../egcs-1.1.2/gcc/p/../toplev.c:1385: Internal compiler error in function > fatal_insn > make[2]: *** [files.o] Error 1 > make[2]: Leaving directory `/ece2/eeof/gcc/gcc/p/rts' > make[1]: *** [pascal.rts] Error 2 > make[1]: Leaving directory `/ece2/eeof/gcc/gcc' > make: *** [all-gcc] Error 2 > > In fact I get the warning: > > /bin/sh: ==: A test command parameter is not valid. > > for every pascal source file compiled. > > Now, what? :) Replace `==' by `=' in the makefiles, or get a recent version of bash. ;-) This will be fixed in the next release of GPC. 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

Installation trouble
by Dimitrios Bartzos 03 Aug '99

03 Aug '99

Hello, I was trying to install GNU Pascal on a 9000/735 running HP-UX 10.20. I got egcs-1.1.2 and gpc-19990409. The trouble starts early when I try to apply the patch (with patch -p1 < p/diffs/gcc-egcs-1.1.2.diff, I get: Hmm... Looks like a new-style context diff to me... The text leading up to this was: -------------------------- |Changes for GCC version egcs-2.93.12 for GNU Pascal 2.1 | |Before applying these diffs, go to the directory gcc-egcs-2.93.12 |and use the command | | patch -p1 | |feeding it the following diffs as input. | |*** gcc-egcs-2.93.12/Makefile.in.orig Wed Mar 17 15:22:18 1999 |--- gcc-egcs-2.93.12/Makefile.in Wed Mar 17 15:24:24 1999 -------------------------- Patching file Makefile.in using Plan A... Hunk #1 failed at 2731. Hunk #2 succeeded at 2637 with fuzz 2 (offset -136 lines). 1 out of 2 hunks failed--saving rejects to Makefile.in.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/convert.c.orig Wed Mar 17 15:22:18 1999 |--- gcc-egcs-2.93.12/convert.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file convert.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 289 (offset -8 lines). Hunk #2 succeeded at 327 (offset -8 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/dbxout.c.orig Wed Mar 17 15:22:18 1999 |--- gcc-egcs-2.93.12/dbxout.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file dbxout.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 986 (offset -2 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/expr.c.orig Wed Mar 17 15:22:19 1999 |--- gcc-egcs-2.93.12/expr.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file expr.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 4172 (offset -170 lines). Hunk #2 succeeded at 4839 (offset -21 lines). Hunk #3 succeeded at 4703 (offset -170 lines). Hunk #4 succeeded at 6023 (offset -74 lines). Hunk #5 failed at 6033. Hunk #6 succeeded at 6452 (offset -150 lines). Hunk #7 succeeded at 6635 (offset -72 lines). Hunk #8 succeeded at 7011 (offset -150 lines). Hunk #9 succeeded at 7124 (offset -72 lines). Hunk #10 succeeded at 7171 (offset -150 lines). Hunk #11 succeeded at 7269 (offset -72 lines). Hunk #12 succeeded at 7682 (offset -149 lines). Hunk #13 succeeded at 8038 (offset -120 lines). Hunk #14 succeeded at 11026 (offset -171 lines). 1 out of 14 hunks failed--saving rejects to expr.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/fold-const.c.orig Wed Mar 17 15:22:19 1999 |--- gcc-egcs-2.93.12/fold-const.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file fold-const.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 1230 (offset -231 lines). Hunk #2 succeeded at 4892 (offset -33 lines). Hunk #3 succeeded at 4755 (offset -231 lines). Hunk #4 succeeded at 4960 (offset -33 lines). Hunk #5 succeeded at 4792 (offset -231 lines). Hunk #6 succeeded at 5443 (offset -33 lines). Hunk #7 failed at 6278. 1 out of 7 hunks failed--saving rejects to fold-const.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/function.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/function.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file function.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 461 (offset -40 lines). Hunk #2 succeeded at 473 (offset -40 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/optabs.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/optabs.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file optabs.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 1383 (offset -8 lines). Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/stor-layout.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/stor-layout.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file stor-layout.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 67 (offset 2 lines). Hunk #2 succeeded at 104 (offset 2 lines). Hunk #3 succeeded at 121 (offset 2 lines). Hunk #4 succeeded at 986 (offset -48 lines). Hunk #5 succeeded at 1061 (offset 2 lines). Hunk #6 failed at 1313. 1 out of 6 hunks failed--saving rejects to stor-layout.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/toplev.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/toplev.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file toplev.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 330 (offset -17 lines). Hunk #2 succeeded at 649 (offset -3 lines). Hunk #3 failed at 965. Hunk #4 succeeded at 1077 (offset -50 lines). Hunk #5 succeeded at 3172 (offset -228 lines). Hunk #6 succeeded at 3367 (offset -50 lines). Hunk #7 succeeded at 4232 (offset -388 lines). Hunk #8 failed at 4520. 2 out of 8 hunks failed--saving rejects to toplev.c.rej Hmm... The next patch looks like a new-style context diff to me... The text leading up to this was: -------------------------- |*** gcc-egcs-2.93.12/tree.c.orig Wed Mar 17 15:22:20 1999 |--- gcc-egcs-2.93.12/tree.c Wed Mar 17 15:24:24 1999 -------------------------- Patching file tree.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] y Hunk #1 succeeded at 4965 (offset 12 lines). done And then of course the compilation in unsuccessful with parse (and other) errors in toplevel.c Any idea what might be the trouble? Thanks, Dimitrios. PS. I am not in the list, so please cc me

2 4

Re: Huffman compression comes to GPC!
by Frank Heckenbach 03 Aug '99

03 Aug '99

"Dr A A Olowofoyeku" wrote: > I have just completed work on an Huffman compression unit which now > supports GPC. The unit exports two main (alternative) compression > functions and two decompression functions. The routines are "dead easy" > to use, and the compression ratio compares well with ZIP's "deflate". > > I have tried to make the code portable, and I believe that I have > achieved this (it works fine with TP, BP, Delphi, FreePascal, and GPC). > AFAIK there are no "endian" issues, but I stand corrected. Unfortunately, there seem to be some. Files compressed on a little-endian machine don't uncompress on a big-endian one (or vice versa). Comparing the same file compressed on both kinds of machines shows differences in byte ordering. I don't have the time to study the code throughly enough to say exactly what the problem it, but at first sight, WDBuf might be the problem, since it contains 16-bit words which are written to a file. To solve the problem, of course, you first have to decide if you want the data files to be little or big endian. If they're following some standard, this will be given, otherwise, if you invented the format, it's up to you. Let's assume you want them to be little endian. Convert each element of the buffer to little endian using the ConvertToLittleEndian procedure, e.g.: ConvertToLittleEndian (WdBuf [i], SizeOf (WdBuf [i])) You can do this either immediately after writing the values into the buffer, or before the BlockWrite. You don't need any ifdef for this -- the routine will simply not change the values on a little endian system. Similarly, before reading values from the buffer (e.g. after the BlockRead statements), convert them back using ConvertFromLittleEndian. BTW, if you want to test the changes and don't have access to a big endian system, you might use big endian data files (perhaps only for testing, if you want little endian data files otherwise), i.e. use ConvertToBigEndian and ConvertFromBigEndian instead of ConvertToLittleEndian and ConvertFromLittleEndian, and verify that you can still compress and decompress files correctly. If you need to still compile the code with BP, you can use the following routines which are part of a GPC compatibility unit for BP which will be included in the next GPC release. (Just install the unit below where BP will find it, but GPC won't, then do a `uses GPC' in the code, so BP will use the unit below, and GPC will use its own GPC unit.) Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html unit GPC; interface const Bits_Big_Endian = False; Bytes_Big_Endian = False; Words_Big_Endian = False; Need_Alignment = False; MaxVarSize = $fff0; type SizeType = Word; procedure ReverseBytes (var Buf; Count : SizeType); procedure ConvertFromLittleEndian (var Buf; Count : SizeType); procedure ConvertFromBigEndian (var Buf; Count : SizeType); procedure ConvertToLittleEndian (var Buf; Count : SizeType); procedure ConvertToBigEndian (var Buf; Count : SizeType); function BlockReadLittleEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; function BlockReadBigEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; function BlockWriteLittleEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; function BlockWriteBigEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; implementation procedure ReverseBytes (var Buf; Count : SizeType); var i : SizeType; b : Byte; ByteBuf : array [1 .. MaxVarSize] of Byte absolute Buf; begin for i := 1 to Count div 2 do begin b := ByteBuf [i]; ByteBuf [i] := ByteBuf [Count + 1 - i]; ByteBuf [Count + 1 - i] := b end end; procedure ConvertFromLittleEndian (var Buf; Count : SizeType); begin if Bytes_Big_Endian then ReverseBytes (Buf, Count) end; procedure ConvertFromBigEndian (var Buf; Count : SizeType); begin if not Bytes_Big_Endian then ReverseBytes (Buf, Count) end; procedure ConvertToLittleEndian (var Buf; Count : SizeType); begin if Bytes_Big_Endian then ReverseBytes (Buf, Count) end; procedure ConvertToBigEndian (var Buf; Count : SizeType); begin if not Bytes_Big_Endian then ReverseBytes (Buf, Count) end; function BlockReadLittleEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; var Result : SizeType; begin BlockRead (aFile, Buf, Count, Result); if InOutRes = 0 then ConvertFromLittleEndian (Buf, Count); BlockReadLittleEndian := Result end; function BlockReadBigEndian (var aFile : File; var Buf; Count : SizeType) : SizeType; var Result : SizeType; begin BlockRead (aFile, Buf, Count, Result); if InOutRes = 0 then ConvertFromBigEndian (Buf, Count); BlockReadBigEndian := Result end; function BlockWriteLittleEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; var Result : SizeType; p : Pointer; begin GetMem (p, Count); Move (Buf, p^, Count); ConvertToLittleEndian (p^, Count); BlockWrite (aFile, p^, Count, Result); FreeMem (p, Count); BlockWriteLittleEndian := Result end; function BlockWriteBigEndian (var aFile : File; const Buf; Count : SizeType) : SizeType; var Result : SizeType; p : Pointer; begin GetMem (p, Count); Move (Buf, p^, Count); ConvertToBigEndian (p^, Count); BlockWrite (aFile, p^, Count, Result); FreeMem (p, Count); BlockWriteBigEndian := Result end; end.

3 2

MoreProblems with gpc
by Hernandez Perdomo Juan Carlos 30 Jul '99

30 Jul '99

After of to try "chmod +w *", I continue whith this problem ........ if [ -f libgcc2.ready ] ; then \ true; \ else \ touch libgcc2.ready; \ fi gcc -DGPC -DIN_GCC -DSVR4 -g -DHAVE_CONFIG_H -I. -I. -I./config -c p/mkstemp.c -o p/mkstemp.o p/mkstemp.c:30: system.h: No such file or directory make: *** [p/mkstemp.o] Error 1 And I can't to compile it... bye ---------- Forwarded message ---------- Date: Tue, 8 Jun 1999 18:39:54 +0200 From: Markus Gerwinski <markus(a)gnu.de> Reply-To: markus(a)adrian.gerwinski.de To: Juan Carlos <alu268(a)csi.ull.es> Subject: Re: Problem with gpc Hello, Juan! > patch: 'Makefile.in': Permission denied > ...... Try "chmod +w *". If there are still problems, ask gpc(a)gnu.de. Hope this helps Markus

2 1

Drop C-numbers and multiple compilations per file?
by Peter Gerwinski 29 Jul '99

29 Jul '99

Hello, everybody! Some features of GPC are beginning to cause serious trouble, so I consider to drop them: * Multiple compilations in one file. One source file contains one program and several units, or an interface and an implementation module, or whatever which has more than one `end.' (please note the dot). Hammering this behaviour of GPC into the GCC/EGCS backend is a nontrivial change which I do not expect the GCC steering committee to accept. (They already rejected much less crucial changes.) Thus, removing this feature would probably be necessary for full integration into GCC/EGCS. * C-style numbers. With the --c-numbers switch or the (*$C+*) directive, GPC accepts C-style octal and hexadecimal numbers such as 0755 or 0xdeadbeef. However, this does mess up other parts of the lexical analyzer. Since I do not think that this feature is widely used, I think it is better to remove it rather than "fixing" large parts of the lexical analyzer and thus inviting for more unpleasant errors. * (Other things may follow.) Comments welcome, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ ***

3 4

Re: (no subject)
by Frank Heckenbach 29 Jul '99

29 Jul '99

Adam Naumowicz wrote: > Thanks for answering, > I already have quite new version of the compiler taken from the net. > I noticed that if I try to compile my unit file test1.pas I get a warning: > > c:\gpc\lib/crt0.o(.data+0xc2):crt0.s: undefined reference to 'main' > c:\gpc\lib/libc.a(crt1.o)(.text+0x446):crt1.c: undefined reference to > 'main' > > and a .gpi file is created. Oh yes. This warning is harmless. gpc tries to link the unit to an executable, which, of course, doesn't work. To get rid of the warning when compiling a unit, you can use the -c switch. > When I compile a program using test1 the following error occures: > > c:/gpc/tmp\cceaaaaa(.text+0xad):test.pas: undefined reference to 'First' > > where First is an identifier of a function from test1. > But if i compile my program with --automake switch everything goes all > right. > Do I always have to turn on the build mode ? Yes, you should always use --automake which will cause GPC to recompile all units needed. (There's also --autobuild which will always recompile *all* units, but this shouldn't be necessary.) 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: (no subject)
by Frank Heckenbach 29 Jul '99

29 Jul '99

Adam Naumowicz wrote: > Hello, > I hava a primitive question but please don't be mad at me (you know, > I don't know gpc at all). How to prepare a unit file for using in normal > USES declaration. I did it how I used to with BP, but all I got was error > message from GPC that 'undefined refference' to function from my unit > occured. You do it just like you would in BP. For examples, you can look at the included units in the "units" directory. If you still get errors with your code, please post the relevant code and the exact errors messages you get. Oh yes, and in case you're using the (very old) version 2.0, I'd recommend to upgrade to a recent alpha or beta version (already much more stable than 2.0), available from (though I think units did also work in 2.0): ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/ 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

None
by Adam Naumowicz 29 Jul '99

29 Jul '99

Hello, I hava a primitive question but please don't be mad at me (you know, I don't know gpc at all). How to prepare a unit file for using in normal USES declaration. I did it how I used to with BP, but all I got was error message from GPC that 'undefined refference' to function from my unit occured. Please help me start with GPC. --------------------------------------- Adam Naumowicz e-mail: adamn(a)math.uwb.edu.pl WWW : http://math.uwb.edu.pl/~adamn/ ---------------------------------------

1 0

Installing GPC.
by Alejandro Villarroel 26 Jul '99

26 Jul '99

Hello, I have installed GPC, reading the Faqs, and everything, but maybe I forgot some files or directories. Can somebody tell me about the directory and file structure?, so I can compare and see what file or directory is missing. And how the djgpp.env looks like. Another thing, in my bin direcotry I put some exe files, but I also put the crt0.o file that was on the lib directory, is that necesary, beacuse is the only way that gpc compile my files, also I have to copy the unit (*.pas) files in the bin directory in order to use the units, and I have to compile twice in order to have the unit in an object file (*.o). Becase of that I think some files are missing and/or I have to modify some files. Thanks in advance.

2 2

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