- Gpc - gnu.de

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 16 Feb '05

16 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > > C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1552: > > undefined reference to `closedir' make[2]: *** [binobj.exe] Error 1 > > make[1]: *** [pascal.utils] Error 2 make: *** [all-gcc] Error 2 > I remember seeing this problem before. You're nearly there :) :-) > The problem (IIRC) is solved either by having os-hacks.h > (http://www.gnu-pascal.de/contrib/chief/win32/os-hacks.h) in your > "/mingw/include" directory when configuring and building the > compiler, Well, that didn't work so far... I downloaded the file into C:\MinGW\include and ran "make clean", "make distclean" on my gcc distribution before starting again with "./configure --enable-languages=pascal". I ended up with the same error message. > or (more likely), in having libmingwex.a linked to your > program. This however should be happening automatically (i.e., > linking libmingwex.a). > > What is the output of "gcc -print-file-name=libmingwex.a"? C:\MinGW\lib\libmingwex.a. What now? Best, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 16 Feb '05

16 Feb '05

Adriaan van Os wrote: > Markus Gerwinski wrote: > > Thanks! Something seems wrong, however. Calling > > patch -p1 < ../gcc.c.patch > Did you try patch -p0 < ... ? I did. It didn't work either. However, I applied the patch manually now, and that worked. (See parallel mail.) ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Bug in function parsing?
by Markus Gerwinski 15 Feb '05

15 Feb '05

CBFalconer wrote: > Markus Gerwinski wrote: > > Of course, you also can do so by explicitly declaring `result`as a > > local variable and assigning it to getIndexOf in the end, but > > personally, I find the above way far more elegant. > Which, to me, means there are no new capabilities introduced by > this usage. I find the local variable and final assignment to be > much clearer and more elegant. All result has done is provide a > synonym for the function name, whose use in an expression will not > trigger recursion. Exactly. My issue here isn't about capability, but about readability. I usually try chosing my function names in a manner that you can use them just like verbs in normal talking. Using them as a noun when passing themselves as their own result always gave me a strange feeling, even back when I started my first steps in BP. Besides, since it can always happen that you run into that recursion at some point, I used to always declare the function's return value as a local variable whenever the function was bigger than a one-liner, even in my old BP days. This may be a matter of taste, but I was really happy when GPC gained the ability to declare them in the function implementation's header, and I'd be really, really sad to lose it again. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

3 3

cast increases required alignment of target type
by Adriaan van Os 15 Feb '05

15 Feb '05

Consider the followig test program: program TestCast; type BytePtr = ^Byte; IntPtr = ^Integer; var theBytePtr : BytePtr; theIntPtr: IntPtr; begin theBytePtr := nil; theIntPtr:= nil; theIntPtr:= IntPtr( theBytePtr); {testcast.pas:11: warning: cast increases required alignment of target type} BytePtr( theIntPtr) := theBytePtr; theBytePtr:= BytePtr( theIntPtr); IntPtr( theBytePtr):= theIntPtr; {testcast.pas:14: warning: cast increases required alignment of target type} end. 1. Compiling with gpc produces two warnings as indicated in the comment. The compiler warns if the "casting" pointer type (outside the parenthesis) points to a larger type than the "casted" pointer type (inside the parenthesis). Gale Paper brought to my attention that the same holds on the left side of an assignment and I am inclined to regard this as a bug - the compiler should check here for a smaller type, rather than a larger type. 2. the -Wcast-align and -Wno-cast-align command-line switches don't seem to work with gpc. Regards, Adriaan van Os

2 5

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 15 Feb '05

15 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > Differences in the sources. You might try to make the changes > manually, or someone who knows more about patch and stuff may be able > to explain the differences. Okay, I manually applied the changes now, and I'm back to the linker problems: make[2]: Entering directory `/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/utils' ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" ../../libgpc.a(rts.o)(.text+0xfdd): In function `p_CStringReadDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1546: undefined reference to `readdir' ../../libgpc.a(rts.o)(.text+0xfc1): In function `p_CStringOpenDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1541: undefined reference to `opendir' ../../libgpc.a(rts.o)(.text+0x100c): In function `p_CStringCloseDir': C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts/rts.c:1552: undefined reference to `closedir' make[2]: *** [binobj.exe] Error 1 make[1]: *** [pascal.utils] Error 2 make: *** [all-gcc] Error 2 I have /mingw/lib in my LIBRARY_PATH and LD_LIBRARY_PATH. What could prevent gcc from finding the libs? ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 15 Feb '05

15 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > This is an old gcc bug that has been fixed in later versions. The > attached patch should solve that problem. Thanks! Something seems wrong, however. Calling patch -p1 < ../gcc.c.patch from my gcc distribution directory leads to an error message: patching file `gcc/gcc.c' Hunk #1 FAILED at 328. Hunk #2 FAILED at 3050. Hunk #3 FAILED at 3279. Hunk #4 FAILED at 5917. 4 out of 4 hunks FAILED -- saving rejects to gcc/gcc.c.rej I don't quite understand the gcc.c.rej... it's attached. Can you tell me what I did wrong here? Yours, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

