Runtime error with homebrew netlib-native_system-linux-x86_64-natives.jar on CentOS 7.0

[yangliuyu]

Hi,

I got a runtime error when running spark application.

/usr/java/jdk1.7.0_65/bin/java: symbol lookup error: /tmp/jniloader9104995036364593011netlib-native_system-linux-x86_64.so: undefined symbol: cblas_daxpy

Build steps

Same build steps work on CentOs 6.5, so maybe it caused by the library version.

gcc.x86_64 4.8.2-16.el7 @base
gcc-gfortran.x86_64 4.8.2-16.el7 @base
libgfortran.x86_64 4.8.2-16.el7 @base
blas.x86_64 3.4.2-4.el7 @base
lapack.x86_64 3.4.2-4.el7 @base
arpack.x86_64 3.1.3-2.el7 @epel

[fommil]

hmm, looks like you're missing the cblas layer on top of BLAS (which is a fortran API). most distros compile the C API into the blas library.

Check if you have a libcblas you can install (e.g. ATLAS' version)

Or compile your own CBLAS against your fortran BLAS. Sources included in this project.

Can you do an ldd against the system-linux lib?

Does the reference lib work ok?

[yangliuyu]

Thanks @fommil ,

ldd /tmp/jniloader9104995036364593011netlib-native_system-linux-x86_64.so
ldd: warning: you do not have execution permission for `/tmp/jniloader9104995036364593011netlib-native_system-linux-x86_64.so'
    linux-vdso.so.1 =>  (0x00007fffaf9fe000)
    libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007fc871320000)
    libblas.so.3 => /lib64/libblas.so.3 (0x00007fc8710c7000)
    liblapack.so.3 => /lib64/liblapack.so.3 (0x00007fc87085c000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fc87049b000)
    libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007fc87025f000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fc86ff5c000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc86fd46000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc8719d3000)

No missing so files hint here...

The atlas-3.10.1-7.el7.x86_64 (CentOS 7) do not contain libcblas.so.3 which atlas-3.8.4-2.el6.x86_64 (CentOS 6.5) does. After install old version of atlas and arpack, the problem fixed.
And now ldd result is:

ldd /tmp/jniloader9104995036364593011netlib-native_system-linux-x86_64.so
ldd: warning: you do not have execution permission for `/tmp/jniloader9104995036364593011netlib-native_system-linux-x86_64.so'
    linux-vdso.so.1 =>  (0x00007fffef36d000)
    libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007fa068595000)
    libblas.so.3 => /lib64/libblas.so.3 (0x00007fa06833c000)
    liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x00007fa067b1a000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fa067759000)
    libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007fa06751d000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fa06721a000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa067004000)
    libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007fa066de5000)
    libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x00007fa066bc4000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa068c48000)
    libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007fa066568000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa06634c000)

[gabeos]

I ran into this same issue -- in Fedora 21 atlas is packaged only with libsatlas.so (serial) and libtatlas.so (threaded)
Errant bug report describing change

There's an apparently ongoing discussion of how to handle this here

Anyway, now with fedora 21, you can't downgrade to atlas 3.8, so there's no easy way to get things working. I force installed an old rpm of 3.8 with 'rpm' rather than yum/dnf, but it's super hacky and might very well break things..

anyway, I'm just wondering if you have any other suggestions, is there a way to build netlib-java or otherwise directly specify with libraries to use? I tried making symlinks to the libsatlas.so library in the /lib64/atlas directory (same error).

[fommil]

yeah, unfortunately the only thing I can recommend is to tell Fedora to learn how to package these projects correctly.

You could try installing the debian/ubuntu equivalents.

You don't need to recompile netlib-java. You just need to link it to a library at runtime that implements libblas.so.3 and liblapack.so.3 through symlinks.

Try OpenBLAS or Intel's Math Kernel Library. They are faster anyway.

[kgrech]

Same issue for openSuse 13.2. Solved by removing repository version of atlas and installing the following rpm:
http://rpm.pbone.net/index.php3/stat/4/idpl/23733523/dir/opensuse/com/atlas-3.8.3-5.1.x86_64.rpm.html

[danielkza]

Sorry for reviving this old issue, but it seems as of today Fedora still does not ship CBLAS with ATLAS or OpenBLAS. There seems to be an implementation available from GSL in libgslcblas.so.0. My first try was to simply symlink it to libcblas.so.3, but it was not sufficient, as it seems the netlib JNI objects are not compiled with -lcblas.

The only solution that seemed to work was to run Java with LD_PRELOAD=libgslcblas.so.0 in it's environment, so that the CBLAS symbols are already loaded in the JVM when netlib-native is loaded. Unfortunately I don't see an easy way to construct a library that would work in both situations, as explicitly linking to CBLAS would break Debian-based distributions, which do not have it.

[fommil]

GSL is GPL. Make sure that your application is correctly licensed GPL if distributing them linked to GSL.

[danielkza]

I'm not distributing any binaries with the LD_PRELOAD workaround applied, I only used it privately. I thought it might be useful to anyone ending up in this thread from Google.

edit: contrary to my previous statement, preloading libopenblas.so.0 actually seems to work, and does not bring up any licensing concerns.