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.)


Andreas

Hi Andreas,

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

Please check my reply on #946497 which is about the same problem in
zfs-dkms. Perhaps both of you find a solution that will work for the two
packages.

Andreas

Thanks for the pointer.

I think that having dkms set CC/etc. appropriately is probably the
architecturally cleanest solution (as dkms actually knows what kernel is
being built for), and am willing to try to dig into how that might happen,
time permitting.

That said, I have pretty severe time demands these days so can only get a
couple days of solid development time per month (split among several
projects); would you mind if I dropped the severity of this bug to prevent
autoremoval from testing while that work proceeds?

Thanks,

Ben

Control: severity -1 important
Control: retitle -1 openafs-modules-dkms: module wants to build with gcc instead of kernel's compiler

not at all

Andreas

Please depend on gcc if you cannot find a way to use the kernel
compiler. You cannot expect build-essential to be available.

Andreas

Hi Andreas,

Thanks for filing 984929.
Do you have a sense for what the cutoff should be for trying to get 984929
resolved vs. just uploading a workaround in the dkms-consuming packages
(e.g., openafs)?

Thanks,

Ben

Depends: gcc" suggestion is a rather bad hack (that does the right thing
only in some cases), especially after I found this rather easy (but
Debian specific) solution in dkms.

The patch is probably not suitable for upstream inclusion, as the
.kernelvariables file seems to be Debian specific. But a more general
solution getting the CC value from Kbuild might be a useful upstream
addition.


Andreas

I've just added a patch to dkms to export the kernel compiler used for
the headers as CC and the module build system automatically picks it up
and therefore uses the "correct" compiler for the module.
I'll attempt to get this unblocked for bullseye.

Therefore please *do not add Depends: gcc* as I suggested previously.

You might consider bumping the dkms dependency to
   dkms (>= 2.8.4-3~)
but that change alone is not worth an upload/unblock cycle.

Andreas

Hi Andreas,

Andreas Beckmann wrote:

Thanks! Much appreciated!

		Regards, Axel