This seems to be needed for out-of-tree module builds since d57568fcad.
We do not yet understand why, but this will unblock the channels while
we figure it out.
Fixes: d57568fcad ("linuxManualConfig: install GDB scripts")
kernel.override overrides the invocation of buildLinux, not the
function in the file that defines the specific kernel version, so we
need to pass the arguments that buildLinux expects.
These are required to debug kernel modules. Since we're now able to
do that, there's another reason besides BTF to enable DEBUG_INFO, so
I've done that for pre-BTF kernel modules as well here.
For GDB to get configured correctly, vmlinux-gdb.py has to be two
directories up from scripts/gdb, and vmlinux has to be next to
vmlinux-gdb.py. The least invasive way to satisfy these constraints
is to make vmlinux a symlink, which GDB will resolve before looking
for vmlinux-gdb.py.
Tested both ways of getting the scripts into GDB that I know of:
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-iex 'add-auto-load-safe-path /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-ex 'source /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
Also tested that the strip changes don't result in meaningful output
size changes (there's some small variation due to BTF data not always
coming out the same size, which is unrelated), and built every kernel
I can on x86_64 to make sure I'm not relying on build system behaviour
specific to newer kernels.
We've basically been reimplementing this — by default it contains
vmlinux, dtbs (on applicable architectures), modules, and architecture
specific stuff like $(KBUILD_IMAGE) and a couple of other
miscellaneous files.
linux is unusual in that we include its sources in an output. There's
no point unpacking into /build when we're going to copy the sources
into $dev later. Let's unpack directly into the final destination of
the code, and save copying a whole kernel source tree (often across
filesystems!).
This also means that Kbuild knows the location of the sources, which
will allow us to install the GDB scripts — some scripts are generated,
and some are not, so the generated ones end up in the build directory,
accompanied by symlinks to the non-generated ones in the source
directory.
bpftools used to use the same version and sources as linux_latest, but
this was changed in f12d2f016b ("bpftools: decouple version from
linux_latest"), because it caused too many rebuilds.
Since then, it has languished. It came to my attention because
bpftool btf dump seems to be completely broken on recent kernels.
So, since it's a package that really needs to be kept up to date to be
compatible with the latest kernels, let's couple it to linuxHeaders
instead. linuxHeaders updates already have to go through staging, so
we won't suffer from extra rebuilds like we did when it was coupled to
the latest kernel directly, which goes straight to master.
The SDK was missing SDKSettings files. This is usually not a problem for
Nix builds, because we generate our own fake SDK structure when
necessary (in xcbuild), but not having these files blocks using the
upstream Apple SDK in tooling such as gen-frameworks.py.
Attempting to install the package via environment.systemPackages, as
describe in #212799, otherwise failed with a non-existent directory
error.
Co-authored-by: Martin Weinelt <hexa@darmstadt.ccc.de>
Version V1.3.0.4236 of mwprocapture (the Linux driver for the Magewell Pro Capture family) FTBFS when building against Linux 6.1 or newer.
This patch bumps the driver version to 1.3.0.4328 that Magewell published to address this issue. The 1.3.0.4328 release notes state:
> Fix problem: driver installation may fail on an operating system with kernel version 6.1 or 6.2.
pci.patch has also been dropped as that fix is now applied upstream.