Prof A Olowofoyeku (The African Chief) wrote:
I am building the snapshot at the moment for Mingw (gcc-2.93-8). The build process halted with errors relating to undefined "sys_siglist" in gpc.c. I checked up on this, and had to comment out the declaration below: "#define strsignal(N) (sys_siglist[(N)])"
Under Mingw strsignal() is defined in libiberty.h,
In gcc-2.95.3 (I assume your 2.93 was a typo) the declaration in libiberty is commented out. Does Mingw use some special patches to libiberty.h? If so, what do they look like? If they `#define strsignal', it should be enough to put an `#ifndef strsignal' around the definition in gpc.c. Or does it provide an external declaration?
Try the following:
--- /home/gpc/orig/gpc.c Wed Nov 6 07:35:25 2002 +++ /home/gpc/p/gpc.c Thu Nov 14 00:38:03 2002 @@ -125,17 +125,21 @@ #define PEXECUTE_LAST 2 #define PEXECUTE_SEARCH 4 #define PEXECUTE_VERBOSE 8 +#ifndef HAVE_STRSIGNAL +#define strsignal(N) (sys_siglist[(N)]) +#endif #endif #if defined (EGCS) && !defined (EGCS97) +/* If the system doesn't provide strsignal, we get it defined in + libiberty but no declaration is supplied. */ +#if !defined (HAVE_STRSIGNAL) && !defined (strsignal) +extern const char *strsignal PARAMS ((int)); +#endif #undef _ #define _(String) String #endif #ifndef HOST_BIT_BUCKET #define HOST_BIT_BUCKET "/dev/null" -#endif - -#ifndef HAVE_STRSIGNAL -#define strsignal(N) (sys_siglist[(N)]) #endif
#ifdef GCC_2_95_3
but it seems that the configure script doesn't look there.
I suppose not. Since libiberty.h is distributed with gcc, it can assume it knows what's in there.
Or is for some reason another libiberty.h (system-wide installed) used instead of the one that comes with gcc? That might be a bug in the build process.
Frank
Hi Frank
I am building the snapshot at the moment for Mingw (gcc-2.93-8). The build process halted with errors relating to undefined "sys_siglist" in gpc.c. I checked up on this, and had to comment out the declaration below: "#define strsignal(N) (sys_siglist[(N)])"
Under Mingw strsignal() is defined in libiberty.h,
In gcc-2.95.3 (I assume your 2.93 was a typo)
It was. I was referring to gcc-2.95.3-8 (Mingw special)
the declaration in libiberty is commented out. Does Mingw use some special patches to libiberty.h?
Sorry - I actually found that they are commented out as well (I used "grep" before, but this time I opened the file and looked inside it).
If so, what do they look like? If they `#define strsignal', it should be enough to put an `#ifndef strsignal' around the definition in gpc.c. Or does it provide an external declaration?
It is commented out, as follows:
/*extern const char *strsignal PARAMS ((int));*/
/* Return the name of a signal number (e.g., strsigno (SIGHUP) returns "SIGHUP"). */
extern const char *strsigno PARAMS ((int));
/* Given the name of a signal, return its number. */
extern int strtosigno PARAMS ((const char *));
But it strsignal exists in libiberty.a, and the patch that you sent works.
but it seems that the configure script doesn't look there.
I suppose not. Since libiberty.h is distributed with gcc, it can assume it knows what's in there.
There is a copy in "/mingw/include/" (the system include directory). Should it not be there?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
but it seems that the configure script doesn't look there.
I suppose not. Since libiberty.h is distributed with gcc, it can assume it knows what's in there.
There is a copy in "/mingw/include/" (the system include directory). Should it not be there?
It may be there, but it shouldn't be used while building GCC/GPC since GCC comes with its own copy. (Since things work now, I assume that's what happens.)
Frank
Well, almost ;)
I have created an ebuild for gpc-20021111 that builds against default-x86-1.4 profile of Gentoo Linux. This is a profile for gcc-3.2/glibc-2.3.1 based system (this profile is officially supported for a few month now).
gpc builds fine, running tests I get the following statistics:
[clean-up headers skipped] Testing gpc 20021111, based on gcc-3.2 (i686-pc-linux-gnu) (groug.home.net) [lots of error messages skipped] # of GPC tests 2828 # of GPC tests passed 2645 # of GPC tests skipped 4 # of GPC tests failed 179
Which is probably not bad, considering significant version change. Most of errors are "internal compiler error". Frank: would you be interested in me sending you the full test report (47k)? (there is no rush on my side. It is perfectly fine to wait until you will release the version for gcc-3.2. This is essentially a prototype ebuild). What other information would you like?
Also, I did not commit the ebuild to the main portage tree yet, as the test results are not quite ideal. If anybody on the list has access to gentoo system and would be interested in testing this I may commit the ebuild (of course it will stay masked, i.e. will not belong to the stable profile). Meanwhile you can find the ebuild at: http://cvs.gentoo.org/~george/gpc-20021111.ebuild.
The build procedure follows the lines of 2.1 release. Only the gpc front-end gets installed, relying on the same version of gcc being already on the system (its presence and version correspondence are garanteed by the design of portage (package manager for Gentoo)). Frank: is this still appropriate? Or does this version introduce some non-trivial changes into the gcc-3 backend? I would really appreciate if you could glance at the src_install function in the ebuild and confirm that I am not missing any important files.
Few remarks on ebuild: 1. GCC_PV is defined for future "transparrent" support of both gcc-2.95.x and gcc-3.x. Right now it is fixed at 3.2 by DEPEND definition. 2. P,PV will get assigned "gpc-${PV}" and "20021111" correspondingly.
Thanks for the great work!
George
gpc builds fine, running tests I get the following statistics:
[clean-up headers skipped] Testing gpc 20021111, based on gcc-3.2 (i686-pc-linux-gnu) (groug.home.net) [lots of error messages skipped] # of GPC tests 2828 # of GPC tests passed 2645 # of GPC tests skipped 4 # of GPC tests failed 179
Looks that you run test suite in the default mode -- with debug info enabled. Currentely the '-g' option does NOT work (6% failing tests means it is unusable). With debug option removed from test Makefile one test is expected to fail.
George Shapovalov wrote:
Well, almost ;)
I have created an ebuild for gpc-20021111 that builds against default-x86-1.4 profile of Gentoo Linux. This is a profile for gcc-3.2/glibc-2.3.1 based system (this profile is officially supported for a few month now).
gpc builds fine, running tests I get the following statistics:
[clean-up headers skipped] Testing gpc 20021111, based on gcc-3.2 (i686-pc-linux-gnu) (groug.home.net) [lots of error messages skipped] # of GPC tests 2828 # of GPC tests passed 2645 # of GPC tests skipped 4 # of GPC tests failed 179
Which is probably not bad, considering significant version change. Most of errors are "internal compiler error".
Not to disturbe your euphoria, but IMHO that's quite bad. Consider that most of the tests test only one specific feature, so if one out of 16 tests fails, any program that uses 16 features would not work (well, a very rough estimate ;-), which includes basically all real-world programs ...
But wait, you did not by any chance run the test with debug info left enabled? As I wrote in my announcement, debug info generation with a gcc-3 backend *is* broken, and such a large number of failures is expected. I hope that's the case and you get a better result without debug info, but then still you might want to warn users of the ebuild about this problem, and to provide a 2.x based version for "production use".
The build procedure follows the lines of 2.1 release. Only the gpc front-end gets installed, relying on the same version of gcc being already on the system (its presence and version correspondence are garanteed by the design of portage (package manager for Gentoo)). Frank: is this still appropriate? Or does this version introduce some non-trivial changes into the gcc-3 backend?
All the changes made to the backend are conditionalized for GPC, and not used by other compilers (they are essential for GPC, of course). So the C compiler (cc1), libgcc.a and all the other files of the gcc installation need no change, and the Pascal compiler (gpc1) includes its modified backend files, so it should be alright.
I would really appreciate if you could glance at the src_install function in the ebuild and confirm that I am not missing any important files.
I'm not online while I'm writing this, but here's a list of files that should be installed, provided gcc is already installed:
<prefix>/bin/gpc <prefix>/bin/gpc-run <prefix>/lib/gcc-lib/<target>/<version>/units/rts-config.inc <prefix>/lib/gcc-lib/<target>/<version>/units/gpc.pas <prefix>/lib/gcc-lib/<target>/<version>/units/* (see source p/units dir except gpc-in-c.h) <prefix>/lib/gcc-lib/<target>/<version>/include/gpc-in-c.h <prefix>/lib/gcc-lib/<target>/<version>/gpc1 <prefix>/lib/gcc-lib/<target>/<version>/gpcpp <prefix>/lib/gcc-lib/<target>/<version>/libgpc.a <prefix>/info/gpc.info* <prefix>/info/gpcs-de.info <prefix>/info/gpcs-hr.info <prefix>/info/gpcs.info <prefix>/doc/gpc/demos/* (see source p/demos dir) <prefix>/doc/gpc/docdemos/* (run extract-doc-demos to get list of files) <prefix>/doc/gpc/README <prefix>/doc/gpc/NEWS <prefix>/doc/gpc/INSTALL <prefix>/doc/gpc/FAQ <prefix>/doc/gpc/AUTHORS <prefix>/doc/gpc/COPYING <prefix>/doc/gpc/COPYING.LIB <prefix>/doc/gpc/BUGS <prefix>/man/man1/gpc.1 <prefix>/man/man1/gpc-run.1
Frank
Hi
On Saturday 16 November 2002 08:39, Frank Heckenbach wrote:
George Shapovalov wrote: Not to disturbe your euphoria, but IMHO that's quite bad. Consider that most of the tests test only one specific feature, so if one out of 16 tests fails, any program that uses 16 features would not work (well, a very rough estimate ;-), which includes basically all real-world programs ...
This is why I did not add it even with the "testing" status yet. We will keep gcc-2.95.x based version available for a long time (as long as gcc-2 based profile, which is not going to go into oblivion any foreseeble time). The presently released alphas are going to be masked - that is to have a "testing" status so that they are not available to anybody who does not specifically selects so, and that is only after the package gets built and runs successfully.
But wait, you did not by any chance run the test with debug info left enabled? As I wrote in my announcement, debug info generation
Thanks for that suggestion! (and thatnk to Waidek too). I did not realize that tests/Makefile forces debug info on. I repeated the tests after removing "-g" option, now it looks just as expected (1 failure only):
[gerr@groug test]$ nice -n 5 make Running the GPC Test Suite. This may take a while ... [skipped few setup lines] Testing gpc 20021111, based on gcc-3.2 (i686-pc-linux-gnu) (groug.home.net) echo "gpc -O3 -Wall " gpc -O3 -Wall PC="gpc" PFLAGS="--autobuild -O3 -Wall " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | "./test_sum" TEST agettext2test.pas: failed 3: foobar (bazqux) TEST fjf480a.pas: SKIPPED: librx not installed TEST fjf480b.pas: SKIPPED: librx not installed TEST fjf480c.pas: SKIPPED: librx not installed TEST regextest.pas: SKIPPED: librx not installed
# of GPC tests 2828 # of GPC tests passed 2823 # of GPC tests skipped 4 # of GPC tests failed 1
Thus I feel relieved and can consider this version worth of going into the tree with a testing status (and a big warning about broked debug info generation is definitely due).
I would really appreciate if you could glance at the src_install function in the ebuild and confirm that I am not missing any important files.
I'm not online while I'm writing this, but here's a list of files that should be installed, provided gcc is already installed:
[list skipped]
Looks like I have everything listed installed. Thanks!
George
George Shapovalov wrote:
We will keep gcc-2.95.x based version available for a long time (as long as gcc-2 based profile, which is not going to go into oblivion any foreseeble time).
But maybe it will WRT GPC. If all goes well, I plan to drop gcc-2 support shortly after the release of GPC 2.2 (probably sometime next year). Hope that won't be a problem for you. For GPC development, it will make life a bit easier, not having to deal with the backend differences, once the new version works (at least as well as 2.x) on all platforms.
Thanks for that suggestion! (and thatnk to Waidek too). I did not realize that tests/Makefile forces debug info on. I repeated the tests after removing "-g" option, now it looks just as expected (1 failure only):
TEST agettext2test.pas: failed 3: foobar (bazqux)
That's not the expected one (fjf341b.pas, only with `--enable-checking').
Apparently the temporary installation of a locale (cf. gettext2.cmp) doesn't work right. It's certainly not a serious problem, and it might well be in the test program/script rather than the Intl unit or even the compiler, but you might want to try and debug it ...
Frank
-
Frank Heckenbach -
George Shapovalov -
Prof A Olowofoyeku (The African Chief) -
Waldek Hebisch