From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

Hi,

I am attempting to install NI488.2-17.0.0 on a RHEL7.5 machine with the 3.10.0-862.3.2.el7.x86_64 kernel.  Makefile for nikal fails.  I included NULL in do_munmap() in nikal.c as indicated in other threads on this site, to eliminate that error.  National Instruments explicitly declares support for RHEL...so what is this all about?  I have also tried NI488.2 15.1.1 with NIKAL 15.1.  No dice there either.  Am I missing something?  Any help would be greatly appreciated.

Thanks

 

Make Output:

 

 

[lab1@s1012047 nikal]$ sudo make
  CC [M]  /var/lib/nikal/3.10.0-862.3.2.el7.x86_64/nikal/nikal.o
/var/lib/nikal/3.10.0-862.3.2.el7.x86_64/nikal/nikal.c:2023:10: error: ‘GENL_ID_GENERATE’ undeclared here (not in a function)
    .id = GENL_ID_GENERATE,
          ^
/var/lib/nikal/3.10.0-862.3.2.el7.x86_64/nikal/nikal.c: In function ‘nNIKAL100_initDriver’:
/var/lib/nikal/3.10.0-862.3.2.el7.x86_64/nikal/nikal.c:2063:4: error: implicit declaration of function ‘genl_register_family_with_ops’ [-Werror=implicit-function-declaration]
    if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;
    ^
cc1: some warnings being treated as errors
make[2]: *** [/var/lib/nikal/3.10.0-862.3.2.el7.x86_64/nikal/nikal.o] Error 1
make[1]: *** [_module_/var/lib/nikal/3.10.0-862.3.2.el7.x86_64/nikal] Error 2
make: *** [nikal.ko] Error 2

 

0 Kudos
Message 1 of 19
(9,060 Views)

vpinho13 Solved this here

 On top of including NULL in do_munmap() you need to also:

 

#define NLNIKAL_CMD_SEND     1
#define GENL_ID_GENERATE 0  // define value to genl_id_generate = 0

static struct genl_family nikal_netlink_family =
{
   .id = GENL_ID_GENERATE,
   .name = "nlnikal",
   .version = 1,
   .maxattr = 1

 

 

and then comment this

 

#ifdef nNIKAL1400_kHasFamilyGenlOpsGroups
   //if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops))) return status;
#else
   //if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;
#endif

 

 

 

0 Kudos
Message 2 of 19
(9,037 Views)

@justinblair wrote:

vpinho13 Solved this here

 On top of including NULL in do_munmap() you need to also:

 

#define NLNIKAL_CMD_SEND     1
#define GENL_ID_GENERATE 0  // define value to genl_id_generate = 0

static struct genl_family nikal_netlink_family =
{
   .id = GENL_ID_GENERATE,
   .name = "nlnikal",
   .version = 1,
   .maxattr = 1

 

 

and then comment this

 

#ifdef nNIKAL1400_kHasFamilyGenlOpsGroups
   //if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops))) return status;
#else
   //if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;
#endif 


Good luck with that: ttis will remove registering the netlink family, so the driver won't work.

 

Meanwhile, I'm tired of repeating myself ... already wrote about that several times.

Maybe I could be motivated by inserting some coins 😉

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 3 of 19
(9,033 Views)

@justinblair thank for the lead!  It finally compiled.  I must have missed that forum thread when scouring for a solution.  I owe you one.

@metux I agree this is a very hack-y solution and scares me...

0 Kudos
Message 4 of 19
(9,002 Views)
Solution
Accepted by tlooby

Ok I may have a way to fix these compilation errors without simply adding comments to the code.  I will preface by saying I am a scientist/engineer working on nuclear fusion, not a software developer.  I am posting this to throw my rock on this pile and contribute my findings, not as a permanent solution.  Clearly NI needs some serious overhaul with regards to Linux compatibility.

 

Because the implicit declaration error seemed to be a function call error, I searched through the genetlink.h header file, which was located here for me:  /usr/src/kernels/3.10.0-514.10.2.el7.x86_64/include/net/genetlink.h.  I could not find a function / method: genl_register_family_with_ops() in this header file, or in any of the header file that genetlink.h includes.  After a trip through the internet wormhole, I found this thread, which indicated that even though I was running the RHEL kernel 3.10, genl_register_family_with_ops() had possibly been deprecated early.  The deprecation is supposed to happen after 4.10, according to Linux Foundation Netlink Howto.

 

All that being said, this is what I did, and I am communicating with ENET devices using GPIBEXPLORER.

