failed to build nikal error on RHEL7.5 (3.10.0-862.3.2.el7.x86_64)

[metux]

---

@TommyDunkz

Thanks for your post, and sorry to hear it has been so cumbersome to install NI-488.2 onto this system. NI has been made aware of the issues exposed by the bug regarding do_munmap(), and has developed a fix that went into NI-KAL 17.5.1. In the future, if stuck at that error you'll be able to resolve it by upgrading KAL from 17.0.0 to 17.5.1.

---

I'd suggest setting up an CI that automatically builds against all recent kernels (incl. master head).

Pretty trivial to do, perhaps a few hrs of initial work. This would catch those errors long before they happen in the field.

[metux]

The issue here is incompatibilities between the RHEL kernel (3.10) that NI claims they support, and the NIKAL driver NI wrote.  More specifically, it is obvious that no NI employee has formally tested the NIKAL module with RHEL7.5 because genl_register_family_with_ops() is deprecated in this version of redhat so the script nikal.c would never compile.  

Yes. At least an fully automatic build test via CI against recent kernels and distros is a must for any serious sw development. This really isn't hard to do - any decent operator can do that.

NI should either a) stop claiming support for RHEL, or b) fix the bugs.  I am a scientist, and for me to be fixing your software engineers' bugs is ridiculous (I won't ask them to do my plasma physics for me).

ACK. It really seems NI's users are far better sw engineers, than NI folks themselves.

Why does anybody buy that stuff ?

[GabeJ]

---

@tloobybecause genl_register_family_with_ops() is deprecated in this version of redhat so the script nikal.c would never compile.

NI-KAL 17.5.1 that Tom D. linked to solves that problem. I just installed and loaded it on a CentOS 7.5 system which had been yum upgrade-ed to kernel 3.10.0-862.3.3.el7.x86_64.

[tlooby]

@GabeJ thanks for that good news!  When I get to back to the lab I will try it out.

-Tom

[metux]

Note that 3.10 now 5 years old and not maintained anymore. Current stable is 4.17.

[GabeJ]

---

@metux wrote:

Note that 3.10 now 5 years old and not maintained anymore. Current stable is 4.17.

---

Yes, RHEL tends to choose a kernel version and sit on it.  (RHEL6 is on 2.6.32!!!)  Fortunately, openSUSE and other distros tend to stay much more current.

[metux]

Yes, RHEL tends to choose a kernel version and sit on it.  (RHEL6 is on 2.6.32!!!)  Fortunately, openSUSE and other distros tend to stay much more current.

One of the many reasons why I never could take them seriously, and never use their distro for any production system. Also, they always try to make GNU/Linux more and more like Windows, eg. the whole dbus and systemd bs. 

BTW: do they meanwhile have any actually usable dist-upgrade mechanism or do they still advice doing a completely fresh install ? 😮 (few years ago, I had to cope w/ a bunch of RHEL instances, and it was so bad, that a fresh install really was the better way) ... something that just works easily on Debian world for over 20 years now.

It really seems, RH is only for people, who really need to waste much $$$ for trivial things.

[EC_LTA]

Hello Tommy,

I get the same error when installing NI-DAQmx base 15.0 ( that need nivisa-15.0 ) on CentOS 7.8.

Is it safe to install and use NI-KAL 17.5.1 with older versions of NI-DAQmx base / nivisa ?

Best regards,

Lionel

[GabeJ]

---

@EC_LTA wrote:

I get the same error when installing NI-DAQmx base 15.0 ( that need nivisa-15.0 ) on CentOS 7.8.

Is it safe to install and use NI-KAL 17.5.1 with older versions of NI-DAQmx base / nivisa ?

---

Yes. NI-KAL 17.5.1 should work fine with earlier versions of NI software.

18.0 on Linux was a clean break.  NI Linux drivers from 18.0+ are not compatible with anything prior to 18.0, but they are much more modern and they are under active support, while NI-DAQmx Base reached its end of life last year.  NI-DAQmx Base hasn't been tested on recent Linux distributions.  While you can probably get it limping along, there won't be any official support.  I'd encourage you to move to the current NI driver stack wherever possible.