Arch Linux User Repository

@Bevan, not sure what the problem was, since I can build and install the dkms module by manually building it as root. Meaning the configure and build step succeed with root account and GCC 10. However, it was not working until today's update - which did not have anything to do with GCC, dkms or kernal at all. Anyway, it works now for no apparent reason.

kgizdov: Interesting. It looks like your GCC cannot find its own cc1 binary when called by dkms. Kind of similar to what has been described by another person at https://bbs.archlinux.org/viewtopic.php?id=255784

Is your system fully up-to-date? Are you using packages from testing? For me it works with dkms 2.8.1-3, in testing there is a different version.

fails to build the modules with following error:

==> dkms install openafs/1.8.6pre2 -k 5.4.43-1-lts
Error! Bad return status for module build on kernel: 5.4.43-1-lts (x86_64)
Consult /var/lib/dkms/openafs/1.8.6pre2/build/make.log for more information.
$ cat /var/lib/dkms/openafs/1.8.6pre2/build/make.log
DKMS make.log for openafs-1.8.6pre2 for kernel 5.6.15-arch1-1 (x86_64)
Fri May 29 16:21:39 EEST 2020
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/var/lib/dkms/openafs/1.8.6pre2/build':
configure: error: C compiler cannot create executables
See `config.log' for more details
$ cat /var/lib/dkms/openafs/1.8.6pre2/build/config.log
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=ht>
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)
configure:3161: $? = 0
configure:3150: gcc -V >&5
gcc: error: unrecognized command-line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3161: $? = 1
configure:3150: gcc -qversion >&5
gcc: error: unrecognized command-line option '-qversion'; did you mean '--version'?
gcc: fatal error: no input files
compilation terminated.
configure:3161: $? = 1
configure:3181: checking whether the C compiler works
configure:3203: gcc     conftest.c  >&5
gcc: fatal error: cannot execute 'cc1': execvp: No such file or directory
compilation terminated.
configure:3207: $? = 1
configure:3245: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenAFS"
| #define PACKAGE_TARNAME "openafs"
| #define PACKAGE_VERSION "1.8.6pre2"
| #define PACKAGE_STRING "OpenAFS 1.8.6pre2"
| #define PACKAGE_BUGREPORT "openafs-bugs@openafs.org"
| #define PACKAGE_URL "http://www.openafs.org/"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3250: error: in `/var/lib/dkms/openafs/1.8.6pre2/build':
configure:3252: error: C compiler cannot create executables

however, if I run the configure step in the DKMS config manually, it succeeds.

@fepf: linux-headers is only the correct choice if you use the linux package from the repositories. But there are also the LTS and the ZEN kernels + several others here in AUR. The dkms package already has all of the linux-*-headers packages as optional dependencies which is why I did not include them as optional dependency here.

This package should also have linux-headers as dependency, otherwise it will not compile as dkms module.

Seems to have been a transient thing with my installation. Not sure what went wrong that last time, but the main symptom was when rebuilding modules for the kernel, one of the threads would report as having become stuck for more than 120s or something along those lines.

For whatever reason, it's decided not to have problems this time around. The -j`nproc` thing is nice, but since ./configure is taking the vast majority of the time, it's really not a big deal.

@JMurph2015: Thanks for your report and the debugging. I wasn't aware of any issue until now. The issues caused by obtaining MAKEFLAGS from makepkg.conf have been eliminated in June already by entirely dropping that logic. They aren't worth the amount of pain, I agree.

So the issue you are seeing must be something different and I have never experienced that before. The -jnproc clearly is a convenient thing but still may be a good idea. The quoted "yes" should not make any difference. So the remaining change is quoting the call to 'make'. Could you try only applying that change to see if it fixes the issue for you? I'll gladly include it here but I'd like to know if it is the culprit.

By the way, I think I have a fix. I took a look at the nvidia DKMS configuration and noticed a couple of things.

First, they had the AUTOINSTALL=yes quoted to AUTOINSTALL="yes", which may have been the issue.

Second, they had the call to make quoted as 'make' for some interesting reason explained in the file regarding make flags.

And third (really this is just a convenience thing), they had -j`nproc` after the quoted call to make to speed compilation up.

Overall, making those changes, that results in the below file. This works correctly when I call "pacman -S linux", so I'd assume it works on an upgrade as well (as opposed to a reinstall). Thanks!

PACKAGE_NAME="openafs"
PACKAGE_VERSION="1.8.2"

BUILT_MODULE_NAME[0]="openafs"
BUILT_MODULE_LOCATION[0]="src/libafs/MODLOAD-$kernelver-SP"
DEST_MODULE_LOCATION[0]="/kernel/fs"
AUTOINSTALL="yes"

MAKE[0]="(./configure --prefix=/usr \
              --sysconfdir=/etc \
              --sbindir=/usr/bin \
              --libexecdir=/usr/lib \
              --disable-fuse-client \
              --with-linux-kernel-packaging \
              --with-linux-kernel-headers=${kernel_source_dir} \
          && 'make' -j`nproc`)"
CLEAN="[ ! -f Makefile ] || 'make' clean"

This is still not building on the pacman hook (even with MAKEFLAGS="-j16" set in my /etc/makepkg.conf). Just last night my kernel upgraded and I was really messed up because it prevented the kernel from installing correctly and when I rebooted things got really bad. I ended up having to use an archiso to remove openafs entirely, reinstall my kernel, then reboot and fix things. Whatever those MAKEFLAGS, they aren't worth that amount of pain.

Trying the command with "echo" also produced no output. Even after trying it with "remove" and later "install" again, there was not output. But the cause of problem seams to be identified by seally1186.