[BUG] Unable to `make dkms` on up to date CentOS Stream 9 with kernel 5.14.0 - stdarg.h missing
kimma opened this issue · 3 comments
Bug description
Unable to make dkms on up to date CentOS Stream 9 with kernel 5.14.0
How to reproduce
What are the steps to reproduce the reported issue.
git clone https://github.com/snuf/iomemory-vsl.git
cd iomemory-vsl
sudo make dkms
------ snip----
'make' DKMS_KERNEL_VERSION=5.14.0-289.el9.x86_64...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.14.0-289.el9.x86_64 (x86_64)
Consult /var/lib/dkms/iomemory-vsl/5.14.0-b7bb5f0/build/make.log for more information.
make[1]: *** [Makefile:121: dkms] Error 10
make[1]: Leaving directory '/home/k3s/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16'
make: *** [Makefile:10: dkms] Error 2
Logfile states: error: stdarg.h: No such file or directory
Possible solution
Seems to be related to the new stdarg.h location.
fio/port/vararg.h has an if/else statement with specifically kernel 5.16.0, but in CentOS Stream 9 it is apparently needed for 5.14.0 as well.
[root@..~]# find / -name stdarg.h
/usr/lib/gcc/x86_64-redhat-linux/11/include/stdarg.h
/usr/src/kernels/5.14.0-289.el9.x86_64/include/linux/stdarg.h
Updating the if statement to also catch 5.14.0 has solved it for my use case, but it might not be a good generic catch.
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,14,0)
#include <linux/stdarg.h>
Environment information
Information about the system the module is used on
- Linux kernel compiled against (uname -a)
5.14.0-289.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Mar 19 07:28:57 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux - The C compiler version used (gcc --version)
gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4) - distribution, and version (cat /etc/os-release)
VERSION="9"```
4. Tag or Branch of iomemory-vsl that is being compiled
`main`
5. FIO device used, if applicable
not applicable
Red Hat: breaking things by backporting since forever. Thank you for the bug report. @snuf is the primary code contributor and this will get fixed at some point. Glad you were able to work around it.
Seems like the fix was already in vsl4, back porting it and testing.
fixed, merged to main.