- Gpc - gnu.de

Re: Windows install
by Jay Michael 02 Sep '12

02 Sep '12

Trying to get the source corresponding to the 20070904 Windows distribution, I have downloaded and unpacked gpc-20070904.tar.bz2 mingw-gcc-core-3.4.5-20060117-2-src.tar.gz Between them, they don't seem to be the complete source of the binary distribution I have installed. I can't find any reference to "winmain", which I'm sure is involved in a Windows GUI application. The only version of "collect2" is in the "gcc" chain. It doesn't invoke "windres", and it certainly doesn't say "ld-orig" when it can't find "ld". What do I need to download to be in a position to build GPC under and for Windows?

2 1

running gpc on Mac OS X 10.7.4
by Schneider, Thomas (NIH/NCI) [E] 02 Sep '12

02 Sep '12

gpc folks: I have moved to a new Mac running OS X 10.7.4 and Gnu Pascal now doesn't work: % more h.p program helloworld (output); begin writeln(output,'hello world'); end. % gpc h.p ld: library not found for -lSystemStubs collect2: ld returned 1 exit status Any suggestions on how to fix this? Thanks, Tom Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 http://alum.mit.edu/www/toms

3 6

schema pointer compatibility
by Jay Michael 22 Aug '12

22 Aug '12

Why isn't the address of an object of a schema type an acceptable value for a pointer to the (undiscriminated) schema type? type sptr_type = ^ string ; type sptr_array_type( n : integer ) = array [ 1 .. n ] of sptr_type ; type sptr_array_ptr_type = ^ sptr_array_type ; const s1 = 's1' ; const s2 = 's2' ; const s3 = 's3' ; const slist : sptr_array_type(3) = ( @s1, @s2, @s3 ) ; var slist_ptr : sptr_array_ptr_type = @slist ; t12.pas:23: error: assignment from incompatible pointer type I got the same error when I changed "slist" (the object of the discriminated schema type) from a "const" to a "var". I got the same error when I tried using an assignment statement: var slp : sptr_array_ptr_type ; ... slp := @slist ; If a discriminated instance of a schema type isn't quite the same type as the undiscriminated type, then when would I ever be able to use the address of an object as a value for a pointer to the undiscriminated type? (without coercion, that is)

3 2

Why no schema alias?
by Jay Michael 22 Aug '12

22 Aug '12

type LSTRING = STRING ; t3.pas:8: warning: missing string capacity -- assuming 255 Is there some other syntax to creating an alias of a schema type? On a related note, when I tried type LSTRING( Capacity : INTEGER ) = STRING( Capacity ) ; I got t3.pas:9: error: duplicate field `Capacity' on the attempted type declaration, and again each time I used the new type name. I tried "STRING( LSTRING.Capacity )" and "STRING( .Capacity )". No improvement. type LSTRING( N : INTEGER ) = STRING( N ) ; compiled, and worked almost as well as a true alias. It wouldn't let me pass a string literal as the actual argument to a "const x : LSTRING" parameter.

3 3

file extension case sensitive
by Jay Michael 22 Aug '12

22 Aug '12

The automatic selection of source language based on the extension of an input file seems to be case-sensitive. gpc 20070904, based on gcc-3.4.5 (mingw special) gpc JSM4.PAS gpc: Internal GPC problem: internal option `--amtmpfile' not given gpc JSM4.pas worked fine

2 1

automatic PChar wrong for output param
by Jay Michael 22 Aug '12

22 Aug '12

gpc 20070904, based on gcc-3.4.5 (mingw special) If an array of CHAR is used as the actual argument for a formal parameter declared as "x : PChar", a temporary STRING object is created, the actual argument is copied to the temporary, and the address of the temporary is passed to the subroutine. This is no good when the parameter is a pointer to an output buffer. Using "@s[1]" as the actual argument passes the right address, but if "s" is a STRING, the index "1" is checked, resulting in a RangeCheckError unless the STRING is initialized. I've accepted having to "SetLength" before reading or writing individual characters of the STRING. I didn't expect referring to a character of the STRING in order to get its address to be considered an "access" that would trigger a Range Check. (I planned to set the length of the STRING after the subroutine told me how many characters it had written to the buffer.)

1 0

Re: GPC git
by Waldek Hebisch 02 Aug '12

02 Aug '12

