From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH Date: Thu, 17 Dec 2015 22:43:17 +0100 Message-ID: <87mvt8iwei.fsf@inria.fr> References: <871tama22g.fsf@igalia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9gLG-0005uD-Me for bug-guix@gnu.org; Thu, 17 Dec 2015 16:44:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9gLC-0007m0-L2 for bug-guix@gnu.org; Thu, 17 Dec 2015 16:44:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:47188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9gLC-0007lw-HU for bug-guix@gnu.org; Thu, 17 Dec 2015 16:44:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a9gLC-00024S-AN for bug-guix@gnu.org; Thu, 17 Dec 2015 16:44:02 -0500 In-Reply-To: <871tama22g.fsf@igalia.com> Sender: "Debbugs-submit" Resent-Message-ID: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Andy Wingo Cc: 22186@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 > '=3D', then the '=3D' 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 s= ee > 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 =E2=80=9Csystem header=E2=80=9D 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=E2=80=99s, would now be considered a system head= er, and thus exempt from warnings. This would be undesirable. Here=E2=80=99s an experiment: --8<---------------cut here---------------start------------->8--- $ guix environment --ad-hoc gcc ld-wrapper glibc binutils --container sh-4.3# gcc -Werror=3Dtype-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 >=3D 0 is always true [-Werror= =3Dtype-limits] { return (__builtin_constant_p (__wc) && __wc >=3D L'\0' && __wc <=3D L'\x= 7f' ^ cc1: some warnings being treated as errors sh-4.3# echo $CPATH /gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/st= ore/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include:/gnu/store/14xgip7w= slikzqfkr67vln0kpcclwy37-linux-libre-headers-3.14.37/include:/gnu/store/0wq= 6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include sh-4.3# export CPATH=3D/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils= -2.25.1/include:/gnu/store/14xgip7wslikzqfkr67vln0kpcclwy37-linux-libre-hea= ders-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/= include sh-4.3# gcc -Werror=3Dtype-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 commenceme= nt) glibc-final)' binutils --container sh-4.3# gcc -Werror=3Dtype-limits -O2 -c sysp.c sh-4.3# echo $CPATH /gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/st= ore/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/include:/gnu/store/lyn2331i= lik14yy2jqhndshvxmv9r6w5-linux-libre-headers-3.14.37/include:/gnu/store/0wq= 6hcbfjh5clyz6pjcqxjkl60rmijjf-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 =E2=80=98gcc-toolchain=E2=80=99, CPATH contains an entry th= at 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=3Dtype-limits -O2 -c sysp.c In file included from sysp.c:1:0: /gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include/wch= ar.h: In function 'wctob': /gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include/wch= ar.h:397:47: error: comparison of unsigned expression >=3D 0 is always true= [-Werror=3Dtype-limits] { return (__builtin_constant_p (__wc) && __wc >=3D L'\0' && __wc <=3D L'\x= 7f' ^ 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 =E2=80=98guix environment=E2= =80=99 is solved by this patch: --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index 73b0ce4..fbf4361 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -794,9 +794,13 @@ COREUTILS-FINAL vs. COREUTILS, etc." (let ((out (assoc-ref %outputs "out"))) - (match %build-inputs - (((names . directories) ...) - (union-build out directories))) + (define (select label) + (assoc-ref %build-inputs label)) + + (union-build out + (list (select "gcc") + (select "ld-wrapper") + (select "binutils"))) (union-build (assoc-ref %outputs "debug") (list (assoc-ref %build-inputs @@ -820,8 +824,9 @@ and binaries, plus debugging symbols in the 'debug' output), and Binutils.") (inputs `(("gcc" ,gcc) ("ld-wrapper" ,(car (assoc-ref %final-inputs "ld-wrapper"))) ("binutils" ,binutils-final) - ("libc" ,glibc-final) - ("libc-debug" ,glibc-final "debug"))))) + ("libc-debug" ,glibc-final "debug"))) + + (propagated-inputs `(("libc" ,glibc-final))))) (define-public gcc-toolchain-4.8 (gcc-toolchain gcc-final)) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable However, this doesn=E2=80=99t help with the case where gcc-toolchain is installed in a profile. Libcpp does have a file canonicalization method, enabled by default (see --enable-canonical-system-headers.) Specifically, in files.c, =E2=80=98find_file_in_dir=E2=80=99 does: /* We try to canonicalize system headers. */ if (CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp) { char * canonical_path =3D maybe_shorter_path (path); Unfortunately, =E2=80=98maybe_shorter_path=E2=80=99 (which calls =E2=80=98l= realpath=E2=80=99 from libiberty) doesn=E2=80=99t seem to be called for libc headers, presumably because it=E2=80=99s too late: file->dir->sysp is false. In summary, so far I can only think of half a solution, which is the =E2=80=98gcc-toolchain=E2=80=99 fix above. Thoughts? Ludo=E2=80=99. --=-=-=--