Hello, everybody!
I have solved the I/O problem on the DJGPP platform (and fixed some other bugs) and am now uploading a new alpha version of GPC to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ (source (diff) and binaries).
Many thanks to Eli Zaretskii for his help with the I/O problem.
Have fun,
Peter
Maurice Lombardi wrote: [...]
A completely different problem, found while trying to recompile various programs. The BPCOMPAT 1.1 package have to be adapted to the new version.
Yes, I am working on bpcompat 1.20. I have changed many things to correspond to the developments in the compiler, but I have to wait until the full release of the next version of GPC before I can complete what I am doing. Perhaps I should release an interim version of bpcompat (1.1.1?) sometime in the near future? Like I said, many things have changed in bpcompat since the release of v1.1 (for one thing, it is more compatible with BP), and I need to test these fully.
Some issues are simple: ParamCount and ParamStr are now builtin and the compiler barks because _p_paramcount and _p_paramstr no more exist in libgpc.
Yep.
The string issues have to be reconsidered: the trick Type String = bpString used with the _BORLAND_PASCAL_ compilation parameter causes problem because String[255]
Yep.
(e.g. in tFileRec in system.pas) is no more valid (I cannot understand how it can have been valid previouly).
A kludge and a hack to get around the limitations on untyped file handling. Most of these limitations have been removed, and many of the file functions are now built in.
I can make a workaround in this case, but it would be better than the author have a more general look.
He is! ;)
There have been many discussions on strings in this mailing list, and I am a bit lost now.
Many things are happening on that score. Hence the need to wait until release of the next GPC in order to finalise the work on bpcompat.
BTW: I will always be grateful for any help/contributions to the bpcompat package. Basically, I have only DJGPP to work and test with. I have decided to discontinue support for CYGWIN, because that version of the compiler is so far behind. However, it would be nice if bpcompat could be tested for portability with the other ports of GPC - something that I cannot personally do.
Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12@keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro 4.25 for Win16 and Win32: ftp://ftp.simtel.net/pub/simtelnet/win3/install/chief425.zip
According to Maurice Lombardi:
I have downloaded the djgpp binary of this alpha. We are one step farther, the bug I have reported on 980401 is no more there.
:-)
But there is one more.
:-(
[...] #include <...> search starts here: /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.80/include $DJDIR/include [...] (what is JDIR in the include search ? )
I suspect it's a corrupted `$DJDIR'. This might be a remainder of the bug just fixed. (Meanwhile I know about a more elegant solution which might solve that problem.)
Do paths containing environment variables like `$DJDIR' work in general under UNIX or UNIX-like platforms such as DJGPP?
End of search list. f:/djgpp/lib/gcc-lib/djgpp/2.80/gpc1.exe C:\TMP/ccaaaaaa.i -quiet -dumpbase bug.pas -version -famtmpfile=bug.gpc -o C:\TMP/ccaaaaaa.s GNU Pascal version 2.8.0 (djgpp) compiled by GNU C version 2.8.0.
Obviously, it's `gpc1.exe' which causes the error. :-I
In a WIN311 DOS box there is also a general protection fault caught by the system, so that the DPMI server is not responsible.
Obviously, it's `gpc.exe' which causes the error. :-(
I am investigating ...
[...]
An other independant problem. Is it usefull that I try to recompile the compiler under DJGPP now ? I had problems with the 971001 beta, and the configure.bat seems to be the same.
You can try, but be warned: It's a pain. A lot of manual action is needed. If you succeed to make it more comfortable, be welcome to send me your changes to be incorporated into the main distribution.
Greetings,
Peter
Hi, everybody
I have downloaded the djgpp binary of this alpha. We are one step farther, the bug I have reported on 980401 is no more there. But there is one more. Trying to compile BGI2GRX demos, the compiler hangs under DOS/DJGPP. I have previously recompiled GRX22 and BCC2GRX which are used by BGI2GRX, and their demos with gcc 2.8.0. All runs correctly. To track the bug, I use no automake. BGI2GRX.PAS compiles without apparent problem. Then I compile the program bug.pas which in fine contains only:
program ModeList;
uses BGI2GRX;
begin end.
with
redir -e bug.lst gpc -v -o bug.exe bug.pas
the compiler hangs under plain DOS/DJGPP but finish after some time with a general protection fault message under bash1147
The content of bug.lst is then:
Using builtin specs. gpc version 2.8.0 f:/djgpp/lib/gcc-lib/djgpp/2.80/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) -Acpu(i386) -Amachine(i386) bug.pas C:\TMP/ccaaaaaa.i GNU CPP version 2.8.0 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.80/include $DJDIR/include End of search list. f:/djgpp/lib/gcc-lib/djgpp/2.80/gpc1.exe C:\TMP/ccaaaaaa.i -quiet -dumpbase bug.pas -version -famtmpfile=bug.gpc -o C:\TMP/ccaaaaaa.s GNU Pascal version 2.8.0 (djgpp) compiled by GNU C version 2.8.0. General Protection Fault at eip=1cee0f; flags=3012 eax=001d1d0e ebx=001c016f ecx=00000123 edx=00000000 esi=002d0000 edi=00012300 ebp=0000000d esp=001f5b18 cs=167 ds=16f es=16f fs=14f gs=17f ss=16f error=0000
(what is JDIR in the include search ? )
In a WIN311 DOS box there is also a general protection fault caught by the system, so that the DPMI server is not responsible.
A completely different problem, found while trying to recompile various programs. The BPCOMPAT 1.1 package have to be adapted to the new version. Some issues are simple: ParamCount and ParamStr are now builtin and the compiler barks because _p_paramcount and _p_paramstr no more exist in libgpc. The string issues have to be reconsidered: the trick Type String = bpString used with the _BORLAND_PASCAL_ compilation parameter causes problem because String[255] (e.g. in tFileRec in system.pas) is no more valid (I cannot understand how it can have been valid previouly). I can make a workaround in this case, but it would be better than the author have a more general look. There have been many discussions on strings in this mailing list, and I am a bit lost now.
An other independant problem. Is it usefull that I try to recompile the compiler under DJGPP now ? I had problems with the 971001 beta, and the configure.bat seems to be the same.
Peter Gerwinski a écrit:
Do paths containing environment variables like `$DJDIR' work in general under UNIX or UNIX-like platforms such as DJGPP?
if you run under bash shell OK, you can type a command like $DJDIR/bin/perl
under plain DOS COMMAND.COM shell it doesn't work at all. only inside a .BAT command file you can have e.g.: %DJDIR%\bin\perl or type %DJDIR%\djgpp.env or even MyProg %DJDIR% if in MyProg you recover the argument with s:=paramstr(1); you recover the _content_ of environment variable DJDIR in string s.
otherwise in the argument of a program e.g. myprog.exe $DJDIR/toto it rests to the program Myprog to parse the first argument and call s:=getenv(DJDIR); to get the content of environment variable DJDIR
Hope it helps
-
Dr A Olowofoyeku (The African Chief) -
Maurice Lombardi -
Peter Gerwinski