Hi Andreas, On Tue, Nov 26, 2019 at 02:38:21AM +0100, Andreas Beckmann wrote: > Package: openafs-modules-dkms > Version: 1.8.5-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > openafs-modules-dkms/sid fails to build the kernel module for the > current kernel (5.3.0-2-amd64) in a minimal sid chroot with > linux-headers-amd64 installed: > > Setting up openafs-modules-dkms (1.8.5-1) ... > Loading new openafs-1.8.5 DKMS files... > It is likely that 5.2.14 belongs to a chroot's host > Building for 5.3.0-2-amd64 > Building initial module for 5.3.0-2-amd64 > Error! Bad return status for module build on kernel: 5.3.0-2-amd64 (x86_64) > Consult /var/lib/dkms/openafs/1.8.5/build/make.log for more information. > dpkg: error processing package openafs-modules-dkms (--configure): > installed openafs-modules-dkms package post-installation script subprocess > returned error exit status 10 > Processing triggers for libc-bin (2.29-3) ... > Errors were encountered while processing: > openafs-modules-dkms > > make.log contains: > > DKMS make.log for openafs-1.8.5 for kernel 5.3.0-2-amd64 (x86_64) > Fri Nov 15 21:42:48 UTC 2019 > checking for gcc... no > checking for cc... no > checking for cl.exe... no > configure: error: in `/var/lib/dkms/openafs/1.8.5/build': > configure: error: no acceptable C compiler found in $PATH > See `config.log' for more details > > So the sources are looking for "gcc" while they should get the correct > compiler to use from the kernel headers ... the module must be built > with the same compiler version as the kernel itself, which is not > neccessarily the system default "gcc", and for Debian it's always a > versioned gcc-N. (The linux-headers-<arch> packages transitively > depend on the correct versioned gcc package.)
I think I need some help to figure out the best thing to do here. For background, openafs is portable to a wide variety of OSes including Linux, Solaris, several BSDs, macOS, and AIX, and uses a kernel module to provide the network filesystem client functionality. The configure script does of course conditionalize its checks based on detected OS, but with my upstream hat on I'm pretty skeptical of encoding any distro-specific checks that would involve querying the dpkg database. (I'm also not sure I properly understand the need to use the exact same compiler as the base kernel -- is the calling convention ABI really going to change regularly? But feel free to treat that as an aside, as it's not unreasonable to expect) So, are you just saying that configure should be looking for various gcc-N while searching for a compiler, or are you saying that the debian packaging needs to be chasing the dpkg database for the kernel in question to find the appropriate compiler, and hardcoding that as the CC argument to configure? (This is of course more exciting since the actual kernel module build for openafs-modules-dkms does not occur at package build time, and the package also produces a package with module sources for non-dkms builds.) Your insight would be greatly appreciated. Thanks, Ben
