pavenis@lanet.lv wrote:
Can You update this Pascal compiler (gpc2953b.zip) and documentation and inform me (download site), too?
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
You need to add one define in gpc.c
#define MKTEMP_EACH_FILE
(see gcc.c for example) It's becoming evident if You run gpc -v --automake .... and view what it spits out.
OK. With this change and the previous replacements of cpp by cpp0, I am able to do a native djgpp build of gpc-20010331. It gives zero error when running the whole test suite, the gpc demos programs and the grx24 pascal demo programs. I have thus uploaded the resulting gpc2953b.zip to agnes under the link:
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip
In the same directory I have uploaded all that I have used to do this native build (to enable compilations of new snapshots):
-> the gpc diff file: ftp://agnes.dida.physik.uni-essen.de/home/maurice/gcc-2.95.3.diff (it complains that some hunks are not in proper place. It is easy to correct for that but I prefer to let people to try on other systems with the original diff first in case there would be something special to djgpp)
-> the patch to apply to gcc2953s.zip to enable a native build: ftp://agnes.dida.physik.uni-essen.de/home/maurice/build_gpc_djgpp_2953.diff Notice that there is something wrong with the change made by gcc2953s2 to enable better incorporation of gpc into the gcc suite: what is changed in the top level Makefile.in: it produces GPC_FOR_TARGET=gpc instead of GPC_FOR_TARGET=./xgpc -B./ I have not tried to understand, only reverted these changes in the previous diff.
-> a batch file ftp://agnes.dida.physik.uni-essen.de/home/maurice/buildgpc2953.bat which automates the whole process: compiling gpc, installing and running the test suite if there is no compilation error. I usually run it during lunch time or at night.
Hope this helps
Maurice
On Sun, 8 Apr 2001, Maurice Lombardi wrote:
pavenis@lanet.lv wrote:
Can You update this Pascal compiler (gpc2953b.zip) and documentation and inform me (download site), too?
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
You need to add one define in gpc.c
#define MKTEMP_EACH_FILE
(see gcc.c for example) It's becoming evident if You run gpc -v --automake .... and view what it spits out.
OK. With this change and the previous replacements of cpp by cpp0, I am able to do a native djgpp build of gpc-20010331. It gives zero error when running the whole test suite, the gpc demos programs and the grx24 pascal demo programs. I have thus uploaded the resulting gpc2953b.zip to agnes under the link:
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip
In the same directory I have uploaded all that I have used to do this native build (to enable compilations of new snapshots):
-> the gpc diff file: ftp://agnes.dida.physik.uni-essen.de/home/maurice/gcc-2.95.3.diff (it complains that some hunks are not in proper place. It is easy to correct for that but I prefer to let people to try on other systems with the original diff first in case there would be something special to djgpp)
-> the patch to apply to gcc2953s.zip to enable a native build: ftp://agnes.dida.physik.uni-essen.de/home/maurice/build_gpc_djgpp_2953.diff Notice that there is something wrong with the change made by gcc2953s2 to enable better incorporation of gpc into the gcc suite: what is changed in the top level Makefile.in: it produces GPC_FOR_TARGET=gpc instead of GPC_FOR_TARGET=./xgpc -B./ I have not tried to understand, only reverted these changes in the previous diff.
Yes, the GPC related changes for top level Makefile.in in gcc2953s2.zip were wrong. Defining GPC_FOR_TARGET there is not needed for native build or to build a Linux to DJGPP cross-compiler under Linux, but I built gcc-2.95.3 as native compiler for DJGPP (together with GPC) under Linux and I had problems when target==host and host!=build (eg. building native compiler for DJGPP under Linux)
Perhaps I'll update gcc2953s2.zip after some time
-> a batch file ftp://agnes.dida.physik.uni-essen.de/home/maurice/buildgpc2953.bat which automates the whole process: compiling gpc, installing and running the test suite if there is no compilation error. I usually run it during lunch time or at night.
Andris
Maurice Lombardi wrote:
pavenis@lanet.lv wrote:
You need to add one define in gpc.c
#define MKTEMP_EACH_FILE
(see gcc.c for example) It's becoming evident if You run gpc -v --automake .... and view what it spits out.
OK. With this change and the previous replacements of cpp by cpp0, I am able to do a native djgpp build of gpc-20010331. It gives zero error when running the whole test suite, the gpc demos programs and the grx24 pascal demo programs.
Good news. :-)
I've now put these things into GPC (uploaded soon, 20010409). You might want to check if it builds "out of the box" then.
(it complains that some hunks are not in proper place. It is easy to correct for that but I prefer to let people to try on other systems with the original diff first in case there would be something special to djgpp)
I've looked at the changes. They all seem to be in the right place where diff puts them (Peter could tell better, of course). So I've built a patch for gcc-2.95.3 with only the offsets changed.
Frank
On Mon, 9 Apr 2001, Frank Heckenbach wrote:
I've now put these things into GPC (uploaded soon, 20010409). You might want to check if it builds "out of the box" then.
er ... nope. sorry.
easy part: chmod +x p/script/make-lib*
hard part: those pesky ".. linking not done" errors.
been looking at the problem. woke up at 4 am with an idea for a solution. will e-mail you later today.
Russ
Russ Whitaker wrote:
On Mon, 9 Apr 2001, Frank Heckenbach wrote:
I've now put these things into GPC (uploaded soon, 20010409). You might want to check if it builds "out of the box" then.
er ... nope. sorry.
easy part: chmod +x p/script/make-lib*
As I wrote in my reply to Dominique Schuppli's report:
: Thanks for the report, I've fixed it now. : : Anyone who's updated GPC from CVS since March 31, may have to do it : on their own copies like you did: : chmod +x <insert your path>/p/script/make-library-interface
I don't know if/how to make CVS change the mode after the file is initially downloaded. If you do, let me know. (If not, it's not so bad, I think -- it's only a one-time effort for some people; those who haven't updated CVS between March 31 and April 5, or who download a fresh copy of GPC will be unaffected.)
hard part: those pesky ".. linking not done" errors.
I thought they were because GPC called cpp instead of cpp0, and this should have been fixed now.
Oh yeah, you (and anyone else using gcc-2.95.3) will have to rerun the configure script. (This will detect gcc-2.95.3 and put a corresponsing define in gcc-version.h (in the build directory) which will tell gpc.c to call cpp0.)
Frank
On Tue, 10 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
On Mon, 9 Apr 2001, Frank Heckenbach wrote:
I've now put these things into GPC (uploaded soon, 20010409). You might want to check if it builds "out of the box" then.
er ... nope. sorry.
easy part: chmod +x p/script/make-lib*
As I wrote in my reply to Dominique Schuppli's report:
: Thanks for the report, I've fixed it now. : : Anyone who's updated GPC from CVS since March 31, may have to do it : on their own copies like you did: : chmod +x <insert your path>/p/script/make-library-interface
I don't know if/how to make CVS change the mode after the file is initially downloaded. If you do, let me know. (If not, it's not so bad, I think -- it's only a one-time effort for some people; those who haven't updated CVS between March 31 and April 5, or who download a fresh copy of GPC will be unaffected.)
hard part: those pesky ".. linking not done" errors.
I thought they were because GPC called cpp instead of cpp0, and this should have been fixed now.
Oh yeah, you (and anyone else using gcc-2.95.3) will have to rerun the configure script. (This will detect gcc-2.95.3 and put a corresponsing define in gcc-version.h (in the build directory) which will tell gpc.c to call cpp0.)
It doesn't work, so went into gpc.c and changed ccp by hand. Didn't know if ECGS95 *or where* is defined so played it safe and changed the name to cpp0 in 12 places.
compiled, installed, and ran test suite:
# tests 1302 # passed 1301 # skipped 1 # fail 0
Hooray !
Am attaching diff file. Caution - it's only for the 20010409 release.
Russ
*** gpc-20010409/p/gpc.c Mon Apr 9 09:34:30 2001 --- gcc-2.95.3/gcc/p/gpc.c Tue Apr 10 19:33:12 2001 *************** *** 38,50 **** * This file is derived from GCC's `gcc.c'. */ ! #ifdef GCC_2_95_3 /* gcc "wants this on by default all the time now" (cf. gcc.c) */ #define MKTEMP_EACH_FILE ! #define CPP "cpp0" ! #else ! #define CPP "cpp" ! #endif
#include "gcc-version.h" #include "p/version.h" --- 38,47 ---- * This file is derived from GCC's `gcc.c'. */ ! /* gcc "wants this on by default all the time now" (cf. gcc.c) */ #define MKTEMP_EACH_FILE !
#include "gcc-version.h" #include "p/version.h" *************** *** 718,724 **** {"@c", { #if USE_CPPLIB ! "%{E|M|MM:" CPP " -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 715,721 ---- {"@c", { #if USE_CPPLIB ! "%{E|M|MM:cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 754,760 **** %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! CPP " -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 751,757 ---- %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 782,788 **** #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:" CPP " -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 779,785 ---- #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 800,806 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! " CPP " %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ --- 797,803 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp0 %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ *************** *** 831,837 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {CPP " -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 828,834 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp0 -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ *************** *** 867,873 **** {".c", {"@c"}}, {"@c", { ! CPP " -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 864,870 ---- {".c", {"@c"}}, {"@c", { ! "cpp0 -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 889,895 **** %{!pipe:%g.s} %A\n }}}}" }}, {"-", ! {"%{E:" CPP " -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 886,892 ---- %{!pipe:%g.s} %A\n }}}}" }}, {"-", ! {"%{E:cpp0 -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 902,908 **** %{!E:%e-E required when input is from standard input}"}}, {".m", {"@objective-c"}}, {"@objective-c", ! {CPP " -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__OBJC__ -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 899,905 ---- %{!E:%e-E required when input is from standard input}"}}, {".m", {"@objective-c"}}, {"@objective-c", ! {"cpp0 -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__OBJC__ -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 926,932 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! " CPP " %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 923,929 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp0 %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 954,960 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {CPP " -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -undef -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 951,957 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp0 -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -undef -$ %{!undef:%p %P} -D__ASSEMBLER__ \ *************** *** 1468,1474 **** static struct spec_list static_specs[] = { INIT_STATIC_SPEC ("asm", &asm_spec), INIT_STATIC_SPEC ("asm_final", &asm_final_spec), ! INIT_STATIC_SPEC (CPP, &cpp_spec), INIT_STATIC_SPEC ("cc1", &cc1_spec), INIT_STATIC_SPEC ("cc1plus", &cc1plus_spec), #ifdef GPC --- 1465,1471 ---- static struct spec_list static_specs[] = { INIT_STATIC_SPEC ("asm", &asm_spec), INIT_STATIC_SPEC ("asm_final", &asm_final_spec), ! INIT_STATIC_SPEC ("ccp", &cpp_spec), INIT_STATIC_SPEC ("cc1", &cc1_spec), INIT_STATIC_SPEC ("cc1plus", &cc1plus_spec), #ifdef GPC
Russ Whitaker wrote:
hard part: those pesky ".. linking not done" errors.
I thought they were because GPC called cpp instead of cpp0, and this should have been fixed now.
Oh yeah, you (and anyone else using gcc-2.95.3) will have to rerun the configure script. (This will detect gcc-2.95.3 and put a corresponsing define in gcc-version.h (in the build directory) which will tell gpc.c to call cpp0.)
It doesn't work, so went into gpc.c and changed ccp by hand. Didn't know if ECGS95 *or where* is defined so played it safe and changed the name to cpp0 in 12 places.
compiled, installed, and ran test suite:
# tests 1302 # passed 1301 # skipped 1 # fail 0
Hooray !
Am attaching diff file. Caution - it's only for the 20010409 release.
And by private mail (hope you don't mind me quoting it here, but it really seems to be of interest to others as well):
Since there is already a separate diff file for 2.95.3 and since there aren't that many changes to gpc.c and since the approach you took isn't working at this time, why not just add on a patch to the 2.95.3.diff file?
The gcc-*.diff's are for patching the GCC sources, not the GPC sources themselves (otherwise, e.g., one would get real problems when changing the GCC version). So, undoing my change and putting it in gcc-2.95.3.diff is not a good solution.
Rather than that, we've got to figure out why it doesn't work yet. In gpc.c I do an #ifdef GCC_2_95_3. As I said, it should be defined in gcc-version.h which is automatically created in the build directory during configuration. (That's also where ECGS95 will be defined for the respective GCC versions, but ECGS95 is not relevant to this discussion.)
So, the first step would be to check if GCC_2_95_3 is defined there. If so, then you may just need to rebuild gpc.o (remove the object file, do a make clean, or build from scratch ...).
Otherwise, try to find out what's going wrong in config-lang.in (which is called from configure). The code in lines 35-37 should set the define. You may want to add some debugging echo's to show the values of $version and $version_string when running configure. This might give you a hint why the check fails and how to correct it.
Frank
On Wed, 11 Apr 2001, Frank Heckenbach wrote:
Rather than that, we've got to figure out why it doesn't work yet. In gpc.c I do an #ifdef GCC_2_95_3. As I said, it should be defined in gcc-version.h which is automatically created in the build directory during configuration. (That's also where ECGS95 will be defined for the respective GCC versions, but ECGS95 is not relevant to this discussion.)
So, the first step would be to check if GCC_2_95_3 is defined there. If so, then you may just need to rebuild gpc.o (remove the object file, do a make clean, or build from scratch ...).
Otherwise, try to find out what's going wrong in config-lang.in (which is called from configure). The code in lines 35-37 should set the define. You may want to add some debugging echo's to show the values of $version and $version_string when running configure. This might give you a hint why the check fails and how to correct it.
I see 2 problems with update to gpc-20010409:
1) #ifdef GPC_2_95_3 in gpc.c is placed before any #include statement (so it's undefined). Moving it after #include statements fixes the problem
2) Testing for exactly 2.95.3 in make-lang.in is not correct. Perhaps we should test for 2.95.[3-9] as current version in GCC_2_95 branch is already 2.95.3
Andris
Andris Pavenis wrote:
I see 2 problems with update to gpc-20010409:
- #ifdef GPC_2_95_3 in gpc.c is placed before any #include statement (so it's undefined). Moving it after #include statements fixes the problem
Oh yes. #-) I put them before in case any include would need MKTEMP_EACH_FILE, but III forgot that GCC_2_95_3 is only set in an include. Will fix this.
- Testing for exactly 2.95.3 in make-lang.in is not correct. Perhaps we should test for 2.95.[3-9] as current version in GCC_2_95 branch is already 2.95.3
OK -- though there may be other problems with new versions, and we'll have to care about them when the new versions are there, doing this change already now probably won't hurt. -- BTW, what about 2.96 (I think Red Hat released such a version) and 2.97 (the current development version?). Do they also have cpp0 or not yet? I must admit I'm quite confused about all these GCC/EGCS versions and I've given up trying to understand them...
Frank
On Wed, 11 Apr 2001, Frank Heckenbach wrote:
Andris Pavenis wrote:
I see 2 problems with update to gpc-20010409:
- #ifdef GPC_2_95_3 in gpc.c is placed before any #include statement (so it's undefined). Moving it after #include statements fixes the problem
Oh yes. #-) I put them before in case any include would need MKTEMP_EACH_FILE, but III forgot that GCC_2_95_3 is only set in an include. Will fix this.
It's not used in include files AFAIK.
- Testing for exactly 2.95.3 in make-lang.in is not correct. Perhaps we should test for 2.95.[3-9] as current version in GCC_2_95 branch is already 2.95.3
My typo: in current CVS version of gcc_2_95 branch version is 2.95.4
OK -- though there may be other problems with new versions, and we'll have to care about them when the new versions are there, doing this change already now probably won't hurt. -- BTW, what about 2.96 (I think Red Hat released such a version) and 2.97 (the current development version?). Do they also have cpp0 or not yet? I must admit I'm quite confused about all these GCC/EGCS versions and I've given up trying to understand them...
For comment about gcc-2.96 see http://gcc.gnu.org. It is not an official FSF release. Perhaps one should support gcc-3.0 when it will come out. Current development branch has now version 3.1 (for example gcc 3.1 20010411 (experimental)). gcc-3_0-branch have version 3.0 (prerelease).
There seems not too big problems to build current CVS version of gcc-3.0 prerelease under Linux (at least as I can see from my nightly builds: update of sources from CVS and bootstrapping and running tests). My attempts to build it for DJGPP was unsuccesfull after March 20 (I didn't want to mess with native build with DJGPP so I used Linux to build native compiler for DJGPP). For gcc-3.0 prerelease the preprocessor name is cpp0
Andris
Andris Pavenis wrote:
On Wed, 11 Apr 2001, Frank Heckenbach wrote:
Andris Pavenis wrote:
I see 2 problems with update to gpc-20010409:
- #ifdef GPC_2_95_3 in gpc.c is placed before any #include statement (so it's undefined). Moving it after #include statements fixes the problem
Oh yes. #-) I put them before in case any include would need MKTEMP_EACH_FILE, but III forgot that GCC_2_95_3 is only set in an include. Will fix this.
It's not used in include files AFAIK.
No, it isn't, as far as I can grep...
- Testing for exactly 2.95.3 in make-lang.in is not correct. Perhaps we should test for 2.95.[3-9] as current version in GCC_2_95 branch is already 2.95.3
My typo: in current CVS version of gcc_2_95 branch version is 2.95.4
OK -- though there may be other problems with new versions, and we'll have to care about them when the new versions are there, doing this change already now probably won't hurt. -- BTW, what about 2.96 (I think Red Hat released such a version) and 2.97 (the current development version?). Do they also have cpp0 or not yet? I must admit I'm quite confused about all these GCC/EGCS versions and I've given up trying to understand them...
For comment about gcc-2.96 see http://gcc.gnu.org. It is not an official FSF release. Perhaps one should support gcc-3.0 when it will come out. Current development branch has now version 3.1 (for example gcc 3.1 20010411 (experimental)). gcc-3_0-branch have version 3.0 (prerelease).
So there's a stable 2.95.3, a development 2.95.4, an unofficial 2.96, a development 2.97, a prerelease 3.0 and a development 3.1?!? (And the Linux kernel wants 2.91.66 for compilation.) OK, I'll stay with 2.8.1, at least then I know which version I have. ;-)
Frank
On 11 Apr 01, at 21:25, Frank Heckenbach wrote:
[...]
For comment about gcc-2.96 see http://gcc.gnu.org. It is not an official FSF release. Perhaps one should support gcc-3.0 when it will come out. Current development branch has now version 3.1 (for example gcc 3.1 20010411 (experimental)). gcc-3_0-branch have version 3.0 (prerelease).
So there's a stable 2.95.3, a development 2.95.4, an unofficial 2.96, a development 2.97, a prerelease 3.0 and a development 3.1?!? (And the Linux kernel wants 2.91.66 for compilation.) OK, I'll stay with 2.8.1, at least then I know which version I have. ;-)
The information on the gcc site makes it clear that 2.96 and 2.97 were never meant to be released (although some linux distributions included them), and were developments on the way to the release of 3.0, and as such, are not supported by the gcc development team. So as far as "official" releases are concerned, there was 2.95.2, then, recently, 2.95.3 (only to fix certain bugs in 2.95.2 - bugs which do not affect every platform), and the next one is 3.0, due for release later this year. I think that we would do well to stick with the official gcc releases.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
On Wed, 11 Apr 2001, Frank Heckenbach wrote:
Andris Pavenis wrote:
I see 2 problems with update to gpc-20010409:
- #ifdef GPC_2_95_3 in gpc.c is placed before any #include statement (so it's undefined). Moving it after #include statements fixes the problem
Oh yes. #-) I put them before in case any include would need MKTEMP_EACH_FILE, but III forgot that GCC_2_95_3 is only set in an include. Will fix this.
I think you should do it just like gcc.c and put the #define just before the first usage of MKTEMP_EACH_FILE. ( it's only used in one small area ).
- Testing for exactly 2.95.3 in make-lang.in is not correct. Perhaps we should test for 2.95.[3-9] as current version in GCC_2_95 branch is already 2.95.3
OK -- though there may be other problems with new versions, and we'll have to care about them when the new versions are there, doing this change already now probably won't hurt. -- BTW, what about 2.96 (I think Red Hat released such a version)
There was quite a flap over that. Now the gcc folks absolutely refuse to make 2.96 an "official" release. I think we can safely ignore 2.96.
and 2.97 (the current development version?). Do they also have cpp0 or not yet?
Read where cpp0 is cpp with the -E flag builtin. Since this was a bug fix think it would be safe to assume so. However, since 2.97 is only "developemental snapshots" the whole thing could change overnight.
I must admit I'm quite confused about all these GCC/EGCS versions...
Me too. Shows what can happen when two independent groups merge.
Russ
On 8 Apr 2001, at 12:45, Maurice Lombardi wrote:
pavenis@lanet.lv wrote:
Can You update this Pascal compiler (gpc2953b.zip) and documentation and inform me (download site), too?
Mmm. There is something broken in gpc under gcc-2.9.5.3. It compiles with snapshot gpc-20010315, but it gives lots of errors when running the test suite. As a comparison I have compiled the same snapshot under gcc-2.9.5.2 (the result is on agnes) and it gives zero error for the test suite.
You need to add one define in gpc.c
#define MKTEMP_EACH_FILE
(see gcc.c for example) It's becoming evident if You run gpc -v --automake .... and view what it spits out.
OK. With this change and the previous replacements of cpp by cpp0, I am able to do a native djgpp build of gpc-20010331. It gives zero error when running the whole test suite, the gpc demos programs and the grx24 pascal demo programs.
I did build build of gcc-2.95.3 together with gpc-20010409 (after fixing some small source problems, see gcc2953s2.zip for details) for DJGPP under Linux. Seems that it works Ok.
Compiler binaries for DJGPP (built under Linux): http://www.ltn.lv/~pavenis/gpc2953s.zip Output of tests http://www.ltn.lv/~pavenis/make.out
Updated version of gcc2953s2.zip http://www.ltn.lv/~pavenis/gcc2953s2.zip (native building is not really tested)
Andris
pavenis@lanet.lv wrote:
I did build build of gcc-2.95.3 together with gpc-20010409 (after fixing some small source problems, see gcc2953s2.zip for details) for DJGPP under Linux. Seems that it works Ok.
Output of tests http://www.ltn.lv/~pavenis/make.out
BTW, if you pipe these results through test_sum (which the default make target in test/ as well as dostest.bat should do automatically), you get quite a compact report:
: TEST daj13.pas: d:/Devel/gpc/test/a.out: error when writing to file `daj13.dat' (error #466 at 160f) : TEST fay.pas: e:\tmp\ccdaaaaa: Assembler messages: : e:\tmp\ccdaaaaa:934: Fatal error: C_EFCN symbol out of scope : failed : TEST fjf165a.pas: SKIPPED: only for German locale : TEST formattimetest.pas: failed (1990-3-25 3:3:45): : |Sun|Sunday|Mar|March|25|03|03|084|03|03|45|12|0|12|90|1990|%| : |Sun|Sunday|Mar|March|25|02|02|084|03|03|45|12|0|12|90|1990|%| : TEST gpctest.pas: warning: stange time zone -1193044.50 : 4294960096 : -4294960200 : 943841988 : True : True : 1999 1999 : 11 11 : 29 29 : 1 1 : 2 2 : 21 19 : 32 48 : 0 0 : Error in UnixTimeToTimeStamp: : TEST longr2.pas: SKIPPED: no LongReal math routines available : : # of GPC tests 1302 : # of GPC tests passed 1296 : # of GPC tests skipped 2 : # of GPC tests failed 4
The two skipped tests are expected (since there's no "long double" routines like sqrtl() and no locale support in DJGPP, AFAIK).
The failure in gpctest.pas seems to be a problem in the test program itself. I'll fix it.
The failure in formattimetest.pas is also a bug in the test program -- it generates some random times to check their formatting. Unfortunately, one of the times generated fell in the hour skipped at the beginning of DST. I avoided hour 2 for that reason (that's the hour we skip in MET), but as I see now, you (EET) seem to skip the 3rd hour, and it seems other time zones can skip even other hours. Even though it's only one hour in a year, it seems quite hard to find a general way to avoid it. I'm changing the test program now so it simply allows for one error per year and tries again with another hour in the same day. I hope that's safe ... ;-)
I don't understand the other two errors -- apparently they don't occur with Maurice and others, and I can't reproduce them. If you could do some more debugging, it would be nice ...
In your previous test report (forwarded by Maurice Lombardi), you also had the following errors in dialdef4.pas, fjf421l.pas and fjf421m.pas. I didn't understand them, and they didn't appear to occur now, so I suppose (hope ;-) it was some intermittent problem.
c:\djgpp\tmp\cceaaaaa: In function `pascal_main_program': fjf421m.pas:8: undefined reference to `_p_stdout' fjf421m.pas(.text+0x20): undefined reference to `_p_write' fjf421m.pas(.text+0x29): undefined reference to `_p_inoutres' fjf421m.pas(.text+0x31): undefined reference to `_p_check_inoutres' fjf421m.pas:9: undefined reference to `_p_atexit' fjf421m.pas(.text+0x82): undefined reference to `_p_initialize' fjf421m.pas(.text+0x91): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
Frank
Hi
gpc-20010409 didn't work because #define won't make changes inside a quoted string. So fixed it using this pseudo code:
if EGCS95 common part of table A if GCC_2_95_3 table A using cpp0 else table A using cpp end else table B end
Using gcc-2.95.3: patched, compiled, installed, tested. 0 fails. If you like can do it again using gcc-2.95.2
The attached diff file was made using gcc-20010317
That was fun Russ
Russ Whitaker wrote:
gpc-20010409 didn't work because #define won't make changes inside a quoted string.
Nope. The CPP macro is always used outside of the quoted strings (even where it doesn't appear so, e.g. in line 804, but note the opening quote in 803). (What results from preprocessor expansion is a sequence of strings like "%{E:" "cpp0" " -lang-c ..." which the C compiler concatenates to a string constant. In Pascal we'd write '%{E:' + CPP + ' -lang-c ...', but apart from syntax, it's the same.)
The reason it didn't work, as Andris pointed out, was because the #define was before the #includes, rather then after them. I'll fix this in my next change.
Frank
On Thu, 12 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
gpc-20010409 didn't work because #define won't make changes inside a quoted string.
Nope. The CPP macro is always used outside of the quoted strings (even where it doesn't appear so, e.g. in line 804, but note the opening quote in 803). (What results from preprocessor expansion is a sequence of strings like "%{E:" "cpp0" " -lang-c ..." which the C compiler concatenates to a string constant. In Pascal we'd write '%{E:' + CPP + ' -lang-c ...', but apart from syntax, it's the same.)
The reason it didn't work, as Andris pointed out, was because the #define was before the #includes, rather then after them. I'll fix this in my next change.
Not true.
My first approach was:
Since CPP is in use elsewhere, renamed cpp to czz in the table. then added:
#ifdef GPC_2_95_3 #define czz cpp0 #else #define czz cpp #endif
Compiled ok, but the test suite bombed out with czz. Obviously, define should have replaced czz with either cpp0 or cpp but did neither.
Russ
Russ Whitaker wrote:
On Thu, 12 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
gpc-20010409 didn't work because #define won't make changes inside a quoted string.
Nope. The CPP macro is always used outside of the quoted strings (even where it doesn't appear so, e.g. in line 804, but note the opening quote in 803). (What results from preprocessor expansion is a sequence of strings like "%{E:" "cpp0" " -lang-c ..." which the C compiler concatenates to a string constant. In Pascal we'd write '%{E:' + CPP + ' -lang-c ...', but apart from syntax, it's the same.)
The reason it didn't work, as Andris pointed out, was because the #define was before the #includes, rather then after them. I'll fix this in my next change.
Not true.
My first approach was:
Since CPP is in use elsewhere,
Err, where? The only place I see it is in some shell scripts which are completely unrelated. (In fact, any use in a file not included by gpc.c would be unrelated.) Though, of course, renaming it to anything else (which doesn't conflict with anything) should work just as well.
renamed cpp to czz in the table. then added:
Do you mean CPP or "cpp" (besides C's case-sentivity, the real question is whether you renamed the CPP macro I introduced, or the cpp as part of the quoted strings)?
#ifdef GPC_2_95_3 #define czz cpp0 #else #define czz cpp #endif
Compiled ok, but the test suite bombed out with czz. Obviously, define should have replaced czz with either cpp0 or cpp but did neither.
Well, I don't know exactly what you did. It seems you renamed cpp in the quoted string. This will not work, since (as you said correctly) defines are not replaced in quoted strings.
But where I use the CPP macro is always outside of quoted strings (Really! I just checked it again!), so if you renamed the macro to czz, there's no way it can creep into the gpc executable (you can check with `strings' or `grep'), so gpc won't try to call czz. Maybe you did something wrong, or your files have become inconsistent with our sources due to your previous attempts to solve the problem.
I suggest you get a fresh copy from CVS, move the define below the includes (if this change isn't in the CVS yet -- I'm not sure at the moment), then it should work without any renaming...
Frank
On Fri, 13 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
On Thu, 12 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
gpc-20010409 didn't work because #define won't make changes inside a quoted string.
Nope. The CPP macro is always used outside of the quoted strings (even where it doesn't appear so, e.g. in line 804, but note the opening quote in 803). (What results from preprocessor expansion is a sequence of strings like "%{E:" "cpp0" " -lang-c ..." which the C compiler concatenates to a string constant. In Pascal we'd write '%{E:' + CPP + ' -lang-c ...', but apart from syntax, it's the same.)
The reason it didn't work, as Andris pointed out, was because the #define was before the #includes, rather then after them. I'll fix this in my next change.
Not true.
My first approach was:
Since CPP is in use elsewhere,
Err, where?
CPP_SPEC (6 PLACES) CPP_PREDEFINES USE_CPPLIB
The only place I see it is in some shell scripts which are completely unrelated. (In fact, any use in a file not included by gpc.c would be unrelated.) Though, of course, renaming it to anything else (which doesn't conflict with anything) should work just as well.
renamed cpp to czz in the table. then added:
Do you mean CPP or "cpp" (besides C's case-sentivity, the real question is whether you renamed the CPP macro I introduced, or the cpp as part of the quoted strings)?
I maintain that gpc.c in 20010409 is messed up, so copied over a virgin copy of gpc.c from 20010317 and worked with that. Thus the renaming and the following snipet was a cautious approach that paid off when it did't work.
#ifdef GPC_2_95_3 #define czz cpp0 #else #define czz cpp #endif
Compiled ok, but the test suite bombed out with czz. Obviously, define should have replaced czz with either cpp0 or cpp but did neither.
Well, I don't know exactly what you did. It seems you renamed cpp in the quoted string. This will not work, since (as you said correctly) defines are not replaced in quoted strings.
But where I use the CPP macro is always outside of quoted strings (Really! I just checked it again!),
Of course! gpc.c in 20010409 is wrong!
so if you renamed the macro to czz, there's no way it can creep into the gpc executable (you can check with `strings' or `grep'), so gpc won't try to call czz. Maybe you did something wrong, or your files have become inconsistent with our sources due to your previous attempts to solve the problem.
gpc parses lines in the table to determine what sub-programs to call and what parameters to pass. Since czz did't get replaced and there was no czz in the bin directory ...
I suggest you get a fresh copy from CVS, move the define below the includes (if this change isn't in the CVS yet -- I'm not sure at the moment), then it should work without any renaming...
I think I'll wait for the smoke to clear.
Russ
Russ Whitaker wrote:
On Fri, 13 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
Since CPP is in use elsewhere,
Err, where?
CPP_SPEC (6 PLACES) CPP_PREDEFINES USE_CPPLIB
Macro substitution occurs only on whole tokens, not on parts of identifiers, so that's no problem.
The only place I see it is in some shell scripts which are completely unrelated. (In fact, any use in a file not included by gpc.c would be unrelated.) Though, of course, renaming it to anything else (which doesn't conflict with anything) should work just as well.
renamed cpp to czz in the table. then added:
Do you mean CPP or "cpp" (besides C's case-sentivity, the real question is whether you renamed the CPP macro I introduced, or the cpp as part of the quoted strings)?
I maintain that gpc.c in 20010409 is messed up, so copied over a virgin copy of gpc.c from 20010317 and worked with that. Thus the renaming and the following snipet was a cautious approach that paid off when it did't work.
#ifdef GPC_2_95_3 #define czz cpp0 #else #define czz cpp #endif
Compiled ok, but the test suite bombed out with czz. Obviously, define should have replaced czz with either cpp0 or cpp but did neither.
Well, I don't know exactly what you did. It seems you renamed cpp in the quoted string. This will not work, since (as you said correctly) defines are not replaced in quoted strings.
But where I use the CPP macro is always outside of quoted strings (Really! I just checked it again!),
Of course! gpc.c in 20010409 is wrong!
so if you renamed the macro to czz, there's no way it can creep into the gpc executable (you can check with `strings' or `grep'), so gpc won't try to call czz. Maybe you did something wrong, or your files have become inconsistent with our sources due to your previous attempts to solve the problem.
gpc parses lines in the table to determine what sub-programs to call and what parameters to pass. Since czz did't get replaced and there was no czz in the bin directory ...
I suggest you get a fresh copy from CVS, move the define below the includes (if this change isn't in the CVS yet -- I'm not sure at the moment), then it should work without any renaming...
I think I'll wait for the smoke to clear.
Well, let me say this again:
- 20010409 is broken, but only because the define is before, not after the includes. The name of the define (CPP) and the way it's used (outside of quoted strings) seems to be correct. Simply moving the define after the includes should work (patch below; this will also be in the next GPC version). Why don't you just try it?
- I really don't know what you did with czz, but if the string czz did creep into the table in the executable, you probably have inserted it within a quoted string or something (unlike my CPP macro). If you send me your file with these changes, I can perhaps find out what the problem is ...
--- gpc.c.orig Fri Apr 13 10:23:04 2001 +++ gpc.c Fri Apr 13 00:29:17 2001 @@ -38,14 +38,6 @@ * This file is derived from GCC's `gcc.c'. */ -#ifdef GCC_2_95_3 -/* gcc "wants this on by default all the time now" (cf. gcc.c) */ -#define MKTEMP_EACH_FILE -#define CPP "cpp0" -#else -#define CPP "cpp" -#endif - #include "gcc-version.h" #include "p/version.h" #include "config.h" @@ -73,6 +65,15 @@ #include <varargs.h> #endif #include <stdio.h> + +#ifdef GCC_2_95_3 +/* gcc "wants this on by default all the time now" (cf. gcc.c) */ +#undef MKTEMP_EACH_FILE +#define MKTEMP_EACH_FILE +#define CPP "cpp0" +#else +#define CPP "cpp" +#endif
#ifndef R_OK #define R_OK 4
Frank
On Fri, 13 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
On Fri, 13 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
Since CPP is in use elsewhere,
Macro substitution occurs only on whole tokens, not on parts of identifiers, so that's no problem.
True, but like I said, was just being cautious. Last thing I wanted was some side effect to sneak in undetected.
Well, let me say this again:
20010409 is broken, but only because the define is before, not after the includes. The name of the define (CPP) and the way it's used (outside of quoted strings) seems to be correct. Simply moving the define after the includes should work (patch below; this will also be in the next GPC version). Why don't you just try it?
I really don't know what you did with czz, but if the string czz did creep into the table in the executable, you probably have inserted it within a quoted string or something (unlike my CPP macro). If you send me your file with these changes, I can perhaps find out what the problem is ...
Attached is a gzip copy of a virgin gpc.c, copied from the 20010317 release.
Below is two diff files: The first is an *exact* reproduction of what I did. The second is in case you want to try it yourself and you are *not* using gcc-2.95.x
If you are still not convinced:
1. gunzip the attachment.
2. apply the appropiate diff file from below to the attachment
3. compile gpc using patched attachment, install, run test suite
4. checkmate
Russ ________________________________________________________________________ diff file #1:
*** gpc.c.orig Fri Apr 13 14:32:05 2001 --- gpc.c Fri Apr 13 14:37:30 2001 *************** *** 692,697 **** --- 692,703 ----
#ifdef EGCS95
+ #ifdef GPC_2_94_3 + #define czz cpp0 + #else + #define czz cpp + #endif + static struct compiler default_compilers[] = { /* Add lists of suffixes of known languages here. If those languages *************** *** 710,716 **** {"@c", { #if USE_CPPLIB ! "%{E|M|MM:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 716,722 ---- {"@c", { #if USE_CPPLIB ! "%{E|M|MM:czz -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 746,752 **** %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 752,758 ---- %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "czz -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 774,780 **** #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 780,786 ---- #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:czz -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 792,798 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ --- 798,804 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! czz %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ *************** *** 823,829 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 829,835 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"czz -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ ____________________________________________________________________________ diff file #2
*** gpc.c.orig Fri Apr 13 14:32:05 2001 --- gpc.c Fri Apr 13 14:43:26 2001 *************** *** 690,695 **** --- 690,702 ----
/* The default list of file name suffixes and their compilation specs. */
+ + #ifdef GPC_2_94_3 + #define czz cpp0 + #else + #define czz cpp + #endif + #ifdef EGCS95
static struct compiler default_compilers[] = *************** *** 710,716 **** {"@c", { #if USE_CPPLIB ! "%{E|M|MM:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 717,723 ---- {"@c", { #if USE_CPPLIB ! "%{E|M|MM:czz -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 746,752 **** %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 753,759 ---- %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}\ %{!pipe:%g.s} %A\n }}}}" #else /* ! USE_CPPLIB */ ! "czz -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 774,780 **** #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ --- 781,787 ---- #endif /* ! USE_CPPLIB */ }}, {"-", ! {"%{E:czz -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ *************** *** 792,798 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ --- 799,805 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! czz %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2}\ *************** *** 823,829 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 830,836 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"czz -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %{$} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -$ %{!undef:%p %P} -D__ASSEMBLER__ \ *************** *** 859,865 **** {".c", {"@c"}}, {"@c", { ! "cpp -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 866,872 ---- {".c", {"@c"}}, {"@c", { ! "czz -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 881,887 **** %{!pipe:%g.s} %A\n }}}}" }}, {"-", ! {"%{E:cpp -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 888,894 ---- %{!pipe:%g.s} %A\n }}}}" }}, {"-", ! {"%{E:czz -lang-c%{ansi:89} %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 894,900 **** %{!E:%e-E required when input is from standard input}"}}, {".m", {"@objective-c"}}, {"@objective-c", ! {"cpp -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__OBJC__ -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 901,907 ---- %{!E:%e-E required when input is from standard input}"}}, {".m", {"@objective-c"}}, {"@objective-c", ! {"czz -lang-objc %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__OBJC__ -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 918,924 **** {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! cpp %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ --- 925,931 ---- {".h", {"@c-header"}}, {"@c-header", {"%{!E:%eCompilation of header file requested} \ ! czz %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\ *************** *** 946,952 **** %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"cpp -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -undef -$ %{!undef:%p %P} -D__ASSEMBLER__ \ --- 953,959 ---- %i %A\n }}}}"}}, {".S", {"@assembler-with-cpp"}}, {"@assembler-with-cpp", ! {"czz -lang-asm %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\ %{C:%{!E:%eGNU C does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG} %{trigraphs}\ -undef -$ %{!undef:%p %P} -D__ASSEMBLER__ \
Russ Whitaker wrote:
- I really don't know what you did with czz, but if the string czz did creep into the table in the executable, you probably have inserted it within a quoted string or something (unlike my CPP macro). If you send me your file with these changes, I can perhaps find out what the problem is ...
Attached is a gzip copy of a virgin gpc.c, copied from the 20010317 release.
Below is two diff files: The first is an *exact* reproduction of what I did. The second is in case you want to try it yourself and you are *not* using gcc-2.95.x
Well, you try to use the macro inside the quoted strings like I assumed. As I said (and I think you also pointed out), this does not work. To get macro substitution, you have to put it outside of strings.
And, again, that's exactly what I did in 20010409, so I still claim this version is correct, except for the placement of the defines.
Frank
On Sat, 14 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
- I really don't know what you did with czz, but if the string czz did creep into the table in the executable, you probably have inserted it within a quoted string or something (unlike my CPP macro). If you send me your file with these changes, I can perhaps find out what the problem is ...
Attached is a gzip copy of a virgin gpc.c, copied from the 20010317 release.
Below is two diff files: The first is an *exact* reproduction of what I did. The second is in case you want to try it yourself and you are *not* using gcc-2.95.x
Well, you try to use the macro inside the quoted strings like I assumed. As I said (and I think you also pointed out), this does not work. To get macro substitution, you have to put it outside of strings.
And, again, that's exactly what I did in 20010409, so I still claim this version is correct, except for the placement of the defines.
You just dug yourself into a deeper hole.
The goal is to replace cpp with cpp0 when you have GPC_2_95_3.
If you will look at the quote marks in the untouched gpc.c (from 20010317 as an example) you will discover that the cpp's in the table *are* inside quoted strings.
Reminder: the diff files in the last post are only for illustrating the problem.
Russ
Russ Whitaker wrote:
On Sat, 14 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
- I really don't know what you did with czz, but if the string czz did creep into the table in the executable, you probably have inserted it within a quoted string or something (unlike my CPP macro). If you send me your file with these changes, I can perhaps find out what the problem is ...
Attached is a gzip copy of a virgin gpc.c, copied from the 20010317 release.
Below is two diff files: The first is an *exact* reproduction of what I did. The second is in case you want to try it yourself and you are *not* using gcc-2.95.x
Well, you try to use the macro inside the quoted strings like I assumed. As I said (and I think you also pointed out), this does not work. To get macro substitution, you have to put it outside of strings.
And, again, that's exactly what I did in 20010409, so I still claim this version is correct, except for the placement of the defines.
You just dug yourself into a deeper hole.
The goal is to replace cpp with cpp0 when you have GPC_2_95_3.
If you will look at the quote marks in the untouched gpc.c (from 20010317 as an example) you will discover that the cpp's in the table *are* inside quoted strings.
Reminder: the diff files in the last post are only for illustrating the problem.
I've explained this so often now, I don't what more I can say about it. So I just repeat myself...
In 20010317 (before the whole thing started), there was a number of occurrences of cpp *inside* quoted strings.
In your diffs, you renamed cpp to czz *within* the quoted strings (which clearly is a "problem" since it can't work).
In my changes (20010409), I moved it *out of* the quoted strings and renamed it to CPP. E.g.:
[...] - "%{E|M|MM:cpp -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ + "%{E|M|MM:" CPP " -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\ [...]
CPP is a macro which expands to either "cpp" or "cpp0" (depending on the GCC version), including the quotes.
So the line above expands to (using gcc-2.95.3):
"%{E|M|MM:" "cpp0" " -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\
which in C is the same as:
"%{E|M|MM:cpp0 -lang-c %{ansi:-std=c89} %{std*} %{nostdinc*}\
OK, so maybe you're not familiar with how macros and string constants work in C (as a Pascal programmer, that's no shame ;-). But then, why don't you just try it rather than claiming that it doesn't work?
Frank
On Wednesday 11 April 2001 23:44, Frank Heckenbach wrote:
In your previous test report (forwarded by Maurice Lombardi), you also had the following errors in dialdef4.pas, fjf421l.pas and fjf421m.pas. I didn't understand them, and they didn't appear to occur now, so I suppose (hope ;-) it was some intermittent problem.
c:\djgpp\tmp\cceaaaaa: In function `pascal_main_program': fjf421m.pas:8: undefined reference to `_p_stdout' fjf421m.pas(.text+0x20): undefined reference to `_p_write' fjf421m.pas(.text+0x29): undefined reference to `_p_inoutres' fjf421m.pas(.text+0x31): undefined reference to `_p_check_inoutres' fjf421m.pas:9: undefined reference to `_p_atexit' fjf421m.pas(.text+0x82): undefined reference to `_p_initialize' fjf421m.pas(.text+0x91): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
Tried to replace -g with -v in PFLAGS (file test_run). Got this problem. After that added -g at end and problem disappeared (on one box). Comparisson of outputs for dialdef1.pas shows that '-lgpc -lm' is missing in collect2 command line when I'm getting the failure.
So it seems that add_automake_files() in gpc.c fails to add linking these libraries to collect2 command line ( library==0 ?). I cannot say why it happens now.
Andris
On Wednesday 11 April 2001 23:44, Frank Heckenbach wrote:
pavenis@lanet.lv wrote:
In your previous test report (forwarded by Maurice Lombardi), you also had the following errors in dialdef4.pas, fjf421l.pas and fjf421m.pas. I didn't understand them, and they didn't appear to occur now, so I suppose (hope ;-) it was some intermittent problem.
c:\djgpp\tmp\cceaaaaa: In function `pascal_main_program': fjf421m.pas:8: undefined reference to `_p_stdout' fjf421m.pas(.text+0x20): undefined reference to `_p_write' fjf421m.pas(.text+0x29): undefined reference to `_p_inoutres' fjf421m.pas(.text+0x31): undefined reference to `_p_check_inoutres' fjf421m.pas:9: undefined reference to `_p_atexit' fjf421m.pas(.text+0x82): undefined reference to `_p_initialize' fjf421m.pas(.text+0x91): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
The source of problem was errorous setting static variable library (in gpc.c) to 0 in some cases when command line contains something like '-I .'
We are not testing: - that we have at least 2 characters in option (this causes test problems in some cases as 3th character could be anything including 0, it's not very often though ...)
- if we have exactly 2 characters we should check whether 1st one is '-'. Try for example 'gpc --automake -I xc hello.pas' to get a problem (no linking when -c specified, in this cases xc not distinguished from -c)
Included patch should fix box problems
Andris
--- gpc.c~1 Tue Apr 17 20:36:18 2001 +++ gpc.c Fri Apr 20 20:11:43 2001 @@ -1348,6 +1348,8 @@ while (i < newindex) { if (library != 0 + && newv[i][0]=='-' + && newv[i][1] && newv[i][2] == '\0' && (char *) strchr ("hv", newv[i][1]) != NULL && (newindex == 2 @@ -1360,7 +1362,10 @@ dialect = 0; } if (library != 0 - && ((newv[i][2] == '\0' + && ((newv[i][0]=='-' + && newv[i][1] + && newv[i][2] == '\0' + && (char *) strchr ("cSEM", newv[i][1]) != NULL) || strcmp (newv[i], "-MM") == 0 || strcmp (newv[i], "-fsyntax-only") == 0)) Ā
Andris Pavenis wrote:
On Wednesday 11 April 2001 23:44, Frank Heckenbach wrote:
pavenis@lanet.lv wrote:
In your previous test report (forwarded by Maurice Lombardi), you also had the following errors in dialdef4.pas, fjf421l.pas and fjf421m.pas. I didn't understand them, and they didn't appear to occur now, so I suppose (hope ;-) it was some intermittent problem.
c:\djgpp\tmp\cceaaaaa: In function `pascal_main_program': fjf421m.pas:8: undefined reference to `_p_stdout' fjf421m.pas(.text+0x20): undefined reference to `_p_write' fjf421m.pas(.text+0x29): undefined reference to `_p_inoutres' fjf421m.pas(.text+0x31): undefined reference to `_p_check_inoutres' fjf421m.pas:9: undefined reference to `_p_atexit' fjf421m.pas(.text+0x82): undefined reference to `_p_initialize' fjf421m.pas(.text+0x91): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
The source of problem was errorous setting static variable library (in gpc.c) to 0 in some cases when command line contains something like '-I .'
We are not testing:
that we have at least 2 characters in option (this causes test problems in some cases as 3th character could be anything including 0, it's not very often though ...)
if we have exactly 2 characters we should check whether 1st one is '-'. Try for example 'gpc --automake -I xc hello.pas' to get a problem (no linking when -c specified, in this cases xc not distinguished from -c)
Included patch should fix box problems
Great, thanks. ISTR Maurice reported a similar problem last November, but no-one had an idea how to fix it. But I suppose it was the same cause.
Frank
pavenis@lanet.lv wrote:
I did build build of gcc-2.95.3 together with gpc-20010409 (after fixing some small source problems, see gcc2953s2.zip for details) for DJGPP under Linux. Seems that it works Ok.
Compiler binaries for DJGPP (built under Linux): http://www.ltn.lv/~pavenis/gpc2953s.zip
b
Output of tests http://www.ltn.lv/~pavenis/make.out
Updated version of gcc2953s2.zip http://www.ltn.lv/~pavenis/gcc2953s2.zip (native building is not really tested)
Very nearly OK. I have done a native (W98/dos box) build of the same gpc-20010409, using original gcc-2.95.3.tar.gz (and libg++-2.8.1.3.tar.gz) sources and the abovementioned gcc2953s2.zip. The only small change was in makesrc.sh to avoid spurious " which made dtou fail when doing with $gpc-archive. The modified zip is in
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gcc2953s2.zip
Compilation of the whole gcc collection succeeds. I have only removed the -mno-bnu210 options in CFLAGS and CXXFLAGS in djbuild1.sh, since I have bnu210 installed. The "native" compiler was already gcc2953b from simtelnet.
The resulting gpc2953b.zip is uploaded to
ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip
Running the gpc test suite results in only one failure: y2k.pas (which is new). The problem is with the function sleep: Has this function been changed recently ? (We have been discussing at length of various delay functions).
To check I have also installed your abovementioned gpc2953b.zip and tried to compile y2k.pas. It fails with:
C:\djgpp\gnu\gcc-2.953\gcc\p\test>gpc y2k.pas -o y2k.exe --autobuild -D__BP_UNPO RTABLE_ROUTINES__ c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x49d):file.c: undefined reference to `lstat' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x18e2):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x266b):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x26a9):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x26e8):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x2802):file.c: undefine d reference to `llseek' collect2: ld returned 1 exit status
It is a config problem. In my native building tree I find in gcc/p/rts/rts-config.h
<snip> /* Define if the llseek function is declared in <unistd.h>. */ /* #undef LLSEEK_DECLARED */ <snip> /* Define if you have the lstat function. */ /* #undef HAVE_LSTAT */ <snip> and this is correct when looking to my %DJGPP%/include files.
Hope this helps
Maurice
Maurice Lombardi wrote:
Running the gpc test suite results in only one failure: y2k.pas (which is new). The problem is with the function sleep: Has this function been changed recently ? (We have been discussing at length of various delay functions).
Nope. (I haven't gotten around to doing anything about the delay issue yet, and AFAIUI, it doesn't affect sleep (whole seconds), anyway.)
What fails exactly? The errors given below seem quite unrelated to anything this test program does. Do they also occur when running the test suite, or are there other problems then?
To check I have also installed your abovementioned gpc2953b.zip and tried to compile y2k.pas. It fails with:
C:\djgpp\gnu\gcc-2.953\gcc\p\test>gpc y2k.pas -o y2k.exe --autobuild -D__BP_UNPO RTABLE_ROUTINES__ c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x49d):file.c: undefined reference to `lstat' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x18e2):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x266b):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x26a9):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x26e8):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x2802):file.c: undefine d reference to `llseek' collect2: ld returned 1 exit status
Only with this test program? This would seem quite strange. The routines referenced by file.o in libgpc.a don't depend on the program being compiled, and file.o is used in any GPC program, so if there are really undefined references, they should occur with any program.
It is a config problem. In my native building tree I find in gcc/p/rts/rts-config.h
<snip> /* Define if the llseek function is declared in <unistd.h>. */ /* #undef LLSEEK_DECLARED */ <snip> /* Define if you have the lstat function. */ /* #undef HAVE_LSTAT */ <snip> and this is correct when looking to my %DJGPP%/include files.
Yes (and HAVE_LLSEEK should also be unset).
From the RTS sources, it seems quite clear that lstat and llseek
aren't called unless these symbols are defined. Maybe something went wrong when you built GPC? (Some foreign config file or config cache lying around, I don't know... Do you build GPC for several platforms?)
Oh wait... this was a GPC binary built by Andris, right? Maybe he's used a newer DJGPP version which does have these functions, while yours (and mine) doesn't. This could explain the problem. (This should be reflected in the settings rts-config.inc in this binary.)
I don't follow DJGPP releases too closely, so I don't know. If it's a new official DJGPP release, it just means that this GPC binary requires that release. Otherwise, if it's a DJGPP developer version, a public GPC binary should probably not be built against it...
Frank
On Tuesday 17 April 2001 04:47, Frank Heckenbach wrote:
Yes (and HAVE_LLSEEK should also be unset).
From the RTS sources, it seems quite clear that lstat and llseek aren't called unless these symbols are defined. Maybe something went wrong when you built GPC? (Some foreign config file or config cache lying around, I don't know... Do you build GPC for several platforms?)
Oh wait... this was a GPC binary built by Andris, right? Maybe he's used a newer DJGPP version which does have these functions, while yours (and mine) doesn't. This could explain the problem. (This should be reflected in the settings rts-config.inc in this binary.)
I don't follow DJGPP releases too closely, so I don't know. If it's a new official DJGPP release, it just means that this GPC binary requires that release. Otherwise, if it's a DJGPP developer version, a public GPC binary should probably not be built against it...
It seems I have build GPC using current CVS version of DJGPP ....
Andris
Frank Heckenbach wrote:
Maurice Lombardi wrote:
Running the gpc test suite results in only one failure: y2k.pas (which is new). The problem is with the function sleep: Has this function been changed recently ? (We have been discussing at length of various delay functions).
Nope. (I haven't gotten around to doing anything about the delay issue yet, and AFAIUI, it doesn't affect sleep (whole seconds), anyway.)
What fails exactly?
First the test suite failed on this program. Then I have run it step by step under rhide (compiled with -D__BP_UNPORTABLE_ROUTINES__). The other functions give results as expected, but the sleep time seems to be zero. I have then recompiled from dos prompt with increasing sleep times (and deleting each time .o .gpi .gpm files to be sure) and run it. You may miss a 1 second delay, not a 10 or 100 seconds. No delay up to 10000 seconds, and then it stopped and I had not the patience to wait so long. (I had time to check from an other DOS window that date and time of the system have been changed and increased as expected).
The errors given below seem quite unrelated to
anything this test program does. Do they also occur when running the test suite, or are there other problems then?
To check I have also installed your abovementioned gpc2953b.zip and tried to compile y2k.pas. It fails with:
C:\djgpp\gnu\gcc-2.953\gcc\p\test>gpc y2k.pas -o y2k.exe --autobuild -D__BP_UNPO RTABLE_ROUTINES__ c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x49d):file.c: undefined reference to `lstat' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x18e2):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x266b):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x26a9):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x26e8):file.c: undefine d reference to `llseek' c:/djgpp/lib/gcc-lib/djgpp/2.953/libgpc.a(file.o)(.text+0x2802):file.c: undefine d reference to `llseek' collect2: ld returned 1 exit status
Only with this test program?
I have not yet checked others, I was thinking to this y2k problem.
This would seem quite strange. The
routines referenced by file.o in libgpc.a don't depend on the program being compiled, and file.o is used in any GPC program, so if there are really undefined references, they should occur with any program.
Oh wait... this was a GPC binary built by Andris, right? Maybe he's used a newer DJGPP version which does have these functions, while yours (and mine) doesn't. This could explain the problem. (This should be reflected in the settings rts-config.inc in this binary.)
I don't follow DJGPP releases too closely, so I don't know. If it's a new official DJGPP release, it just means that this GPC binary requires that release. Otherwise, if it's a DJGPP developer version, a public GPC binary should probably not be built against it...
Possible. I used as native compiler the simtelnet's gcc2953b.zip (the second one, updated recently) and bnu210b (andris seems to use previous bnu according to the CFLAGS options in djbuils1.sh, but I see no library in it).
Maurice
Maurice Lombardi wrote:
Frank Heckenbach wrote:
Maurice Lombardi wrote:
Only with this test program?
No I checked now: every demo program fails with the same error message. There is some inconsistency between andris setup and mine.
Maurice
Maurice Lombardi wrote:
Frank Heckenbach wrote:
Maurice Lombardi wrote:
Running the gpc test suite results in only one failure: y2k.pas (which is new). The problem is with the function sleep: Has this function been changed recently ? (We have been discussing at length of various delay functions).
Nope. (I haven't gotten around to doing anything about the delay issue yet, and AFAIUI, it doesn't affect sleep (whole seconds), anyway.)
What fails exactly?
First the test suite failed on this program. Then I have run it step by step under rhide (compiled with -D__BP_UNPORTABLE_ROUTINES__). The other functions give results as expected, but the sleep time seems to be zero. I have then recompiled from dos prompt with increasing sleep times (and deleting each time .o .gpi .gpm files to be sure) and run it. You may miss a 1 second delay, not a 10 or 100 seconds. No delay up to 10000 seconds, and then it stopped and I had not the patience to wait so long. (I had time to check from an other DOS window that date and time of the system have been changed and increased as expected).
I can't reproduce the problem. The test works in my DosEmu, at least. Perhaps you can play with the number in the program to find out if it fails when the delay should cross a day boundary (or year, or 0-based-century/millennium...). After all, it might be a bug in Dos or DJGPP (though I've looked at the DJGPP code, and it also seems correct to me)...
Frank
Frank Heckenbach wrote:
Running the gpc test suite results in only one failure: y2k.pas (which is new).
I can't reproduce the problem. The test works in my DosEmu, at least. Perhaps you can play with the number in the program to find out if it fails when the delay should cross a day boundary (or year, or 0-based-century/millennium...). After all, it might be a bug in Dos or DJGPP (though I've looked at the DJGPP code, and it also seems correct to me)...
Forget about it. It seems to be one of those W98 dos box niceties. The same binary y2k.exe work as expected (including variation of sleep times) on the same machine when booting in bare DOS mode (with cwsdmpi5) instead of W98 dos box ! Maurice
-
Andris Pavenis -
Andris Pavenis -
Frank Heckenbach -
Maurice Lombardi -
pavenis＠lanet.lv
-
Prof Abimbola Olowofoyeku -
Russ Whitaker