Package: libc6-dev Version: 2.3.2.ds1-22 Severity: normal /usr/include/limits.h tries to include limits.h from /usr/lib/gcc/.../include, via: #include_next <limits.h> on line 124 which is outside of its ifdef on _LIBC_LIMITS_H_
Thus, with the preprocessor shipped with gcc-4.0, this may cause an infinite recursion when a file in /usr/include calls: #include "limits.h" like in bug #317839. Because of the search path order in cpp-4.0, cpp will continually reread /usr/include/limits.h and never try the one in /usr/lib/gcc/.../include While, it is arguably a bug in a header which specifies "limits.h" instead of <limits.h>, it would be nice if /usr/include/limits.h handled this case as well. From my limited testing, it seems that a patch of: 122c122 < #if defined __GNUC__ && !defined _GCC_LIMITS_H_ --- > #if defined __GNUC__ && !defined _GCC_LIMITS_H_ && !defined > _LIBC_LIMITS_H_ would make the recursion more robust. Cheers, -Mike -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6-dev depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:3.3.6-1 The GNU C compiler ii gcc-2.95 [c-compiler] 1:2.95.4-22 The GNU C compiler ii gcc-3.2 [c-compiler] 1:3.2.3-9 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-7 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.4-3 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.1-1 The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
