Fixincludes - some analysis

Don Smith don_smith at
Sun Jan 26 22:46:23 PST 2003

Greg Schafer wrote:
> Hi
> Could some knowledgable programmers look at this please?

Thanks Greg for posting this. I had never looked into these before
because you all seemed to be doing a fine job of testing these out. But
now I see what they're trying to fix. Matthias mentioned wchar_t is a
new builtin, but actually it's a new keyword. What that means is, if you
want your code to be ANSI C++ you *must* not define wchar_t anywhere in
your code *including* in the system headers. Just a guess here but GCC
may have some algorithm like "if wchar_t is defined set
gcc_version_for_checking to 2" instead of 3.
Since very little code that LFS is compiling is C++, much less the
latest ANSI standard C++, this will not cause problems for now. In fact,
if this is so, the fixincludes may actually break compiles of older code
since the more strict checks of 3 will now generate compilation errors.
There is an option that can be set to tell GCC that the code is old
style but it is late and I'm not going to look that up right now.

Anyway, to get rid of all definitions of wchar_t, fixincludes searches
for them and puts the "if C++ is not defined" preprocessor directives
around them. But what if these headers are being used by both GCC 2.95.3
and GCC 3.2 (for example while you are upgrading your development
environment)? You can't replace them in the normal /usr/include, so GCC
3 puts the fixed headers in it's own internal place that is included
before the normal headers.

Unfortunately for me I am using a package that uses the new features of
the latest ANSI C++ so now I realize that I must run fixincludes and
repair the packages that won't compile. More headaches for me. Whoopie!

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list