[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiling a linux kernel from git
From: |
Mark H Weaver |
Subject: |
Re: Compiling a linux kernel from git |
Date: |
Sat, 06 Jul 2019 18:21:50 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hi Chris,
Christopher Lemmer Webber <address@hidden> writes:
> Unfortunately my laptop was failing and I needed to pick up a new one
> asap before a conference I leave for tomorrow morning, so I bought one
> off the shelf from a retail store. Also unfortunately, while the
> hardware is supported in upstream linux, it isn't in any of the released
> tarballs yet. I thought I'd try to make a package derivative:
>
> (define linux-next
> (package
> (inherit linux-libre)
> (name "linux-next")
> (version "22c45ec32b4a9fa8c48ef4f5bf9b189b307aae12")
> (source
> (origin
> (method git-fetch)
> (uri (git-reference
> (url (string-append "https://git.kernel.org/pub/scm/linux/"
> "kernel/git/next/linux-next.git"))
> (commit version)))
> (file-name (string-append "linux-next-" version "-checkout"))
> (sha256
> (base32
> "1f3fn2mcfa213vb0d40386533dy4nll9v9d2jc6bi7gd38z2rc18"))))))
>
> Unfortunately an extra step seems to be necessary, or something. It's
> failing at the "make oldconfig" stage:
>
>
> patch-shebang: ./tools/usb/usbip/autogen.sh: changing `/bin/sh' to
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> patch-shebang: ./tools/usb/usbip/cleanup.sh: changing `/bin/sh' to
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> patch-shebang: ./tools/usb/usbip/vudc/vudc_server_example.sh: changing
> `/bin/bash' to
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash'
> patch-shebang: ./tools/virtio/ringtest/run-on-all.sh: changing `/bin/sh' to
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> patch-shebang: ./tools/vm/slabinfo-gnuplot.sh: changing `/bin/bash' to
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash'
> patch-shebang: ./usr/gen_initramfs_list.sh: changing `/bin/sh' to
> `/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
> phase `patch-source-shebangs' succeeded after 4.8 seconds
> starting phase `work-around-gcc-7-include-path-issue'
> phase `work-around-gcc-7-include-path-issue' succeeded after 0.0 seconds
> starting phase `configure'
> `ARCH' set to `x86_64'
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> In file included from
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/stdlib.h:394:0,
> from scripts/kconfig/conf.c:9:
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/sys/types.h:42:18:
> error: conflicting types for 'loff_t'
> typedef __loff_t loff_t;
> ^~~~~~
> In file included from
> /gnu/store/3qbgfljvmyi12df4yiwjnlg7mwkc4z1y-linux-next-22c45ec32b4a9fa8c48ef4f5bf9b189b307aae12-checkout/include/linux/limits.h:6:0,
> from
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/bits/local_lim.h:38,
> from
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/bits/posix1_lim.h:161,
> from
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/include/limits.h:183,
> from
> /gnu/store/rvv5rw5gcrpmbgnvhb60f7czk0m0h2qp-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed/limits.h:194,
> from
> /gnu/store/rvv5rw5gcrpmbgnvhb60f7czk0m0h2qp-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed/syslimits.h:7,
> from
> /gnu/store/rvv5rw5gcrpmbgnvhb60f7czk0m0h2qp-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/include-fixed/limits.h:34,
> from scripts/kconfig/conf.c:7:
> /gnu/store/3qbgfljvmyi12df4yiwjnlg7mwkc4z1y-linux-next-22c45ec32b4a9fa8c48ef4f5bf9b189b307aae12-checkout/include/linux/types.h:46:26:
> note: previous declaration of 'loff_t' was here
> typedef __kernel_loff_t loff_t;
> ^~~~~~
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. For now, I
would try packing the git checkout as a tarball, and then using that
tarball as your 'source'.
Mark