Call library function node error 13 on RT-Linux Targets

[tusrob]

I have successfully compiled GCC 4.9.4 with fortran support so that I can get ATLAS to compile on the RT-Linux target.

These are the steps that I took:

• compiled ATLAS -> result was lilsatlas.so and libtatlas.so
• symlinked libcblas.so to libtatlas.so

ln -s libtatlas.so libcblas.so
ln -s libtatlas.so libatlas.so

• cross-compiled a c-file with eclipse

• #include "cblas.h"
  
  float * blasfun(float *A, float *B){
  
  	static float C[4];  //result
  
  	int lda = 3;
  	int ldb = 2;
  	int ldc = 2;
  
  	  cblas_sgemm (CblasRowMajor,
  	               CblasNoTrans, CblasNoTrans, 2, 2, 3,
  	               1.0, A, lda, B, ldb, 0.0, C, ldc);
  
  	return C;
  
  }
  

  • copied it to /usr/local/lib
  • ran readelf --dynamic to see dependencies

  • admin@NI-cRIO-9039-01BE3F31:/usr/local/lib# readelf --dynamic libBLASTEST.so
    
    Dynamic section at offset 0x7f8 contains 20 entries:
      Tag        Type                         Name/Value
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000c (INIT)               0x518
     0x000000000000000d (FINI)               0x738
     0x000000006ffffef5 (GNU_HASH)           0x1b8
     0x0000000000000005 (STRTAB)             0x348
     0x0000000000000006 (SYMTAB)             0x1f8
     0x000000000000000a (STRSZ)              183 (bytes)
     0x000000000000000b (SYMENT)             24 (bytes)
     0x0000000000000003 (PLTGOT)             0x2009a0
     0x0000000000000002 (PLTRELSZ)           72 (bytes)
     0x0000000000000014 (PLTREL)             RELA
     0x0000000000000017 (JMPREL)             0x4d0
     0x0000000000000007 (RELA)               0x440
     0x0000000000000008 (RELASZ)             144 (bytes)
     0x0000000000000009 (RELAENT)            24 (bytes)
     0x000000006ffffffe (VERNEED)            0x420
     0x000000006fffffff (VERNEEDNUM)         1
     0x000000006ffffff0 (VERSYM)             0x400
     0x000000006ffffff9 (RELACOUNT)          1
     0x0000000000000000 (NULL)               0x0
    

  • a quick ldconfig shows that we indeed have the needed libc

  • admin@NI-cRIO-9039-01BE3F31:/usr/local/lib# ldconfig -p |grep libc.so.6
            libc.so.6 (libc6,x86-64, OS ABI: Linux 3.14.3) => /lib/libc.so.6
    

  • i looked at the function calls of the library

    admin@NI-cRIO-9039-01BE3F31:/usr/local/lib# nm -D libBLASTEST.so
    0000000000000684 T blasfun
    00000000002009d8 B __bss_start
                     U cblas_sgemm
                     w __cxa_finalize
    00000000002009d8 D _edata
    0000000000200a00 B _end
    0000000000000738 T _fini
                     w __gmon_start__
    0000000000000518 T _init
                     w _ITM_deregisterTMCloneTable
                     w _ITM_registerTMCloneTable
                     w _Jv_RegisterClasses
    

  • there I see that cblas_sgemm is Undefined...
  • so I go to /usr/local/atlas/lib and run

  • admin@NI-cRIO-9039-01BE3F31:/usr/local/atlas/lib# nm -D libtatlas.so | grep cblas_sgemm
    00000000000c9700 T cblas_sgemm

if I run the call library function node in LabVIEW I get error 13 stating the obvious...

LabVIEW:  Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.

have I missed something obvious while cross compiling?

I am attaching my eclipse project so you can take a look at my configuration

[BradM · Accepted solution]

A primary issue that I see is that the path that contains the ATLAS libraries that you compiled is not on the system library path list. You can either add the path (look at /etc/ld.so.conf and /etc/ld.so.conf.d/*) or place the resulting libraries in a path that's already being considered (e.g. /usr/local/lib post-2014 or /usr/lib for all releases). The way that LVRT tracks down libraries to use is pretty much no different than any other Linux or UNIX binary: it will use the dynamic linking cache to try to track down a library, so you need to get your ATLAS libraries into that cache.

A less critical question I have is the choice of naming the libraries. Why did you create two symlinks (libcblas.so and libatlas.so) to the same file (libtatlas.so)? What did you do with lilsatlas.so (or is it libsatlas.so)?

[tusrob]

---

@BradM wrote:

A primary issue that I see is that the path that contains the ATLAS libraries that you compiled is not on the system library path list. You can either add the path (look at /etc/ld.so.conf and /etc/ld.so.conf.d/*) or place the resulting libraries in a path that's already being considered (e.g. /usr/local/lib post-2014 or /usr/lib for all releases). The way that LVRT tracks down libraries to use is pretty much no different than any other Linux or UNIX binary: it will use the dynamic linking cache to try to track down a library, so you need to get your ATLAS libraries into that cache.

---

That was one of the issues, yes, thank you for the hint!

The second issue was that i did not explicitly link against the library in my build process in eclipse. This is now done and everything works as expected.

---

@BradM wrote:

A less critical question I have is the choice of naming the libraries. Why did you create two symlinks (libcblas.so and libatlas.so) to the same file (libtatlas.so)? What did you do with lilsatlas.so (or is it libsatlas.so)?

---

i meant libsatlas.so - it was a typo. The naming convention of the libs is not something that i chose, it's done so automatically by ATLAS. The symlinks I made are because we use a lot of generated c-code and the process links to libcblas rather than libtatlas/libsatlas and i wanted to keep the consistency there. the other symlink was because I wanted control over the type of threading. So I just have to link against libatlas and the symlink dictates which implementation is to be used. I suppose my thought is that it should make benchmarking easier. I haven't tried it out yet.

Anywho, thank you for the tips!