Storing these CFLAGS is a bad idea in general, but it can become pretty nasty, as you might save flags that are not very compatible; for instance building eventmachine (that uses C++) on my system produces: cc1plus: warning: command line option "-Wno-format-zero-length" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wno-format-zero-length" is valid for C/ObjC but not for C++ cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++ Not nice.
Isn't this a bug with eventmachine (for not using CPPFLAGS instead of CFLAGS)? On my machine CPPFLAGS is actually empty, which is also a bug. It should be similar to the CXXFLAGS set during compile time of ruby.
CPPFLAGS if for the C Pre Processor, not C++ Compiler.
Since Makefiles generated by mkmf using rbconfig do not include CFLAGS in the linking line, this bug can trigger build failures on portage-multilib _if_ ruby was compiled with CFLAGS=-m32 but NOT LDFLAGS=-m32. Modern portage-multilib includes -m32 in LDFLAGS, however. This means that if ruby was compiled at least a half year ago, portage-multilib users might get bitten by compilation failures caused by this bug for project using mkmf.... So at one time this might have been a fatal bug for supporting portage-multilib, but no longer. I really need to work on keeping my system more up-to-date ;-).
