Dear Sirs, Before a few weeks, I fixed builds/unix/configure.raw to detect ANSI-incompatible macros in header files of Mac OS X Carbon framework and insert workarounds.
http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/builds/unix/configure.raw?r1=1.9&r2=1.10 http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftmac.c?r1=1.51&r2=1.52 http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/builds/mac/ftmac.c?r1=1.1&r2=1.2 But the ANSI incompatibility of Carbon headers I could check is only inlining macro (OS_INLINE), and there is possibility that further development can hit another ANSI incompatibility that I've not provided workaround. Thinking of such possibility, omitting ANSI mode CFLAGS can be easier to maintain than insertion of workaround collection (I thank Sean McBride for giving idea). However, my thought comes up from my short experience on Mac OS X header, not tested with wide variety of C compilers. There's anybody who experienced "compiling with ANSI C mode generates better results than compiling in default non-ANSI C mode"? Turner, have you ever heard of? Regards, mpsuzuki _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