Prof A Olowofoyeku (The African Chief) wrote: > > On 25 Jul 2012 at 16:09, Waldek Hebisch wrote: > > > I wrote: > > > > > Hi Waldek > > > > > > Something is broken under Win32 (compiling with msys environment). > > > This is what I have noticed so far; > > > > > > 1. rts-config.inc is not installed when you run 'make pascal.install' > > > 2. make-lang.inc has "@true" in it. This results in a "command not > > > found" error > > > > > > I will report other problems as I isolate them - but there is a big > > > difference from the release version, in the file sizes when you run > > > 'make pascal.bindist' (about 500kb difference in the tarball size). I > > > will investigate further and will report back in due course. > > > > I have found the issues (under Win32, gcc-3.4.5 backend sources); > > > > 1. "@true" causes an error in 'pascal.install' and 'pascal.bindist', so > > I have removed it. > > > > 2. "rts-config.inc" does not get installed. I believe it is something to > > do with "TREE_GIMPLE_H" definitions. Since I don't fully understand > > TREE_GIMPLE_H, I have manually copied the code that installs the file to > > the relevant section. > > > > 3. The GPC info files are not built or installed. I am yet to find a > > solution to that. > > Solved: I found that the git p/doc/info/ does not contain the .info > files. It only contains a zero-byte file called ".git_is_stupid" ! > > Also, p/doc/generated/ does not contain "gpc-run.1". It also only > contains a zero-byte file called ".git_is_stupid". > > How do I update the git repository? Or will you do it yourself? Sorry, I forgot to mention this: git repository is supposed to contain only source files. So machine generated files like content of p/doc/info/ and p/doc/generated/ is omited. Building gpc should fill those directores with content. But for this you need appropriate tools, in particular 'texinfo' package. Look at the output of 'configure' in build log, if configure can not find needed tools it will print a message and skip building documentation. Git repository does not replace release tarballs -- simply it gives access to code between releases. Content is similar to what 'minimal' gpc tarballs used to contain. Concerning updating git repository: I probably could give write access to persons needing it (I would have to check github instructions). However, more popular method seem to be that developer use GitHub 'fork' feature to create own version and then ask maintainer of main repository to merge changes back to master version. Anyway, for documentation the only thing that needs updating is README -- it should clearly say that you need to have 'texinfo'. BTW: Please keep discussion on the mailing list. One, other folks may have similar problems and learn solution from archived message. Second, others may find good answer earlier. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 3

Re: GPC git
by Waldek Hebisch 01 Aug '12

01 Aug '12

Prof A Olowofoyeku (The African Chief) wrote: > > I wrote: > > > Hi Waldek > > > > Something is broken under Win32 (compiling with msys environment). This > > is what I have noticed so far; > > > > 1. rts-config.inc is not installed when you run 'make pascal.install' 2. > > make-lang.inc has "@true" in it. This results in a "command not found" > > error > > > > I have found the issues (under Win32, gcc-3.4.5 backend sources); > > 1. "@true" causes an error in 'pascal.install' and 'pascal.bindist', so > I have removed it. The line is now: echo "pascal.install done" ; @true Try: echo "pascal.install done" ; true that is remove '@' sign. Note: both lines start from a tab. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 7

string literal as const var parameter
by Jay Michael 24 Jul '12

24 Jul '12

gpc 20070904, based on gcc-3.4.5 (mingw special) I got a compilation error, "type mismatch", when I passed a string literal to a routine with a formal parameter of "const var s : string". In tests, this had been acceptable to the compiler. I find that whether it is acceptable seems to be a function of whether the call is preceded by another call (to a different routine), passing a string literal to (as?) a "const s : string" formal parameter. jsm1bad.pas gets a "type mismatch" compilation error. jsm1ok.pas compiles, links, and executes.

6 10

Re: unit/procedure same name, unhelpful error
by Waldek Hebisch 18 Jul '12

18 Jul '12

Jay Michael wrote: > some of the source when it issues a compilation error? Like > > jsm2.pas:5:jsm2m; > jsm2.pas:5:^---error: expression used as a statement > Currently no such option. > In the test case it's not much more informative than the line number. > In the original code, where the procedure had 5 or 8 arguments, it > would have focused me on the procedure that turned out to also be > a module name. (I spent a lot of time getting the error message=20 > backwards and trying to see if one of the arguments was being affected > by a preprocessor directive that changed it into a procedure call or > other statement where I needed an expression.) > > Does the compiler have enough information to reconstruct the=20 > source representation of the expression it thinks is being used as > a statement? I know there's no limit to how big that could be. > Again, I think it would help to know exactly which source is > upsetting the compiler. > Compiler keeps line numbers of expressions in the input. ATM compiler does not know position of offending item within the input line. Also, the expressions are transformed and what compiler have in hand may be quite different from user input. In principle printing compiler data in Pascal-like form could be of some use, but compiler have no routine for doing this. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0