From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lemmer Webber Subject: Re: Compiling a linux kernel from git Date: Sun, 07 Jul 2019 03:00:21 -0400 Message-ID: <87y31acosa.fsf@dustycloud.org> References: <877e8v5ezu.fsf@dustycloud.org> <87pnmm9535.fsf@netris.org> <87h87y8pk6.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:470:142:3::10]:51044) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hk5qJ-0002ev-7L for help-guix@gnu.org; Sun, 07 Jul 2019 08:00:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hk5qI-0001hP-5q for help-guix@gnu.org; Sun, 07 Jul 2019 08:00:31 -0400 Received: from dustycloud.org ([50.116.34.160]:54108) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hk5qH-0001bF-Ey for help-guix@gnu.org; Sun, 07 Jul 2019 08:00:30 -0400 In-reply-to: <87h87y8pk6.fsf@netris.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Mark H Weaver Cc: help-guix Mark H Weaver writes: > Hi Chris, > > I wrote earlier: >> My first guess is that '/gnu/store/=E2=80=A6-linux-next-=E2=80=A6-checko= ut/include' >> should not be in the C include path while compiling that file, but that >> it's getting added. The difference might be due to the fact that the >> 'source' in this case is a directory instead of a tarball. > > I see now what's happening more precisely. Our gcc-7 package inherits > from gcc-6 'native-search-paths' for the CPATH variable. Because of > this, the 'set-paths' phase in 'gnu-build-system' sets the CPATH to > include /include for all native inputs that are > directories with an 'include' subdirectory. > > The 'source' is itself a native input. When it's a tarball, it will not > be included, but when it's a source checkout, it _is_ included, although > it shouldn't be. Oh, that's quite curious. >> For now, I would try packing the git checkout as a tarball, and then >> using that tarball as your 'source'. > > I'm now fairly confident that this workaround would work. Another > workaround would be to add another phase that removes the CPATH > component corresponding to 'source', as Tobias does. > > Mark Thanks! I got things working by going the tarball route, though slightly more indirectly than the approach you suggested here. What I did was get the latest release-candidate tarball and list the patches I specifically needed in the package definition. Happily this worked! Happy to say I'm on my way to the conference with a functioning laptop.