From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#30756: gcc7 doesn't find stdlib.h Date: Fri, 04 May 2018 12:41:52 -0400 Message-ID: <87zi1fid9r.fsf@netris.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> 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]:41924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEdoT-0006Vb-OV for bug-guix@gnu.org; Fri, 04 May 2018 12:44:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fEdoQ-0002TU-J6 for bug-guix@gnu.org; Fri, 04 May 2018 12:44:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:42031) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fEdoQ-0002TO-Eq for bug-guix@gnu.org; Fri, 04 May 2018 12:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fEdoQ-0008Hf-6O for bug-guix@gnu.org; Fri, 04 May 2018 12:44:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <58dc244a-8ff5-fb1f-8c7b-d6745c1f2558@mortis.eu> (Giel van Schijndel's message of "Fri, 4 May 2018 18:03:38 +0200") 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: Giel van Schijndel Cc: 30756@debbugs.gnu.org Giel van Schijndel writes: > On 04-05-18 17:28, Ludovic Court=C3=A8s wrote: >> That=E2=80=99s probably because your package still includes gcc@5 as an = implicit >> input via =E2=80=98cmake-build-system=E2=80=99. >> >> You could use a procedure like this to remove implicit inputs and add >> your own GCC variant: >> >> --8<---------------cut here---------------start------------->8--- >> (define (package-with-specific-compiler p compiler) >> "Return P modified to be built with COMPILER." >> (package >> (inherit p) >> (arguments >> `(#:implicit-inputs? #f ,@(package-arguments p))) >> (native-inputs `(("compiler" ,compiler) >> ,@(package-native-inputs p))) >> (inputs (append (package-inputs p) >> (alist-delete "gcc" (standard-packages)))))) >> --8<---------------cut here---------------end--------------->8--- >> >> =E2=80=A6 where =E2=80=98standard-packages=E2=80=99 comes from (guix bui= ld-system gnu). > This gives me: >> guix/build-system/cmake.scm:93:0: In procedure cmake-build: >> guix/build-system/cmake.scm:93:0: Unrecognized keyword: #:implicit-input= s? > >>> Would it be possible to filter the list of directories added to these >>> environment variables to exclude those already present in GCC's default >>> search path? >> I still don=E2=80=99t fully understand the issue actually. What=E2=80= =99s wrong with >> having these directories appear several times in the search path? >> >> The difficulty here will be that search path environment variables in >> Guix are populated automatically based on their specifications, so it=E2= =80=99s >> not all that clear to me where that filtering would happen. > > The problem seems to be triggered by glibc appearing on the search path. > > I'm not sure about GCC's internals exactly so I'm making one assumption > that causes all of this to make sense to me: if a directory appears > multiples times in the search path it will be searched only the first > time that it's encountered. > > So in short: contains an "#include_next " > preprocessor directive. That's a GCC extension that tells the > preprocessor it should only search directories appearing in the search > path _after_ the directory containing the file currently being processed. I ran into the same problem with our 'gjs' package in the 'core-updates' branch. First I added 'gcc-7' to the inputs to work around a different issue (an internal compiler error in gcc-5), and then I encountered the exact problem you described above. 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-2977= 4&id=3D87022e2666c5e68e865eb160a4bd8e9cdcc1a955 Mark