Hi
After seing the message of Russ I have also run the tests for this snapshot. (djgpp v2.03 in W98 DOS box). No problem with gpctest.pas (the unmodified one). Two skipped as usual: longr2 (no long real in djgpp OK), fjf165a (no german locale OK). But six failed, whereas last time I did it (one or two month ago IIRC) none failed: fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas
After cleaning everything, rebooting (W98 you know), I obtain simplified test by booting bash and running directly test_run as
./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >ta
i.e. on all failing test program and one successfull test program. The result is
GPC-TEST-BEGIN ========================== TEST fieldw.pas: c:/djgpp/tmp\ccbq0vjj1.o: In function `pascal_main_program': fieldw.pas:11: undefined reference to `_p_writestr' fieldw.pas(.text+0x5e): undefined reference to `_p_inoutres' fieldw.pas(.text+0x66): undefined reference to `_p_check_inoutres' fieldw.pas:16: undefined reference to `_p_writestr' fieldw.pas(.text+0xb8): undefined reference to `_p_inoutres' fieldw.pas(.text+0xc0): undefined reference to `_p_check_inoutres' fieldw.pas:18: undefined reference to `_p_stdout' fieldw.pas(.text+0xe3): undefined reference to `_p_write' fieldw.pas(.text+0xec): undefined reference to `_p_inoutres' fieldw.pas(.text+0xf4): undefined reference to `_p_check_inoutres' fieldw.pas:20: undefined reference to `_p_stdout' fieldw.pas(.text+0x116): undefined reference to `_p_write' fieldw.pas(.text+0x11f): undefined reference to `_p_inoutres' fieldw.pas(.text+0x127): undefined reference to `_p_check_inoutres' fieldw.pas:22: undefined reference to `_p_atexit' fieldw.pas(.text+0x182): undefined reference to `_p_initialize' fieldw.pas(.text+0x191): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed TEST fjf101a.pas: c:/djgpp/tmp\ccbycwjj1.o: In function `pascal_main_program': fjf101a.pas:6: undefined reference to `O' fjf101a.pas:7: undefined reference to `K' fjf101a.pas(.text+0x2b): undefined reference to `init_Fjf101au' fjf101a.pas(.text+0x30): undefined reference to `init_Fjf101av' fjf101a.pas(.text+0x3d): undefined reference to `_p_atexit' fjf101a.pas(.text+0x66): undefined reference to `_p_initialize' fjf101a.pas(.text+0x75): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
<snip same for others>
TEST abso1.pas: OK ========================== GPC-TEST-END
All fail at link stage and this is bogus since all other test succeed to find these functions.
I then played with the options by typing e.g.
PFLAGS="--autobuild -g -O3 -Wall -Werror" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tb
This changes nothing since there are the default PFLAGS. But I found then that things go wrong only if I have exactly _five_ PFLAGS, what they may be (I have always included --autobuild, but tried e.g. -g -g -g -g), and succeed for four or six (or any number I have tried).
So I replace the fifth by -v, typing
PFLAGS="--autobuild -g -O3 -Wall -v" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tb
The output is:
GPC-TEST-BEGIN ========================== TEST fieldw.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccaakjgj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./fieldw.pas c:/djgpp/tmp\ccbakjgj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbakjgj.i -quiet -dumpbase fieldw.pas -g -O3 -Wall -version -famtmpfile=c:/djgpp/tmp\ccaakjgj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbakjgj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbakjgj1.o c:/djgpp/tmp\ccbakjgj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbakjgj1.o -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/tmp\ccbakjgj1.o: In function `pascal_main_program': fieldw.pas:11: undefined reference to `_p_writestr' fieldw.pas(.text+0x5e): undefined reference to `_p_inoutres' fieldw.pas(.text+0x66): undefined reference to `_p_check_inoutres' fieldw.pas:16: undefined reference to `_p_writestr' fieldw.pas(.text+0xb8): undefined reference to `_p_inoutres' fieldw.pas(.text+0xc0): undefined reference to `_p_check_inoutres' fieldw.pas:18: undefined reference to `_p_stdout' fieldw.pas(.text+0xe3): undefined reference to `_p_write' fieldw.pas(.text+0xec): undefined reference to `_p_inoutres' fieldw.pas(.text+0xf4): undefined reference to `_p_check_inoutres' fieldw.pas:20: undefined reference to `_p_stdout' fieldw.pas(.text+0x116): undefined reference to `_p_write' fieldw.pas(.text+0x11f): undefined reference to `_p_inoutres' fieldw.pas(.text+0x127): undefined reference to `_p_check_inoutres' fieldw.pas:22: undefined reference to `_p_atexit' fieldw.pas(.text+0x182): undefined reference to `_p_initialize' fieldw.pas(.text+0x191): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
<snip>
TEST abso1.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccayplgj -fautobuild -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./abso1.pas c:/djgpp/tmp\ccbyplgj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbyplgj.i -quiet -dumpbase abso1.pas -g -O3 -Wall -version -famtmpfile=c:/djgpp/tmp\ccayplgj -fautobuild -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbyplgj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbyplgj1.o c:/djgpp/tmp\ccbyplgj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbyplgj1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/bin/stubify.exe -v a.out stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: a.out -> a.000 -> a.exe OK ========================== GPC-TEST-END
On inspection, in the linking stage (collect2) -lgpc -lm are not inserted in the failing cases, whereas they do are in the successfull case.
To check I type (only four PFLAGS)
PFLAGS="--autobuild -g -O3 -v" ./test_run fieldw.pas fjf101[a-b].pas fjf38f.pas fjf394.pas fjf421j.pas abso1.pas >tc
and the result is
GPC-TEST-BEGIN ========================== TEST fieldw.pas: Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.952/specs gpc version 20001122, based on 2.95.2 19991024 (release) c:/djgpp/lib/gcc-lib/djgpp/2.952/gpcpp.exe -lang-pascal -v -I c:/djgpp/lib/gcc-lib/djgpp/2.952/units -I . -I ./../units -famtmpfile=c:/djgpp/tmp\ccaaqypj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20001122 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/bin/../include/sys/version.h -remap ./fieldw.pas c:/djgpp/tmp\ccbaqypj.i GNU Pascal Compiler PreProcessor version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/djgpp/lib/gcc-lib/djgpp/2.952/units . ./../units /usr/local/include JDIR/i586-pc-msdosdjgpp/include $DJDIR/lib/gcc-lib/djgpp/2.952/include $DJDIR/include End of search list. c:/djgpp/lib/gcc-lib/djgpp/2.952/gpc1.exe c:/djgpp/tmp\ccbaqypj.i -quiet -dumpbase fieldw.pas -g -O3 -version -famtmpfile=c:/djgpp/tmp\ccaaqypj -fautobuild -ffield-widths=1,2,3,41,42 -funit-path=. -funit-path=./../rts -funit-path=./../units -funit-path=c:/djgpp/lib/gcc-lib/djgpp/2.952/units -fexecutable-path=. -o c:/djgpp/tmp\ccbaqypj.s GNU Pascal version 2.95.2 19991024 (release) (djgpp) compiled by GNU C version 2.95.2 19991024 (release). c:/djgpp/bin/as.exe -o c:/djgpp/tmp\ccbaqypj1.o c:/djgpp/tmp\ccbaqypj.s c:/djgpp/lib/gcc-lib/djgpp/2.952/collect2.exe -o a.out c:/djgpp/lib/crt0.o -Lc:/djgpp/lib/gcc-lib/djgpp/2.952 -Lc:/djgpp/bin -Lc:/djgpp/lib c:/djgpp/tmp\ccbaqypj1.o -lgpc -lm -lgcc -lc -lgcc -Tdjgpp.djl c:/djgpp/bin/stubify.exe -v a.out stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: a.out -> a.000 -> a.exe OK
<snip>
all other succeed and you see that -lgpc -lm are there !
I cannot say more, especially if it is only a gpc bug, of if djgpp plays a role.
Hope this helps.
Maurice Lombardi wrote:
After seing the message of Russ I have also run the tests for this snapshot. (djgpp v2.03 in W98 DOS box). No problem with gpctest.pas (the unmodified one).
Sure, you live in Europe. (That's no joke: The program was doing a time zone computation which was wrong for negative values, so it would only fail west of GMT. An interesting condition for a bug, isn't it? ;-)
For the rest, I can't help you, I'm afraid. I can't seem to reproduce the problem, and I don't even have the slightest idea whether it's a DJGPP or GPC problem.
I've looked at the GPC code, and there are two places (gpc.c: add_automake_files and gpcspec.c: lang_specific_driver) which both seem to be supposed to add the libraries, but that's one of those dark areas that only Peter if anyone knows anything about and that are probably full of historcial relics...
Perhaps you can try debugging it (either running gpc under gdb if you can, or with the insert-debugging-write-statements-shoot-in-the-dark method) to find out where things go wrong, otherwise I don't know...
Frank
Frank Heckenbach a écrit :
Maurice Lombardi wrote:
After seing the message of Russ I have also run the tests for this snapshot. (djgpp v2.03 in W98 DOS box).
For the rest, I can't help you, I'm afraid. I can't seem to reproduce the problem, and I don't even have the slightest idea whether it's a DJGPP or GPC problem.
OK forget about it. It was a problem with djgpp.env. At some moment it was said on djgpp that [gcc] and [cpp] sections were no more necessary in djgpp.env, because they now correspond to default rules built into the compilers, which need only the root djgpp directory. They said that these sections were kept in stock djgpp.env only to serve as a template for additional search pathes such as those needed with grx when one wants to keep libraries and include files in the grx tree instead of moving them into standard locations. On september/october I have packed a binary grx232b.zip (which is on agnes) which includes in addition to what is contained in grx-2.3.1.i386-pc-msdosdjgpp.zip the chr and font directories, manifest files for clean removal and also grx20.pas and bccgrx20.pas in the units gpc directory so that they can be found automatically by gpc. To simplify I have put (like you have done in grx231) the libgrx20.a and include files in standard locations, so that users need not to change their stock djgpp.env. To check I have replaced my previous djgpp.env which included locations in the grx directory by a stock djgpp.env. But this one had no [gpc] section ! Strangely enough everything worked (graphics gpc programs, demo programs and my own programs) until I ran the gpc test suite, which failed only on those 6 tests over some 1600. Obviously djgpp was expecting that the [gpc] section will no more be necessary. But this triggers some weird bug, since the problem is not that the libraries are not found, but that -lgpc -lm options are omitted at link stage, only on these 6 files for exactly 5 compilator options ! So now I have a workaround, but probably it is not a solution.
Hope this helps
Maurice
-
Frank Heckenbach -
Maurice Lombardi