[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiling a linux kernel from git
From: |
Christopher Lemmer Webber |
Subject: |
Re: Compiling a linux kernel from git |
Date: |
Sun, 07 Jul 2019 03:00:21 -0400 |
User-agent: |
mu4e 1.2.0; emacs 26.2 |
Mark H Weaver writes:
> Hi Chris,
>
> I wrote earlier:
>> My first guess is that '/gnu/store/…-linux-next-…-checkout/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 <NATIVE_INPUT>/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.