3 2

gpc-20041017 released
by Frank Heckenbach 15 Feb '05

15 Feb '05

I have uploaded a new beta version of GPC to <http://www.g-n-u.de/gpc/>! Because our main server is still out of order, please note: - The new URL, as stated above. www.gnu-pascal.de still doesn't work. - There are just the "bare bones" files (full and minimal source distribution, binaries for Linux/IA32 with and without gcc). No diffs, no separate test files, no HTML pages etc. - The main directory in the full source distribution is probably different! Be careful with automatic build scripts. - The releases are signed with a new OpenPGP key. The fingerprint is given in my signature in this mail and my other mails to the gpc(a)gnu.de list for some weeks. When the main server is back again, I'll do the usual release procedures there. One major change is that the types `Integer', `Word', `Cardinal' are now equivalent to `PtrInt', `PtrWord', `PtrCard', no more (necessarily) to C's `int' and `unsigned int' types. New types `CInteger', `CWord', `CCardinal' are provided for the latter purpose. This affects C interfaces in particular. A "porting guide" is given below. If you maintain any such interfaces, be sure to read it carefully. Another major improvement is in the area of initializers, thanks to Waldek Hebisch. GPC now allows initialization of variant records (fjf259.pas, peter6.pas) and packed arrays (emil5.pas) and supports Extended Pascal's structured initializers (fjf964*.pas, fjf967*.pas, fjf968*.pas) as well as record, array and set values (constdef.pas, fjf966*.pas, fjf971*.pas). Unfortunately, we don't have very many test programs for these new features yet. If you can send us some (according to the guidelines described in the manual), this will be very welcome. Other new features: * `Discard' * new make variable `GPC_PAGESIZE' to set the page size when building the manual (PDF, PostScript, DVI) * `qualified' and import lists are no more allowed after `uses' (only after `import', as EP demands) (@) * the `GMP' unit doesn't support gmp-2.x anymore (if you used it, just upgrade to a newer GMP version) (@) * conflicts between object fields/methods and ancestor type names are detected as required by OOE (fjf945*.pas) (@) (O) * repeated function headings (in `forward' declarations and interfaces) are checked stricter: if one has a result variable, so must the other (according to the OOE draft) (@) (O) Bugfixes: * records with no fields are invalid according to EP (fjf972.pas) * `Index' and `Pos' cannot be used in constant expressions (fjf970*.pas) * the `__FILE__' and `__BASE_FILE__' macros should return full paths * `Sqr' sometimes evaluates its argument twice (fjf963.pas) * memory leak in routines with a local variable of file type that are left via `Exit' or `Return' (fjf962.pas) * using a Boolean function as a condition in a `repeat' loop doesn't work correctly (artur1*.pas) * overstrict type-checking in comparisons involving procedural types (fjf960*.pas) * `Read', `Write' etc. evaluate its arguments in the wrong order (az43*.pas) * `Read' etc. evaluate references to string parameters twice (fjf958.pas) * on targets with 16 bit `Integer' type, the `MicroSecond' field of `TimeStamp' causes a compilation error * character arrays indexed by non-integer ordinal types treated as strings cause internal compiler errors (fjf957*.pas) * `-W[no-]cast-align' does not work (fjf956*.pas) * in `FormatTime' `%Z' and `%z' unless provided by system library ignore DST * powerpc: `--strength-reduce' doesn't work with `for' loops (was kludged before, fixed in gcc-3.3.3) * AIX: `ReturnAddress' doesn't work after use of dynmamic variables (backend bug, fixed in gcc-3.3.3) * functions returning sets are called twice if range-checking is on (inga1*.pas) PORTING GUIDE FOR THE NEW C COMPATIBLE INTEGER TYPES ==================================================== In my experience, the transition goes as follows: 1. If you want your code to keep working with older GPC versions after this change, add (near the top) the following part. You can omit the types you will not need in the following. {$if __GPC_RELEASE__ < 20041017} type CInteger = Integer; CCardinal = Cardinal; CWord = Word; {$endif} 2. In all C-visible declarations, replace `Integer' with `CInteger' and `Cardinal'/`Word' with `CCardinal'/`CWord'. C-visible declarations are usually `external' declarations (routines and/or variables) in Pascal which are implemented in C, but they can also be Pascal-implemented declarations (usually with a `name' attribute) which are declared `extern' in C code. Do not forget structures that are used within such declarations, e.g. parameters of type [pointer to] a record, or procedural parameters, etc. The same goes for other languages such as C++. 3. Fix any resulting incompatibilites. (This is the nasty part.) Value parameters are usually no problem. Anything else might be a problem, e.g., reference parameters, variables, structure fields, procedural parameters' parameters (including value parameters). As long as they are used only in the implementation of a unit/module which exports a Pascal interface, necessary changes can be confined to and handled within this interfaec. Otherwise, you have the choice whether to change the interface, which will require further changes in code using the interface, or to add wrappers to keep the interface. Example: unit MyCInterface; interface uses GPC; type t = record x, y, z: Integer end; procedure a (n: Integer); external name 'a'; procedure b (var n: Integer); external name 'b'; procedure c (var r: t); external name 'c'; function d (var n: Integer): TString; implementation function cd (var n: Integer): CString; external name 'd'; function d (var n: Integer): TString; begin d := CString2String (cd (n)) end; end. Changing a to procedure a (n: CInteger); external name 'a'; is usually harmless. Changing b to procedure b (var n: CInteger); external name 'b'; is problematic, since all callers would need to change their types (which might cause further ramifications in indirectly dependent code). So it might be in order to add a wrapper, such as: procedure b (var n: Integer); [implementation] procedure cb (var n: CInteger); external name 'b'; procedure b (var n: Integer); var cn: CInteger; begin cn := n; { omit if n is used only as an "output" parameter } cb (n); n := cn end; Procedure c uses a record containing `Integer' fields. Here, it's a hard choice between adding a wrapper (might be expensive, as the record gets bigger, and if more routines are affected) or changing the record to: type t = record x, y, z: CInteger end; The choice might depend on how many other routines use this structure and how many of them are written in Pascal or C, and how much existing code already uses the structure and what it does with it. Function d already has a wrapper, so it's usually best to also take care of the new change there: function d (var n: Integer): TString; var cn: CInteger; begin cn := n; { omit if n is used only as an "output" parameter } d := CString2String (cd (n)) n := cn end; Finally, note that `Integer' might be bigger than `CInteger', especially on newer platforms (that's the reason for the whole change in the first place). So if you want to have a bigger range available, you might want to consider changing from `CInteger' etc. (`[unsigned] int' in C) to `MedInt' etc. (`[unsigned] long' in C). This, however, requires (possibly substantial) changes in the C code, and might be out of your control (when interfacing to 3rd party libraries). 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 NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