  1. Include: NULL in do_munmap(), as indicated in other threads on this site
  2. Add: GENL_ID_GENERATE 0 as another poster in this thread indicated
  3. Switch order of (including code inside brackets):
    1. static struct genl_ops{}
    2. static struct genl_family{}
  4. Include two references to genl_ops structure as elements in the genl_family structure:
    1.   .ops = nikal_netlink_ops,
    2.   .n_ops = 1
  5. Change the #ifdef nNIKAL1400_kHasFamilyGenlOpsGroups conditional (and else statement) to:
    1. if ((status = genl_register_family(&nikal_netlink_family))) return status;

I have included the entire snippet of this code below.  I am sure I missed something here, so if anyone sees anything really bad please let me know.  I think there is probably a better way to handle the conditional.  In my code below it serves no real purpose.

 

EDIT (20180716): Using NI-KAL 17.5 solves this issue.  All the errors / modifications mentioned above are included in this version of nikal.c.  See other accepted solution below.  I will keep both marked as solution because here I give a description of the problem with the source.

 

#define NLNIKAL_CMD_SEND     1

/**********************************************************************/
// Begin Mod

/* Modified 20180618 by TL
 * genl_register_family_with_ops() is (apparently) no longer existent
 * for this kernel version in RHEL.  Instead, we reference netlink_ops from
 * netlink_family using two elements, .ops and .n_ops, and then replace
 * the genl_register_family_with_ops() call with genl_register_family().
 *
 * Obviously, this is hacky, but until NI codes distro checking into
 * their modules this will have to do.  I am not sure about all the
 * effects of this, but I am sure there are some inadvertent byproducts
 * of doing this that I am unaware of.  So far, I have communicated with
 * E100s over multiple subnets using driver compiled with this code.
 *
 * Linux Foundation Netlink Webpage:
 * https://wiki.linuxfoundation.org/networking/generic_netlink_howto#registering-a-family
 *
 * NI Discussion forum thread I made for this topic:
 * https://forums.ni.com/t5/Linux-Users/failed-to-build-nikal-error-on-RHEL7-3-10-0-862-3-2-el7-x86-64/gpm-p/3805915


*/
// Added 20180618 by TL
#define GENL_ID_GENERATE 0  // define value to genl_id_generate = 0

static int nlnikal_msg(struct sk_buff *skb, struct genl_info *info) { return 0; }


// Modified 20180618 by TL
// The order of genl_ops and genl_family used to be reversed.
static struct genl_ops nikal_netlink_ops[] =
{
   {
      .cmd = NLNIKAL_CMD_SEND,
      .doit = nlnikal_msg
   },
};

static struct genl_family nikal_netlink_family =
{
   .id = GENL_ID_GENERATE,
   .name = "nlnikal",
   .version = 1,
   .maxattr = 1,
   // Added 20180617 by TL
   // For newer kernel versions, we must reference netlink_ops
   .ops = nikal_netlink_ops,
   .n_ops = 1
};

static int __init nNIKAL100_initDriver(void)
{
   int status = 0;
   
   
   nNIKAL120_sStackSize = nNIKAL120_mRoundUp(((nNIKAL100_tUPtr)(&status) -
         (nNIKAL100_tUPtr)(current_thread_info())), PAGE_SIZE) -
         sizeof(struct thread_info);
   KAL_DPRINT("Kernel stack size: %lu\n", nNIKAL120_sStackSize);
   
   nNIKAL230_Mutex_init(&(nNIKAL240_procfsLock));
   sema_init(&(nNIKAL100_sMMapSema), 1);
   sema_init(&(nNIKAL100_sPageLockOperationSema), 1);
   nNIKAL100_mapInit(&nNIKAL100_sPageLockMap);
   nNIKAL100_mapInit(&nNIKAL100_sMallocContiguousMap);
   sema_init(&(nNIKAL100_sMallocContiguousMapLock), 1);
   kref_init(&(nNIKAL200_sPALPseudoDevice.kref));
   kref_init(&(nNIKAL200_sPALPseudoDeviceInterface.kref));

#ifdef nNIKAL1400_kHasFamilyGenlOpsGroups
    //Modified 20180618 by TL
    //Original Line of code from NI:
    // if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops))) return status;
    
    // Tom's line:   
    if ((status = genl_register_family(&nikal_netlink_family))) return status;
#else
    //Original Line from NI:
    // if ((status = genl_register_family_with_ops(&nikal_netlink_family, nikal_netlink_ops, 1))) return status;

    //Tom's Line:
    if ((status = genl_register_family(&nikal_netlink_family))) return status;
#endif

   nNIKAL200_sProcRootDir = proc_mkdir("driver/ni", NULL);

   if (!nNIKAL200_sProcRootDir)
      return -ENOMEM;

   return status;
}

// End Mod
/**********************************************************************/


static void __exit nNIKAL100_cleanupDriver(void)

 

 

 

0 Kudos
Message 5 of 19
(8,947 Views)

Hello guys

 

 

Sorry about delay I'm on **bleep** China and internet make crazy...So **bleep** slow.

 

 

Ok about Visa....any chance that you guys use Centos 7.4?

 

I have a scrip that works fine into Centos.....If is possible please let know.

 

 

 

 
0 Kudos
Message 6 of 19
(8,919 Views)

Please intall gnome version

 
0 Kudos
Message 7 of 19
(8,917 Views)

@vpinho13 I am using Red Hat 7.5 (Maipo), not Centos, although my understanding is that Centos and RHEL are compatible (my background is in Debian/Ubuntu so I am not that knowledgeable about Fedora based distros). Also, I am using gnome-classic.

 

What was your question, specifically?

0 Kudos
Message 8 of 19
(8,906 Views)
Solution
Accepted by tlooby

Hi tlooby,

 

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.

Tom D.
Staff Software Engineer
NI
0 Kudos
Message 9 of 19
(8,816 Views)

@TommyDunkz

Tom D.,

 

That's good that the do_munmap() error has been reported, but that was not my issue here.  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.  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).  Just my two cents.

 

Thanks for the response,

-Tom L.

0 Kudos
Message 10 of 19
(8,807 Views)