Gpc

gpc@gnu.de

5400 discussions

Problem with linking
by Silvio a Beccara 02 May '02

02 May '02

Hi everybody, I'm trying to write a wrapper unit (called mpichwrap.pas) for the MPICH parallel programming library, with the same aim as for the LAM-MPI. When trying to compile a simple test program, called Prova9, with the command: gpc -L/fastcl/mpich-1.2.2/lib/ prova9.pas -o prova9 gpc is version: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20020318, based on 2.95.2 19991024 (release), running on a Linux machine. I get the following errors: /tmp/ccAmOjTJ1.o: In function `pascal_main_program': /tmp/ccAmOjTJ1.o(.text+0xc6): undefined reference to `MPI_Init' /tmp/ccAmOjTJ1.o(.text+0xdc): undefined reference to `MPI_Comm_size' /tmp/ccAmOjTJ1.o(.text+0xf2): undefined reference to `MPI_Comm_rank' /tmp/ccAmOjTJ1.o(.text+0x157e): undefined reference to `MPI_Barrier' /tmp/ccAmOjTJ1.o(.text+0x18c9): undefined reference to `MPI_Scatterv' /tmp/ccAmOjTJ1.o(.text+0x1bbe): undefined reference to `MPI_Gatherv' /tmp/ccAmOjTJ1.o(.text+0x2464): undefined reference to `MPI_Finalize' /tmp/ccAmOjTJ1.o: In function `init_pascal_main_program': /tmp/ccAmOjTJ1.o(.text+0x248f): undefined reference to `init_Mpichwrap' collect2: ld returned 1 exit status The linking instruction in the wrapper is as follows: {$L mpich} referring to the library libmpich.a It seems that the linker cannot link the object code. All the calls are to library functions. Anyone can help? Thank you in advance, best regards Silvio a Beccara

2 1

Bad "stabs" prevent debugging
by J. David Bryan 30 Apr '02

30 Apr '02

Dear ListFolks, I am unable to set breakpoints, and therefore unable to debug, GPC programs under GDB. The cause appears to be bad debugging information generated by GPC. For example, compiling: program debug (output); var i, j: integer; begin i := 1; j := 2; writeln ('A Pascal test'); writeln ('Variable i is ', i); writeln ('Variable j is ', j) end. with: gpc -g -o debug.exe debug.pas and starting GDB with: gdb debug.exe and then trying to set breakpoints, I see the following: (gdb) break 6 Breakpoint 1 at $4011f2: file <implicit code>, line 6. (gdb) break 8 Note: breakpoint 1 also set at pc $4011f2. Breakpoint 2 at $4011f2: file <implicit code>, line 8. (gdb) break 10 Note: breakpoints 1 and 2 also set at pc $4011f2. Breakpoint 3 at $4011f2: file <implicit code>, line 10. Note that all breakpoints reference the same address. Attempting to start the program gives: (gdb) r Starting program: D:/debug.exe Breakpoint 1, init_pascal_main_program () at <implicit code>:11 11 <implicit code>: No such file or directory. in <implicit code> If I try running "objdump", I see the following: objdump --debugging debug.exe debug.exe: file format pei-i386 Bad stab: Datevalid:(0,21)=@s8;16;,0,8;Timevalid:(0,21),8,8; Year:(0,1),32,32;Month:(0,22)=r(0,1);0000000000001;0000000000014;,64,32; Day:(0,23)=r(0,1);0000000000001;0000000000037;,96,32; Dayofweek:(0,24)=r(0,1);0000000000000;0000000000006;,128,32; [...] Running "objdump" on the object file yields a similar error report. I've reproduced this on several PCs, as follows: * OS: Win95, WinNT4, Win2K * GPC versions: 20011222 (i486-pc-mingw32msvc, 2.95.3) 20020318 (i386-unknown-mingw32 -- the Chief's distro) 20020410 (i486-pc-mingw32msvc, 2.95.3) 20020410 (i686-pc-cygwin, 2.95.3) * GDB versions: 4.18, 5.0, 5.1.1 Is this the same error that is listed in the "Known Bugs" section of the GPC manual as: "...error in debug entries generated for objects" <8F990E3D9A6FD1118F3B0000F81EA1D84985D7(a)exchsa2.dsto.defence.gov.au> -- Dave Bryan

3 4

Question about GPC string type.
by Pierre Muller 29 Apr '02

29 Apr '02

