| Summary: | host-x-host builds install broken limits.h | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Daniel Jacobowitz <drow> |
| Component: | other | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aoliva, gcc-bugs, vapier |
| Priority: | P2 | Keywords: | build |
| Version: | 3.1 | ||
| Target Milestone: | 4.0.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2005-07-12 21:46:14 | |
Daniel, do you know whether this problem is still present in 3.3 branch/mainline? Thanks, Dara See Dara's question. The bogus code is still present. It looks as if it will still be run, also. I believe the problem is still present. Confirmed by Daniel. Rrrright. I'm not quite sure what the correct thing to do is, since we do want to have the installed limits.h refer to the (target) system limits.h, but I'm planning to clean up limits.h handling, so I'm taking this. This was fully fixed with r13-2319-gbe9dd80f933480 . Though it was partly fixed with r0-49126-g7a615b25793c22 (for sysroots) and then changed again with r0-63126-gde253ca48a960d and then fixed for building fixincludes for the host by r0-63200-g53c7ffe7dd1c28. So this was basically fixed for GCC 4.0.0 with only a recent improvement for GCC 13 by allowing --disable-fixincludes . |
If $(LIMITS_H_TEST) is true, then the built <limits.h> references "syslimits.h". This test checks $(SYSTEM_HEADER_DIR), which is /usr/include in a typical host-x-host build (building a native compiler for a different target). Syslimits.h is only installed if fixincludes is run, which it is not for host-x-host builds; it's explicitly disabled: # And these apply if build != host. if test x$build != x$host then ... STMP_FIXINC= ... fi $(LIMITS_H_TEST) is a bit bogus anyway. This is a regression from 2.95, where fixinc was run regardless, and thus "syslimits.h" was installed. Release: 3.0, 3.1, HEAD