>> Was it fixincludes or was it the mkheaders script ? >> >> and why ? > > Because system headers should not define something in the users namespace, > certainly not a non-uglified three-letter name such as "sun". > > Consider > > #include <Xlibint.h> > > int sun; > > which will not build otherwise.
I did find this .. and I see it in the 4.0.2 GCC tree also that I have here : $ cat /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.3.3/include-fixed/README This README file is copied into the directory for GCC-only header files when fixincludes is run by the makefile for GCC. Many of the files in this directory were automatically edited from the standard system header files by the fixincludes process. They are system-specific, and will not work on any other kind of system. They are also not part of GCC. The reason we have to do this is because GCC requires ANSI C headers and many vendors supply ANSI-incompatible headers. Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient". simply put .. it all looks good. I simply need to figure out how to release things to users or do I force a fixincludes/make headers script event during install or what. How does Debian and Ubuntu handle this ? When a user installs a pre-compiled ready to run GCC package do they get the headers "fixed" on the fly or do they get delivered ... -- Dennis Clarke
