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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Joachim Nilsson
Hi!

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?

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

The file in question that triggered this is limits.h, which is #include_next
included from uClibc's limits.h:

armeb-redfox-linux-uclibc-4.3.2/lib/gcc/armeb-redfox-linux-uclibc/4.3.2/include-fixed/limits.h

Regards
 /Jocke

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

Reply | Threaded
Open this post in threaded view
|

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

Brian Dessent
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

Reply | Threaded
Open this post in threaded view
|

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

Joachim Nilsson
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

Reply | Threaded
Open this post in threaded view
|

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

Khem Raj-3
On (16/11/08 16:59), Joachim Nilsson wrote:

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

if you have -nostdinc then you have to specify it manually. glibc was
patched to use the new include path and so was uclibc. It should work
with uclibc 0.9.30

http://uclibc.org/cgi-bin/viewcvs.cgi/trunk/uClibc/Rules.mak?rev=19932&r1=19839&r2=19932

fixed it for uclibc.

Thx

-Khem

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