On Wed, 21 Mar 2001, Mariano Alvarez Fernandez wrote:
Tried to build grx-2.4 for DJGPP using gcc-3.0 20010314. After modifying src/bgi/text7.c (gcc-3.0 20010314 miscompiles it with -O3 -fomit-frame-pointer) to workaround problem, all seems to work.
Can you provide the diff for the workaround (or can we expect that gcc will be fixed)?
I don't know whether gcc will be fixed.
Workaround was simple: I added prototype for 'static void _outtextxy (... ' and moved definition of this function to the end of source to avoid inlining.
Anyway. If we don't think to release next update soon, we should recheck compiling src/bgi/text7.c. It's easier for me to do it under Linux as I have current CVS version of gcc-3.0 bootstrapped and tested every night (cron task).
Some comments about results.
It seems that it's better to check for __DJGPP__ instead of __GO32__ (I don't know about DJGPP v1, but we're removing support for it anyway). See patch.
OK, I will apply the pach (__GO32__ was necessary for DJGPP v1), and I will merge src/makebase.dj and src/makefile.dj2 in next release.
If we're killing support for DJGPP v1 permenently, then it's Ok. However I cannot be sure that definition of __GO32__ will no reappear before release of gcc-3.0. Anyway __DJGPP__ is better define to check for ... (in case of DJGPP v2)
gcc-3.0 20010314 miscompiles src/bgi/text7 with '-O3 -fomit-frame-pointer' . Do we really need to use -O6 -fomit--frame-pointer to build optimized library? How much we're getting from that? Maybe it would be enough to use simply -O2? I sent bug report about this problem to gcc-bugs mailing list.
Really I don't know what -O6 means, the gcc docs don't say nothing about -O6. And note that we are using it in the four plattforms. So I can change it if you think is OK.
It's from PGCC where optimization levels >3 added somethng new. I have tried PGCC some times but never was satified with results. Perhaps it would be nice to build GRX with current options '-O3 -fomit-frame-pointer' (for gcc -O6 is the same as -O3) and with -O2 and compare results of speedtst in various modes
grx24/makedefs contains definition of default font path (fortunatelly commented out ...) : strcat(getenv("DJDIR"),"/contrib/grx24/fonts") which modifies value returned bu getenv() (but it must not be modified).
I think that it would be better to add install target in makefiles.
For DJGPP it could install libgrx20.a and include files in $DJDIR/lib and $DJDIR/include. Perhaps something like $DJDIR/share/grxfonts would be Ok for fonts.
For Linux we could use similar approach ($prefix/lib. $prefix/include, $prefix/share/grxfonts where prefix could be /usr or /usr/local)
This was a contribution by Maurice Lombardi, but I commented it out because I prefer to set the environment variable (or not set it at all to prove test programs).
Also I think thet we should change a way how more that one library is being built (like libgrx20.a and libgrx20.so.2.4.0 for Linux). One of the ways could be using different extension instead of .o for object files to be put in shared library.
Andris