Andy Wingo skribis:
> So! CPATH is like -I but C_INCLUDE_PATH et al are like -isystem.
> Here's the docs for -isystem ("Preprocessor Options"):
>
> '-isystem DIR'
> Search DIR for header files, after all directories specified by
> '-I' but before the standard system directories. Mark it as a
> system directory, so that it gets the same special treatment as is
> applied to the standard system directories. If DIR begins with
> '=', then the '=' will be replaced by the sysroot prefix; see
> '--sysroot' and '-isysroot'.
>
> What is a system directory? Well, it's searched for after all -I
> includes, but also header files in it are marked as system headers.
> Many warnings are not issued for system headers; search the manual for
> the phrase "system headers". For example:
>
> '-Wsystem-headers'
> Issue warnings for code in system headers. These are normally
> unhelpful in finding bugs in your own code, therefore suppressed.
> If you are responsible for the system library, you may want to see
> them.
>
> So. We should be using C_INCLUDE_PATH instead of CPATH, to mark system
> headers as system headers. Except that C_INCLUDE_PATH only works for C,
> so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH. And
> that's the proposal of this bug :)
The intent of this “system header” classification, AIUI, is to not
bother users with issues in libc headers.
The problem is that if we use C_INCLUDE_PATH & co., every header in the
search path, not just libc’s, would now be considered a system header,
and thus exempt from warnings. This would be undesirable.
Here’s an experiment:
--8<---cut here---start->8---
$ guix environment --ad-hoc gcc ld-wrapper glibc binutils --container
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
In file included from sysp.c:1:0:
/gnu/store/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include/wchar.h: In
function 'wctob':
/gnu/store/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include/wchar.h:397:47:
error: comparison of unsigned expression >= 0 is always true
[-Werror=type-limits]
{ return (__builtin_constant_p (__wc) && __wc >= L'\0' && __wc <= L'\x7f'
^
cc1: some warnings being treated as errors
sh-4.3# echo $CPATH
/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/store/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include:/gnu/store/14xgip7wslikzqfkr67vln0kpcclwy37-linux-libre-headers-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include
sh-4.3# export
CPATH=/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/store/14xgip7wslikzqfkr67vln0kpcclwy37-linux-libre-headers-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
--8<---cut here---end--->8---
Where sysp.c is:
--8<---cut here---start->8---
#include
int foo () { return 42; }
--8<---cut here---end--->8---
Compare with this:
--8<---cut here---start->8---
$ guix environment --ad-hoc gcc ld-wrapper -e '(@@ (gnu packages commencement)
glibc-final)' binutils --container
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
sh-4.3# echo $CPATH
/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/include:/gnu/store/lyn2331ilik14yy2jqhndshvxmv9r6w5-linux-libre-headers-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include
--8<---cut here---end--->8---
The lesson here is that, if the libc headers that are in CPATH come from
the libc that GCC was built against, then they do not lose their
system-headerness.
Now, when using ‘gcc-toolchain’, CPATH contains an entry that is a
*symlink* to libc. So from the point of view of libcpp, these are not
system headers. Thus:
--8<---cut here---start->8---
$ guix environment --ad-hoc gcc-toolchain --container
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
In file included from sysp.c:1:0:
/gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include/wchar.h:
In function 'wctob':
/gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include/wchar.h:397:47:
error: comparison of unsigned expression >= 0 is always true
[-Werror=type-limits]
{ return (__builtin_constant_p (__wc) && __wc >= L'\0' && __wc <= L'\x7f'
^
cc1: some warnings being treated as errors
sh-4.3# echo $CPATH
/gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include
--8<---cut here---end--->8---
This particular problem with gcc-toolchain in ‘guix environment’ is
solved by this patch: