02-07-2018 04:20 PM
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
02-22-2018 06:42 PM
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.
02-23-2018 05:15 PM
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.
02-23-2018 05:18 PM
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?
03-04-2018 10:22 AM
@pkorsnickAt 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.