Hi all, I am currently trying to improve GDB pascal support by trying to add support for printing individual chars of a string. (printing the whole strings does work for both compilers). The code that I have works now nicely for Free Pascal, but when I tried to check the code for GPC, I got several bad surprises. test.p var S : string; begin S:='Simple test'; Writeln(s); end. 1) ptyp S where S is a pascal string leads to problems... because the stabs format for the strings is weird... .stabs "S:S(0,46)=s264Capacity:(0,4),0,32;length:(0,4),32,32;_p_schema_:(0,47)=@ s2048;@S;S(0,48)=r(0,1);0000000000001;0000000000400;,64,2048;;",40,0,5,_S Looking into stabsread.c I found out that @S sets is_string to 1, but the fact that after this the type is a S mans that GDB inteprets this as a set type which is transformed into a bitstring type... (you can see this if you use) (gdb) p S._p_schema_ Thus, if I add the missing support for bitstring indexes, I get a true or false printout.... where I would like to have a char output... The problem is that bitstring seems to be the wrong choice here, I understand bitstring as being a packed array of boolean values (probably fortran or modula-2) the correct choice would be to get the compiler to generate an array type instead of a set type after the @S; this would then give a correct TYPE_CODE_STRING type for the _p_schema_ field.... I am now rather clueless about how to add support for this feature for GPC :( PS: I would like to have more feedback about the pascal language support in GDB from all of you. Does noone on this list use GDB? If you ever encounter any pascal language problems in GDB, please report them, I does not read all GPC list mails completely, but I always give more attention if debugger is involved... Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

3 2

WWW upload form
by Frank Heckenbach 29 Apr '02

29 Apr '02

Hi everyone, there is now a WWW upload form at http://gnu-pascal.de/contrib/upload.html If you would like to offer some GPC contributions, you can now upload them via this form. But, of course, other ways are also still possible, e.g. sending the files to me by email. If you'd like to make regular uploads, you might want to contact me about getting your own account. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

1 0

Problem with packed arrays of boolean in gpc20020402
by Martin Liddle 29 Apr '02

29 Apr '02

The following test program demonstrates a problem with packed arrays of boolean defined in a separate unit. What I see is D reported as 0 followed by a segmentation fault. The program works correctly if all the declarations are in the main program. I am using gpc20020402 based on gcc 2.95.2 on Red Hat 7.2 using kernel 2.4.9-31 with an i686 processor. Program PackedAssignTest; Uses mltestu; Var I,J:Integer; APackedBoolean:TPackedBoolean; Begin ARecord.C:=99; ARecord.D:=100; ARecord.PackedBoolean:=APackedBoolean; Writeln('D=',ARecord.D); End. Unit mltestu; Interface Const MaxA=5; MaxB=62; Type TPackedBoolean=Packed Array[1..MaxA] of Packed Array[1..MaxB] of Boolean; TRecord = Record C:Integer; PackedBoolean:TPackedBoolean; D:Integer; End; Var ARecord:TRecord; Implementation End. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

2 2

GPC 2.1 RC 7 released
by Frank Heckenbach 26 Apr '02

26 Apr '02

Hi everyone, GPC version 20020426, the release candidate #7 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020426.tar.gz A diff against RC 6 can be found at http://www.gnu-pascal.de/current/gpc-20020410-20020426.diff.gz The problem when building GPC with `-pipe' (reported by George Shapovalov) is now really fixed (hopefully). A runtime error on `EOLn' when a text file does not end in a newline (reported by Emil Jerabek), an error when declaring a forward pointer to an overwritten type of name `Word' (reported by Carel Fellinger), and a bug with packed array types declared in units (reported by Martin Liddle) have been fixed. The GMP unit now also supports version 4 of the GMP library. The (Delphi compatible) procedures `Initialize' and `Finalize' have been implemented. The GPC homepage is now also available in Croatian (http://www.gnu-pascal.de/index-hr.html). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html

1 0

eoln and eof
by Emil Jerabek 26 Apr '02

26 Apr '02

Hi, the RTS sometimes fails to report EOLn before EOF, when a new-line character is missing in the file. For example, this simple program -------------------- program BufferedInput (Output, F); var F: Text; Buffer: String (100); begin Reset (F); while not EOF (F) do begin while not EOLn (F) do begin Read (F, Buffer); WriteLn ('read: `', Buffer, '''') end; WriteLn ('(end of line)'); ReadLn (F) end; WriteLn ('(end of file)') end. ------------------------- produces ---------------------- Input file `F': test read: `first line' (end of line) read: `second line, with no terminator' ./a.out: attempt to read past end of file `test' (error #454 at 8049c73) ---------------------- on this input (where line 2 doesn't end with <LF>): --------------------- first line second line, with no terminator --------------------- Emil Jerabek

2 3

A bug in gpc?
by j.g.ollason 26 Apr '02

26 Apr '02

Greetings everybody, I think that I have found a bug in gpc. The following program generates what I think is a spurious error...of course I could be mistaken. ------------------- program testzero1(input,output); type seabird= record alive:boolean; tomin:real; end ; var tu:real; i,ndives:integer; cguille:seabird; procedure zero(function target(x:real):real;lox,hix:real;var x:real; var found:boolean); begin end { zero }; function fed(var cbird:seabird;var tu:real):seabird; var found:boolean; function oo1(var t:real):real; begin oo1:=0; end { oo1 }; begin with cbird do zero(oo1,0,10000,tomin,found); fed:=cbird; end ; begin cguille:=fed(cguille,tu); end . ---- The error is: testzero1.p: In function `Fed': testzero1.p:26: type mismatch in argument 1 of `Zero' I don't think that there is an error, especially not the one indicated, but I usually believe the compiler's parser rather than my own. What do you think? Thanks, in advance, John Ollason

3 3

pointer forward decl bug
by Carel Fellinger 26 Apr '02

26 Apr '02

Hai, after porting a few thousand lines I think I spotted the next bug. take this simple program: program err; type pword = ^word; word = boolean; var pw : pword; begin new(pw); pw^ := true; end. This is rejected by gpc with: err.pas: In main program: err.pas:12: incompatible types in assignment But if I swap the order of the pword and word type decl's all's swell. Ofcourse using woord (dutch for word) instead of word solves it too. -- groetjes, carel

7 10

Re: GPC 2.1 RC 6 released
by da Silva, Joe 26 Apr '02

26 Apr '02

I see you have solved the mysterious failures. FWIW, yesterday I created a clean directory and tried "test_run" again, as below, except this time I redirected the output of the first run, as well as the second run. In fact (as you no doubt have also discovered), the first run (of "test_run") produces no failures, only the second run does. I also downloaded 'upx' V1.20 and am very impressed with it! It was able to achieve even better compression of the 210K executable file than either 'gzip' or 'zip', by about 5%. The approximate results are as follows (both compiled with GPC) : hello.c : initial size = 13K after 'strip' = 3K after 'upx' = too small to compress (3K) hello.p : initial size = 550K after 'strip' = 210K after 'upx' = 62K So, the smallest GPC executable, using 'strip' and 'upx', is about 62K, which is tolerable. I haven't yet checked what effect the compiler flags have on this, so there might be some more savings possible. Since 'upx' is also available for DOS, I will probably try it on the DJGPP version of GPC as well ... :-) Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, April 24, 2002 11:09 PM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 6 released > > da Silva, Joe wrote: > > > > > As expected, the "bill.pas" and "confarr9.pas" tests were OK > > > > with the "--automake" option. Although, thinking about it again > > > > now, I'm not sure why the required units for these programs > > > > weren't supplying the "missing" identifiers, since the failures > > > > reported below occurred on the second run of the script file, > > > > so the relevant units would/should have been available in > > > > compiled form. > > > > > > I don't really understand either, and can't seem to reproduce it. If > > > you can give me a recipe how to provoke the problem, starting from a > > > clean test directory, I might be able to say more ... > > > > > [Joe da Silva] > > > > As far as I recall, I simply : > > > > 1. Changed to the (pristine) test directory > > 2. Typed "./test_run" > > 3. Typed "./test_run > results.gpc" > > 4. Extracted the failure details from "results.gpc" > > Ah, now I see. The problem is that several test programs (in > particular, bill.pas and kevin5.pas) used an interface called `Foo', > so foo.gpi compiled from kevin5.pas was included when bill.pas > searched for its interface `Foo' in the 2nd turn. Same with `Test1' > (confarr9.pas and rphil6.pas). I'm renaming these now, to be sure. > > > > Should I add some "magic" variables to protect test_run from being > > > run except via make? > > > > > [Joe da Silva] > > > > Maybe. Or maybe just include a comment at the > > top of "test_run" such as : > > > > "Important : Read the README file first!" > > Since probably not everyone looks into a script before starting it, > I'm doing both ... > > > Hmmm ... so the 13K executable isn't self-contained? > > Not at all. Run `ldd filename' to see the dynamic library > dependencies, or compile with `-static' to get a self-contained > statically linked binary. > > > Does that mean that if this executable were redistributed, > > it might not run, depending on the version of RTS available > > on the recipient machine (assuming the same architecture > > of course)? > > In Pascal, quite likely, unless you distribute the RTS with it. In > C, the problem is less severe, since the interface of libc (C's > "RTS") is more stable. But still, there are enough subtle > differences, especially between different Linux distributions, so I > prefer to distribute any Linux binaries statically linked. YMMV. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/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