As you can see in https://gist.github.com/2050618 the change to add -Werror=strict-prototypes to CFLAGS breaks building dyncall, which is bundled in nqp.
In the long run we probably shouldn't pass all of parrots CFLAGs to third party code to compile, but it's not economical to write another configure system for NQP. Maybe we could split CFLAGS into two options, one that contains those switches that should be used by downstream projects like NQP (those concerning binary compatibility, for example), and a second one that is private to parrot.
Yeah, Parrot passing all of the flags we expect to compile with down to all 3rd party/vendor code is probably not a feature.
+1 to @moritz's suggestion of splitting CFLAGS into internal/vendor
The reason why the build fails only on some platforms is probably related to the version of GNU make: according to the manual, make used to export variables by default, but no longer does so.
In particular, the recursive call to make which builds dyncall inherits its CFLAGS from Parrot only on older versions of make, whereas on newer ones, the value from the environment is used.
I'm glad to hear the general consensus be for "hide our more restrictive CFLAGS from others" rather than "dumb down our CFLAGS"
How did we fix this?
We have a makefile expander which deals with those ccwarn or optimize overrides, which can easily be used by all the languages.