This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Am 17.03.2016 um 14:42 schrieb Ismail Donmez:
On Thu, Mar 17, 2016 at 3:35 PM, Marco Atzeri <marco.atzeri@gmail.com> wrote:it seems to prefer gcc headers # 1 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 1 3 4 # 37 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 3 4 # 1 "/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/include/limits.h" 1 3 4 # 38 "/usr/bin/../lib/clang/3.7.1/include/limits.h" 2 3 4 # 17 "/usr/include/sys/dirent.h" 2 3 4I am looking at clang 3.7 headers on Linux so this might be not 100% same on Cygwin but, clang's limits.h has this on top: /* The system's limits.h may, in turn, try to #include_next GCC's limits.h. Avert this #include_next madness. */ #if defined __GNUC__ && !defined _GCC_LIMITS_H_ #define _GCC_LIMITS_H_ #endif which should prevent including gcc's own limits.h but looks like it doesn't.
Actually, that would only try to prevent expanding the contents of GCC's limits.h, by pre-setting its multiple-inclusion guard macro. Which means that the
#include_next<limits.h>following it now begins to look at GCC's version, bounces off the guard macro, and finishes. The actual system <limits.h> would have been #include_next'ed in turn (line 168 of /usr/lib/gcc/.../limits.h), but that was disabled by the above hack.
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |