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

[Joachim Nilsson <joachim dot nilsson at vmlinux dot org>]

On Sun, Nov 16, 2008 at 06:43:14AM -0800, Brian Dessent wrote:
> 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?
> [snip]
> 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>.

That's quite a list. *dazzled and confused*

> > 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.

My new toolchain, gcc-4.3.2 built with crosstool-ng @trunk-r1208, doesn't
do this, and neither did my gcc-4.2.4 with the gcc standard include path
when -nostdinc is applied.

In reply to Thomas Schwinge's question, linked below, Ian Lance Taylor
suggests that one should add -isystem, here: 

	http://gcc.gnu.org/ml/gcc/2007-12/msg00094.html in

It seems to be the best way for (ucfront) in my forked uClinux-dist/SnapGear
tree.  It's at least simple enough to add.

Regards
 /Jocke


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