[Pkg-zfsonlinux-devel] Bug#946497: zfs-dkms: fails to build module for 5.3.0-3-amd64

[Andreas Beckmann]

On 10/12/2019 03.36, Petter Reinholdtsen wrote:
> [Andreas Beckmann]
>> during a test with piuparts I noticed your package failed to install.
> 
> Thank you for the heads up.  Looking at the attached log, I see gcc-9 is
> installed, and thus the error message is very strange:
> 
>>   Building initial module for 5.3.0-3-amd64
>>   configure: error: in `/var/lib/dkms/zfs/0.8.2/build':
>>   configure: error: no acceptable C compiler found in $PATH
>>   See `config.log' for more details
> 
> Can gcc be broken?  Or is it dkms?  Or something else?

If I run it manually in the chroot I get

# dkms build -k 5.3.0-3-amd64 zfs/0.8.2

Kernel preparation unnecessary for this kernel.  Skipping...

Running the pre_build script:
checking for gawk... no
checking for mawk... mawk
checking metadata... META file
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking whether make sets $(MAKE)... yes
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/var/lib/dkms/zfs/0.8.2/build':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

Building module:
cleaning build area...(bad exit status: 2)
make -j8 KERNELRELEASE=5.3.0-3-amd64...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.3.0-3-amd64 (x86_64)
Consult /var/lib/dkms/zfs/0.8.2/build/make.log for more information.


Why is the configure output missing from make.log?
(or from stdout/stderr if dkms gets run by the maintainer scripts?).

Installing linux-headers-something pulls in the compiler version
that was used to build the kernel (which always a versioned compiler
package and not neccessarily the same as the one gcc points to).

dkms packages that only use kbuild automatically use the correct
compiler (out-of-tree modules should be built with the same compiler
as the kernel itself, they often don't work if built with a different
compiler due to subtle abi differences).

Trying to reinvent compiler and flags is not a good idea.
dkms packages using configure etc scripts should rather somehow
query the kernel headers for the correct compiler (and flags) to be
used and only fall back to look for plain "gcc".

Thinking about it, maybe it would be a good idea for dkms to set
the CC (and other) environment variables according to the kernel
headers currently being processed.

For the proprietary nvidia module I had to patch the upstream build
system (which defers most things to kbuild) to
* not set CC=cc
* use KBUILD_FLAGS (excluding -Werror*)
* use KBUILD_LDFLAGS/LDFLAGS

> I notice
> <URL: https://ci.debian.net/packages/z/zfs-linux/testing/amd64/ >
> passed 2019-12-06 13:15:16 UTC.  Is the test insufficient to discover
> this problem, or did something change in the mean time?

This is not a minimal environment without the "gcc" meta-package.


Andreas