NI488.2 15.1.1 fails to install on Centos 7.3 (1611)

[rpoffen]

I am trying to upgrade my machines to the latest Centos 1611 (based on RH 7.3). I previously had the NI488.2 driver 15.1.1f0 installed (which is the latest) on Centos 1511 (RH 7.2). However on the new Centos, the nikal kernel module will not compile, I get this..

nikal: CC [M] /var/lib/nikal/3.10.0-514.el7.x86_64/nikal/nikal.o
nikal: Building modules, stage 2.
nikal: MODPOST 1 modules
nikal: FATAL: modpost: GPL-incompatible module nikal.ko uses GPL-only symbol '__cachemode2pte_tbl'
nikal: make[2]: *** [__modpost] Error 1
nikal: make[1]: *** [modules] Error 2
nikal: make: *** [nikal.ko] Error 2
nikal: ERROR: failed to build nikal
nikal: ERROR: NI-KAL update failed.
nikal: ERROR: make of nikal kernel module failed, not installing kernel module.
nikal: ERROR: updateNIDrivers should be called again after fixing the problem.
nikal: ERROR: Logging failure...
niSystemReport Not found in current path
nikal: ERROR: Some required tools are missing or were not found.
nikal: ERROR: Update of National Instruments drivers failed.

Does anyone know of a solution?

Thanks

[metux]

---

@rpoffen wrote:

I am trying to upgrade my machines to the latest Centos 1611 (based on RH 7.3). I previously had the NI488.2 driver 15.1.1f0 installed (which is the latest) on Centos 1511 (RH 7.2). However on the new Centos, the nikal kernel module will not compile, I get this..

nikal: CC [M] /var/lib/nikal/3.10.0-514.el7.x86_64/nikal/nikal.o
nikal: Building modules, stage 2.
nikal: MODPOST 1 modules
nikal: FATAL: modpost: GPL-incompatible module nikal.ko uses GPL-only symbol '__cachemode2pte_tbl'
nikal: make[2]: *** [__modpost] Error 1
nikal: make[1]: *** [modules] Error 2
nikal: make: *** [nikal.ko] Error 2

Just same old problem, you'd have to expect with all proprietary driver (and also is the reason why usb devices aren't supported by NI): The proprietary module (which includes a precompiled binary blob) modules wants link against an symbol which is gpl-only. Due to the terms of the gpl, that would cause the driver to be a derivitve work of the kernel code, thus demanding it to be gpl. Running such a module would cause an license violation, which in turn would end up in license temination (IOW: you'd loose the right to run the kernel at all!). insmod is clever enough to prevent you from that illegal (and - in some countries - potentially criminal) action. The basic problem is that NI just refuses to play by the rules - abusing the GPL which is only tolerated by a few of the kernel developers. Expect more and more symbols to become gpl-only in future, and more and more proprietary drivers ulceterating out of existance. NI already had to bite the bitter apple and completely loosing the Linux market for their USB devices. Yet, the don't seem to have learned the lesson, so the ring gotta become louder.

[GatorChomp]

Hi all,

We've had a couple questions come in through formal channels related to this recently and managed to find what appears to be a workaround. It seems that the latest CentOS has an incompatibility with NI-KAL 15.0.1, which is included with NI-488.2 15.1.x.

I've tested this myself, and by installing NI-VISA 16.0 (which includes NI-KAL 15.1) I was then able to install NI-488.2 15.1.1 successfully. Please note that you must use version 15.1.1 and not 15.1.0 as documented by the following KnowledgeBase:
http://digital.ni.com/public.nsf/allkb/11CC761B2096A91286257F550069C289

NI-VISA 16.0: http://www.ni.com/download/ni-visa-16.0/6185/en/

We're looking into what needs to be done regarding documenting this behavior and cleaning up the workaround, but it would be helpful to know if this gets everything working for you!

[metux]

What was the actual root cause ?

[GatorChomp]

Hi metux,

I'm honestly not sure what the root cause is at this time. R&D is aware of the problem and is looking into it, but I don't have any other information myself. 

Your explanation may be along the right lines, but I don't have enough detailed knowledge to say either way. 

[metux]

---

@GatorChomp wrote:

Hi metux,

I'm honestly not sure what the root cause is at this time. R&D is aware of the problem and is looking into it, but I don't have any other information myself. 

Obviously, you called some internal arch specific function (that might have been changed to a inlnie or macro), that's not supposed to be called by drivers directly. This gives great doubts that you guys have any idea what you're actually doing.

By the way: at least you should have a proper CI that automatically builds/test all (still supported and upcoming) versions againt all supported distros, including newer kernels (incl. mainline).

So you would notice that problems quickly, w/o having your customers run straight into the open knife. Not having such a very basic QA practise is anything but profession.

--mtx