'make' all KVER=4.18.0-193.28.1.el8_2.x86_64..........(bad exit status: 2)

[pam66]

got this error when compiling:

dkms install rtl8192eu/1.0

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
'make' all KVER=4.18.0-193.28.1.el8_2.x86_64...........(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.18.0-193.28.1.el8_2.x86_64 (x86_64)
Consult /var/lib/dkms/rtl8192eu/1.0/build/make.log for more information.

this is the make.log tail

var/lib/dkms/rtl8192eu/1.0/build/os_dep/linux/os_intfs.c:1407:22: error: initialization of ‘u16 (*)(struct net_device *, struct sk_buff *, struct net_device *, u16 (*)(struct net_device *, struct sk_buff *, struct net_device *))’ {aka ‘short unsigned int (*)(struct net_device *, struct sk_buff *, struct net_device *, short unsigned int (*)(struct net_device *, struct sk_buff *, struct net_device *))’} from incompatible pointer type ‘u16 (*)(struct net_device *, struct sk_buff *, void *, u16 (*)(struct net_device *, struct sk_buff *, struct net_device *))’ {aka ‘short unsigned int (*)(struct net_device *, struct sk_buff *, void *, short unsigned int (*)(struct net_device *, struct sk_buff *, struct net_device *))’} [-Werror=incompatible-pointer-types]
  .ndo_select_queue = rtw_select_queue,
                      ^~~~~~~~~~~~~~~~
/var/lib/dkms/rtl8192eu/1.0/build/os_dep/linux/os_intfs.c:1407:22: note: (near initialization for ‘rtw_netdev_ops.ndo_select_queue’)
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:313: /var/lib/dkms/rtl8192eu/1.0/build/os_dep/linux/os_intfs.o] Error 1
make[1]: *** [Makefile:1545: _module_/var/lib/dkms/rtl8192eu/1.0/build] Error 2
make[1]: Leaving directory '/usr/src/kernels/4.18.0-193.28.1.el8_2.x86_64'
make: *** [Makefile:1840: modules] Error 2

uname -a output:

Linux localhost.localdomain 4.18.0-193.28.1.el8_2.x86_64 #1 SMP Thu Oct 22 00:20:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I also tried with CONFIG_PLATFORM_ARM_AARCH64 = y but the error is the same

[pam66]

SOLVED by inserting the line EXTRA_CFLAGS += -Wno-error=incompatible-pointer-types in the Makefile @clnhub

[pam66]

I also had another issue concernig the number of arguments passed to the access_ok macro. Even if my kernel is 4.18 apparently this macro requires only 2 arguments instead of 3 of previous kernel versions, so I applied this patch:

index 9a54613..f53d372 100644
--- a/os_dep/linux/rtw_android.c
+++ b/os_dep/linux/rtw_android.c
@@ -624,7 +624,7 @@ int rtw_android_priv_cmd(struct net_device *net, struct ifreq *ifr, int cmd)
                goto exit;
        }

-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(5, 0, 0))
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(4, 18, 0))
        if (!access_ok(priv_cmd.buf, priv_cmd.total_len)) {
 #else
        if (!access_ok(VERIFY_READ, priv_cmd.buf, priv_cmd.total_len)) {

and now it compiles perfectly! @clnhub

[clnhub]

Thanks for looking into the driver code.

However, it seems that your 4.18 kernel has a specific _Remove 'type' argument from accessok() function back-port (CentOS?) that is not compatible with other (default) kernels <5.0.

Also, it is better to fix the pointer type issues than to just disable the error. There are many (pointer) changes between v4 and v5, so I would not recommend disabling the pointer error by default for driver code.

Is there no way to update the kernel to a (5+) version? That is probably less time consuming than to fix code for non-default old kernels with back-ported code.

[pam66]

Thanks for looking into the driver code.

However, it seems that your 4.18 kernel has a specific _Remove 'type' argument from accessok() function back-port (CentOS?) that is not compatible with other (default) kernels <5.0.

I see, yes it's a CentOS 8...

Also, it is better to fix the pointer type issues than to just disable the error. There are many (pointer) changes between v4 and v5, so I would not recommend disabling the pointer error by default for driver code.

Is there no way to update the kernel to a (5+) version? That is probably less time consuming than to fix code for non-default old kernels with back-ported code.

OK, agreed, I'll try to update the kernel. Thanks.