9 23

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 14 Feb '05

14 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > As you can see, "d:/mingw/lib/" and "/mingw/lib/" appear in this. They > should have appeared in Markus's list as well. So, I think all points > to a broken installation (either gcc, or Mingw, or MSYS). Okay, I tried with a complete re-install of my MinGW now, and things keep getting weirder. I'm getting the following error message: ./gcc.c: In function `process_command': ./gcc.c:3735: error: assignment of read-only location ./gcc.c:3737: error: assignment of read-only location ./gcc.c: In function `fatal': ./gcc.c:6404: warning: traditional C rejects ISO C style function definitions ./gcc.c: In function `error': ./gcc.c:6418: warning: traditional C rejects ISO C style function definitions ./gcc.c: In function `notice': ./gcc.c:6431: warning: traditional C rejects ISO C style function definitions make[1]: *** [gcc.o] Error 1 make: *** [all-gcc] Error 2 ... so there's now a syntax error within gcc itself. I also tried without --enable-language=pascal, same result. My system now consists of: - MinGW 3.2.0 - MSys 1.0.10 - gcc 3.4.2 (came with the MinGW) What now? Thanks, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

the magics of eof()
by Francesco Bonomi 13 Feb '05

13 Feb '05

Dear friends, I don't know if what I found is a bug or a correct behaviour I don't understand. The following program halts with error 'attempt ro read past end of file'; program test; var f : file of char; begin rewrite(f,'test.dat'); seek(f,0); f^:='x'; (*GIVES ERROR HERE*) put(f); close(f); end. If I just insert a call reading eof(f) everything seems to work: program test; var f : file of char; begin rewrite(f,'test.dat'); seek(f,0); if eof(f) then ; (* do nothing *) f^:='x'; put(f); close(f); end. I am puzzled! (working with gpc 20030830) Ciao, Francesco

4 8

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 11 Feb '05

11 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > > > Is crt2.o anywhere in the Mingw directory tree? It should be in > > > /mingw/lib. > > It's right there. I've set LIBRARY_PATH and LD_LIBRARY_PATH both to > > point there. > Then it appears that you have a broken compiler. What is the output > of "gcc -print-search-dirs"? install: /mingw/lib/gcc-lib/mingw32/3.2.3/ programs: =C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/;/mingw/lib/gcc-lib/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/;/usr/lib/gcc/mingw32/3.2.3/;/usr/lib/gcc/mingw32/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/bin/ libraries: =C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/;/mingw/lib/gcc-lib/mingw32/3.2.3/;/usr/lib/gcc/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../../mingw32/lib/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../mingw32/3.2.3/;C:/MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../mingw32/3.2.3/;/mingw/lib/gcc-lib/mingw32/3.2.3/../../../;/lib/mingw32/3.2.3/;/lib/;/usr/lib/mingw32/3.2.3/;/usr/lib/ ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

4 3