Opened 15 years ago
Closed 15 years ago
#2229 closed defect (fixed)
|Reported by:||Owned by:||DJ Lucas|
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.
Change History (4)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
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.
comment:3 by , 15 years ago
|Status:||new → assigned|
comment:4 by , 15 years ago
|Status:||assigned → closed|
Fixed in r8646.
Note: See TracTickets for help on using tickets.
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.