Re: Q: What is customary wrt GCC's include-fixed?

[Brian Dessent <brian at dessent dot net>]

Joachim Nilsson wrote:

> I've managed to build a fine new toolchain based on GCC v4.3.2 and uClibc
> v0.9.30.  Now, I've noticed that GCC today create a separate include-fixed
> directory for "fixed" includes, whatever that means.  What is customary
> for using the files therein?

The issue is that sometimes system headers are simply broken in some way
and won't work with gcc.  In some cases they are not valid ANSI C and
the vendor's compiler is just not as picky as gcc, but other times its
due to changes in gcc's strictness or semantics.  A recent example was
the change in "extern inline" semantics in 4.2 to match the C99 spec
rather than the old GNU semantics.

These headers are of course completely outside of the control of gcc,
such as when they are from a proprietary vendor's operating system.  But
even when they are part of another open-source project such glibc there
is still a significant delay for someone to propose a patch, get it
through review, and then wait for it to appear in the next release. 
Without some alternative workaround, upgrading gcc in these cases would
be impossible without waiting through these long delays or manually
upgrading libc.

So gcc has this "fixincludes" step to correct these problems.  When it
detects that a given target has a header that matches a given criteria,
it makes a private copy of the header and applies the fix.  You can see
the long list of fixincludes here:
<http://gcc.gnu.org/viewcvs/trunk/fixincludes/inclhack.def?view=markup>.

> Should I symlink/move everything from include-fixed/ to include/ or should
> I add -isystem ...include-fixed to my build system?

Neither.  It's an internal implementation detail of the compiler (which
is why they are stored under the private compiler directory) which is
meant to work transparently.  User code should simply #include
<limits.h> and the compiler should automatically have the correct search
paths built in such that it gets the fixes.

Brian

--
For unsubscribe information see http://sourceware.org/lists.html#faq