Error compiling NI-KAL 17.0 with 4.14 kernel

[twester]

My problem is similar to the one described here: https://forums.ni.com/t5/Linux-Users/Errors-compiling-NI-KAL-2-5-with-3-19-0-25-kernel/gpm-p/3420171

When executing "updateNIDrivers", I get the error:

error: initialization from incompatible pointer type

...plus many additional c++ errors

The only difference between the previous post and now is that I am trying to install the NI-KAL 17.0 driver on a newer kernel (4.14) on a Redhat-based distribution (Fedora)

The initial installation worked without a problem, it is only an issue when doing "updateNIDrivers"

Is the only solution to downgrade to a less recent kernel?

Thanks

[pkorsnick]

We're seeing the same problem. It appears that the kernel's Generic Netlink communications interface has changed from the 3 series to the 4 series.

At minimum the GENL_ID_GENERATE define and genl_register_family_with_ops() function are missing from the 4.14 series kernel we're using

In the stock centos 3.10 kernel there exist the following that prevent the errors when building on 4.14

/usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/uapi/linux/genetlink.h:#define GENL_ID_GENERATE 0

/usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/net/genetlink.h:#define genl_register_family_with_ops_groups(family, ops, grps)

Perhaps someone from NI could reply and let us know if they plan to tweak their code to support the new netlink interface.

[DahlmanR]

Which overall driver are you trying to work with, and what version of that driver are you installing? 

NI-KAL is installed with many of our drivers, included NI VISA. 

[DahlmanR]

Which overall driver are you trying to work with, and what version of that driver are you installing? 

NI-KAL is installed with many of our drivers, including NI VISA and DAQmx. Are you on the most recent version of VISA/DAQmx/etc? 

[metux]

---

@pkorsnick

At minimum the GENL_ID_GENERATE define and genl_register_family_with_ops() function are missing from the 4.14 series kernel we're using

---

 

Yes, that had been removed long ago.

Note that kernel *internal* APIs are always changing. OOT modules always need a lot of maintenance works (this is just intended as temporary workaround until landing in mainline).

Can't be repeated often enough: proprietary drivers are just a *REALLY* bad idea.