From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#30756: gcc7 doesn't find stdlib.h Date: Fri, 04 May 2018 22:39:46 +0200 Message-ID: <87fu37rw8d.fsf@gnu.org> References: <87fu59zagv.fsf@gnu.org> <5212cd7e-5f52-2826-2f65-9b66af4e73ad@mortis.eu> <87d0ybvbep.fsf@gnu.org> <36478fc2-98e7-0ebd-9048-7193fd240f5c@mortis.eu> <87k1sjsan9.fsf@gnu.org> <58dc244a-8ff5-fb1f-8c7b-d6745c1f2558@mortis.eu> <87zi1fid9r.fsf@netris.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:4830:134:3::10]:50846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEhUs-0002po-G4 for bug-guix@gnu.org; Fri, 04 May 2018 16:40:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fEhUo-0000oZ-Gt for bug-guix@gnu.org; Fri, 04 May 2018 16:40:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:42100) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fEhUo-0000oU-DL for bug-guix@gnu.org; Fri, 04 May 2018 16:40:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fEhUo-0005Tt-5w for bug-guix@gnu.org; Fri, 04 May 2018 16:40:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87zi1fid9r.fsf@netris.org> (Mark H. Weaver's message of "Fri, 04 May 2018 12:41:52 -0400") 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" To: Mark H Weaver Cc: 30756@debbugs.gnu.org, Giel van Schijndel Mark H Weaver skribis: > On my own private branch, I worked around this problem by adding > "-idirafter /include" to CXXFLAGS, but of course it's not a proper > fix. My workaround happens to be in Savannah on the > 'reproduce-bug-29774' branch: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?h=3Dreproduce-bug-29= 774&id=3D87022e2666c5e68e865eb160a4bd8e9cdcc1a955 Perhaps we could achieve the same effect by adding =E2=80=9C-idirafter LIBC/include=E2=80=9D to the default spec file, under =E2=80=98cpp_options= =E2=80=99? (We=E2=80=99d achieve that by modifying the value of =E2=80=98cpp_options= =E2=80=99 in gcc/gcc.c.) I suppose that would fix the include_next issue that Giel describes? Ludo=E2=80=99.