From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#36882: Qemu 4.2.0 build for x86_64-linux fails Date: Mon, 24 Feb 2020 15:25:20 +0100 Message-ID: <87tv3gm59r.fsf@gnu.org> References: <87k14gnqng.fsf@gmail.com> <87mu9b3crd.fsf@gnu.org> <87a75a5taw.fsf@gmail.com> <87o8tptu7u.fsf@gnu.org> <87ftf0nx7n.fsf@gmail.com> 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]:49402) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j6EgP-0002Q4-CD for bug-guix@gnu.org; Mon, 24 Feb 2020 09:26:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j6EgN-0007rQ-W9 for bug-guix@gnu.org; Mon, 24 Feb 2020 09:26:05 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:47066) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j6EgM-0007r6-Cs for bug-guix@gnu.org; Mon, 24 Feb 2020 09:26:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j6EgM-0003QD-94 for bug-guix@gnu.org; Mon, 24 Feb 2020 09:26:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87ftf0nx7n.fsf@gmail.com> (Mathieu Othacehe's message of "Mon, 24 Feb 2020 10:36:28 +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: Mathieu Othacehe Cc: 36882@debbugs.gnu.org Hi, Mathieu Othacehe skribis: >> So is it expected that C_INCLUDE_PATH comes before the hard-coded GCC >> include directory? How can we work around that? > > Turns out, the best source of documentation here is > gcc/incpath.c. Here's a summary of my understanding. > > Header search list: > > * QUOTE > -> -iquote=20 > * BRACKET > -> -I goes here > -> CPATH goes here > * SYSTEM > -> -isystem goes here > -> C_INCLUDE_PATH goes here > -> Hardcoded includes (gcc + glibc) goes here > * AFTER > -> -idirafter goes here. > > Duplicates inside SYSTEM are deleted, the first occurence is kept. So as > long as we have glibc in C_INCLUDE_PATH it will trigger deletion of > glibc in hardcoded includes and AFTER section. > > So I can see only two solutions here. > > 1. Go back to using CPATH (sad!), because when there is duplication > between BRACKET and SYSTEM, the include from SYSTEM is kept (why it > works on master). > > 2. Find a way to remove glibc from C_INCLUDE_PATH, but I have no clue > how to do this properly. Maybe using some kind of filter on > search-path-specifications. I=E2=80=99d rather go for #2. To do that, we could modify the =E2=80=98set= -paths=E2=80=99 phase to manually remove glibc from C_INCLUDE_PATH (fragile), or we could modify GCC (perhaps removing the =E2=80=98remove_duplicates=E2=80=99 call f= or SYSTEM). Either way, this wouldn=E2=80=99t work well with =E2=80=98guix environment= =E2=80=99, where glibc ends up in /gnu/store/=E2=80=A6-profile, so it does not appear as duplicate= to GCC. On =E2=80=98core-updates=E2=80=99, I see: --8<---------------cut here---------------start------------->8--- $ git log | head -3 commit 5afcb5caa53615c0a432e0c1781155398d747218 Author: Ludovic Court=C3=A8s Date: Sat Feb 22 21:39:27 2020 +0100 $ ./pre-inst-env guix environment -C -e '(@@ (gnu packages commencement) co= reutils-final)' [env]$ gcc -v -x c -E /dev/null Using built-in specs. COLLECT_GCC=3Dgcc Target: x86_64-unknown-linux-gnu Configured with:=20 Thread model: posix gcc version 7.5.0 (GCC)=20 COLLECT_GCC_OPTIONS=3D'-v' '-E' '-mtune=3Dgeneric' '-march=3Dx86-64' /gnu/store/0pjrnr8vhp94ykvarysd9wg7hcvfqkl5-gcc-7.5.0/libexec/gcc/x86_64-u= nknown-linux-gnu/7.5.0/cc1 -E -quiet -v /dev/null -mtune=3Dgeneric -march= =3Dx86-64 ignoring duplicate directory "/gnu/store/k9l4v4530p1a69j8qs0aijbmn8lwak20-p= rofile/include" ignoring nonexistent directory "/no-gcc-local-prefix/include" ignoring nonexistent directory "/gnu/store/adrw71v03nawqwyblxc0mdhcc41j5vnn= -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/k9l4v4530p1a69j8qs0aijbmn8lwak20-profile/include /gnu/store/adrw71v03nawqwyblxc0mdhcc41j5vnn-gcc-7.5.0-lib/lib/gcc/x86_64-u= nknown-linux-gnu/7.5.0/include /gnu/store/adrw71v03nawqwyblxc0mdhcc41j5vnn-gcc-7.5.0-lib/lib/gcc/x86_64-u= nknown-linux-gnu/7.5.0/include-fixed /gnu/store/ccjj5wg0qkjs1zfjr98nhb8cpr434izw-glibc-2.31/include End of search list. # 1 "/dev/null" # 1 "" # 1 "" # 31 "" # 1 "/gnu/store/k9l4v4530p1a69j8qs0aijbmn8lwak20-profile/include/stdc-prede= f.h" 1 3 # 32 "" 2 # 1 "/dev/null" COMPILER_PATH=3D/gnu/store/0pjrnr8vhp94ykvarysd9wg7hcvfqkl5-gcc-7.5.0/libex= ec/gcc/x86_64-unknown-linux-gnu/7.5.0/:/gnu/store/0pjrnr8vhp94ykvarysd9wg7h= cvfqkl5-gcc-7.5.0/libexec/gcc/x86_64-unknown-linux-gnu/7.5.0/:/gnu/store/0p= jrnr8vhp94ykvarysd9wg7hcvfqkl5-gcc-7.5.0/libexec/gcc/x86_64-unknown-linux-g= nu/:/gnu/store/adrw71v03nawqwyblxc0mdhcc41j5vnn-gcc-7.5.0-lib/lib/gcc/x86_6= 4-unknown-linux-gnu/7.5.0/:/gnu/store/adrw71v03nawqwyblxc0mdhcc41j5vnn-gcc-= 7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=3D/gnu/store/k9l4v4530p1a69j8qs0aijbmn8lwak20-profile/lib/:/gn= u/store/k9l4v4530p1a69j8qs0aijbmn8lwak20-profile/lib/:/gnu/store/adrw71v03n= awqwyblxc0mdhcc41j5vnn-gcc-7.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.5.0= /:/gnu/store/adrw71v03nawqwyblxc0mdhcc41j5vnn-gcc-7.5.0-lib/lib/gcc/x86_64-= unknown-linux-gnu/7.5.0/../../../:/gnu/store/ccjj5wg0qkjs1zfjr98nhb8cpr434i= zw-glibc-2.31/lib COLLECT_GCC_OPTIONS=3D'-v' '-E' '-mtune=3Dgeneric' '-march=3Dx86-64' --8<---------------cut here---------------end--------------->8--- Looking at =E2=80=98cppdefault.c=E2=80=99 in GCC, I don=E2=80=99t see where= glibc-2.31/include comes from; it seems that =E2=80=98INCLUDE_DEFAULTS=E2=80=99 is undefined o= n glibc systems. Thoughts? Incidentally, do we have problems building anything other than QEMU? Thanks, Ludo=E2=80=99.