GCC fixincludes

[randy@…]

Perhaps it was just my build but there seems to be an issue with the GCC fixincludes. The test is pulling in an extra directory that has not been included before. This is from an entry in the "blanket ticket" ticket for the major package update recently (#2205).

Creating this ticket so that we address it whether it is an actual issue or not.

[DJ Lucas]

This is not an issue, and is intended by the GCC devs. We _could_ make it go away, but there will possibly be two (or more) directories added in the future. The extra directory needs to be explained in detail, however. Here is my understanding of it and attempt at keeping it simple, hopefully not over simplified (double check the names as I just started a fresh build and am going completely off of memory ATM):

Whether or not gcc needs to run the fix includes script, limits.h is unconditionally installed into the gcc private directory include-fixed. If the system's installed limits.h is good for general consumption (when using latest available), there is no need to 'fix' it. limits.h, as installed into the gcc private directory, contains #include "syslimits.h". syslimits.h is also in the private include-fixed directory, which simply includes the system installed limits.h file from the standard include path (#include_next <limits.h>). There is a related, but different issue WRT the search path in chapter 5 gcc that will be fixed this weekend.

[randy@…]

There was a note DJ created that sounded good that could be added to the pages where the 'include/fixed' directory is noticed.

That note was in ticket #2205.

[DJ Lucas]

Fixed in r8646.