From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: bug#30756: GCC >= 6 '-isystem' and C_INCLUDE_PATH behavior changed, breaking Date: Tue, 21 Jan 2020 22:04:36 -0500 Message-ID: <878sm0kx8b.fsf@gmail.com> References: <87y2u3qh8b.fsf@gnu.org> <87r1zulsgc.fsf@gmail.com> <87sgkaik08.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47377) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iu6LH-0006jn-FP for bug-guix@gnu.org; Tue, 21 Jan 2020 22:06:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iu6LC-0003ba-A0 for bug-guix@gnu.org; Tue, 21 Jan 2020 22:06:07 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:42851) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iu6LC-0003bT-6K for bug-guix@gnu.org; Tue, 21 Jan 2020 22:06:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iu6LC-0006he-1i for bug-guix@gnu.org; Tue, 21 Jan 2020 22:06:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87sgkaik08.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Mon, 20 Jan 2020 09:56:23 +0100") 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-mx.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: reza.housseini@gmx.ch, 30756@debbugs.gnu.org, Reza Housseini Hello, Ludovic Court=C3=A8s writes: > Hi, > > Maxim Cournoyer skribis: > >> It'd be nice to find a correct solution, but it seems I can't even make >> the build system of Inkscape work after switching from CPATH to >> CPLUS_INCLUDE_PATH and stripping it from any glibc/gcc include >> directories (I don't get the "stdlib.h: No such file or directory." >> error anymore, but I now get: >> "/gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include/bits/err= no.h:26:11: >> fatal error: linux/errno.h: No such file or directory" instead, which I >> don't understand). >> >> I also tried moving the glibc include directory to the end of >> CPLUS_INCLUDE_PATH and it would still wouldn't be happy. Hmmph! > > Oh, really? I think that, as Mark H Weaver mentioned in this thread, if > we make sure that glibc comes next-to-last (before Linux-libre headers) > and appears only once in the list, it should work. > > Can you confirm? OK, so the errors I was getting about linux/errno.h missing was caused by my omission to *also* set C_INCLUDE_PATH to the content of CPATH, because Inkscape goes on building some bundled libraries which are C and not C++. After this was understood, Inkscape now builds successfully by simply taking out glibc from the inputs. Keeping GCC headers in seems OK, although I reckon if we fix this at the core (by extending what can be done which search path specifications) we should take it out as it could potentially cause problems: GCC keeps a reference to its own standard include directories, as shown by the command 'echo | ~a/bin/c++ -E -Wp,-v -'). On core-updates, this command, when ran in the following phase: --8<---------------cut here---------------start------------->8--- (add-before 'set-paths 'show-g++-internal-paths (lambda* (#:key inputs #:allow-other-keys) (system (format #f "echo | ~a/bin/c++ -E -Wp,-v -" (assoc-ref inputs "g= cc"))) #t)) --8<---------------cut here---------------end--------------->8--- gives: --8<---------------cut here---------------start------------->8--- starting phase `show-g++-internal-paths' ignoring nonexistent directory "/no-gcc-local-prefix/include" ignoring nonexistent directory "/gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0= -gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0/../../../../../../../= x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-u= nknown-linux-gnu/7.5.0/include /gnu/store/bhn2mqpnxabmllh1kclrmkqp8mhhvjb0-gcc-7.5.0-lib/lib/gcc/x86_64-u= nknown-linux-gnu/7.5.0/include-fixed /gnu/store/zw5f5g5aqlxam3imaylfla0i98nkridf-glibc-2.30/include End of search list. --8<---------------cut here---------------end--------------->8--- which lists references to GCC itself as well as to glibc. The use of -idirafter is to append a headers directory after *everything* else, including the compiler's own standard include paths. I think that to -idirafter glibc shouldn't have any effect, since glibc headers are already in the standard include path, and IIUC GCC will scan a header directory only once (the first time it encounters it). The GCC manual lists the include directories order as (c.f. the node 'Options for Directory Search' of the GCC reference manual): 1. For the quote form of the include directive, the directory of the current file is searched first. 2. For the quote form of the include directive, the directories specified by '-iquote' options are searched in left-to-right order, as they appear on the command line. 3. Directories specified with '-I' options are scanned in left-to-right order. 4. Directories specified with '-isystem' options are scanned in left-to-right order. 5. Standard system directories are scanned. 6. Directories specified with '-idirafter' options are scanned in left-to-right order. It'd be very cool to embed arbitrary logic such as sorting, filtering, or whatever else we need doing directly in a search path specification :-). Do you thing this could be done? Perhaps Gexps could be useful for this? Maxim