undefined symbol: dsyevr_

[blegat]

I am using Julia v0.5-rc2 and the latest version of SCS.jl on Ubuntu 16.04 64 bits.
When I add SCS.jl, build it (it installs scs v1.1.8) and run julia runtests.jl I get

julia: symbol lookup error: /home/blegat/.julia/v0.5/SCS/deps/usr/lib/libscsdir.so: undefined symbol: dsyevr_

[blegat]

I think this is because it is searching for the LAPACK library of julia but it does not find it since I just unpacked Julia v0.5-rc2 and it doesn't know that the library is in the unpacked folder.

[blegat]

• I have compiled the branch release-0.5 of julia from source: same issue
• With the version Version 0.4.6 (2016-06-19 17:16 UTC) of staticfloat's juliareleases ppa, I do not have this error
• Version 0.5.0-dev+4154 (2016-05-18 11:17 UTC) Commit 778740e (95 days old master) of staticfloat's julianightlies ppa, I do not have this error

This may be because staticfloat's build uses a separate package for lapack which the other build downloads blas and lapack from source and compile it in the julia build.

[mlubin]

It's strange that travis is passing then since it uses the 0.5-rc tarballs. I also can't reproduce locally on ubuntu 16.04 and a manual build of release-0.5. You'll have to dig a bit deeper into which lapack symbols are available in your julia install and why SCS isn't matching up.

[bodono]

Yes, it could be that your version of Lapack is using a different suffix (i.e. not ending with the '_'). SCS can be compiled with another suffix via a flag, you just need to figure out what that suffix is.

[blegat]

Indeed, it seems to be a problem with the suffix:

$ nm /usr/lib/julia/libopenblas64_.so | grep dsyevr
00000000019d4ee0 T dsyevr_64_
0000000001e3cb50 T LAPACKE_dsyevr64_
0000000001e3ceb0 T LAPACKE_dsyevr_work64_

Should we add an automatic procedure in SCS/deps/build.jl to check the suffix and add it in the SCS compilation ?

[mlubin]

@blegat, we already handle this in principle: https://github.com/JuliaOpt/SCS.jl/blob/master/deps/build.jl#L53
What is your blasvendor set to?

[blegat]

Ok I have found my mistake ^^
SCS was compiled with the julia version of staticfloat's julianightlies with was using openblas then when I tried Julia v0.5-rc2 it didn't work since it was using openblas64.
I thought I triggered a rebuild but it seems that I just did Pkg.rm("SCS"); Pkg.add("SCS") but Pkg.rm does not remove the directory so it does not rebuild it (I should have given it a closer look).

Thanks for your help @mlubin and @bodono ;)

If someone gets the same error and arrive here by googling, the solution is easy:

$ cd SCS/deps/
$ rm -r deps.jl src usr downloads
$ Pkg.build("SCS")

[mlubin]

@blegat, you should give JuliaLang/julia#7054 a bump, I reported this issue more than two years ago

[bodono]

Thanks for the update, and glad you worked it out!

[kalmarek]

Well I've run into this problem when trying to use julia build against mkl:

Base.BLAS.vendor()
:mkl
Base.BLAS.libblas
"libmkl_rt"

however it seems that this is not a suffix issue:

nm /opt/intel/compilers_and_libraries_2017.1.132/linux/mkl/lib/intel64_lin/libmkl_rt.so|grep dsyevr
00000000001d0500 T LAPACKE_dsyevr
00000000001d0720 T LAPACKE_dsyevr_work
0000000000172cb0 T dsyevr
0000000000172cb0 T dsyevr_
00000000001d0500 T lapacke_dsyevr
00000000001d0500 T lapacke_dsyevr_
00000000001d0720 T lapacke_dsyevr_work
00000000001d0720 T lapacke_dsyevr_work_

I removed SCS as package and as folder but it didn't help...

[mlubin]

The SCS build script has never been tested with julia+MKL. There's little chance it works out of the box. We'll accept PRs.

[kalmarek]

the build and link work with

if blasvendor == :mkl
    cflags = "$cflags -DMKL_ILP64 -m64"
    ldflags = "-lmkl_intel_ilp64 -lmkl_gnu_thread -lmkl_rt -lmkl_core -lgomp -lpthread"
end

however, one of the tests (the first which actually uses BLAS) feasible_sdp_conic() fails with

Intel MKL ERROR: Parameter 4 was incorrect on entry to DSYEVR.
FATAL: syevr failure, info = -4
ERROR: initCone failure
Setup time: 1.50e-04s
ERROR: SCS_NULL input

which says that the fourth argument has an illegal value according to this. I tried to dive into SCS.jl code, but couldn't trace that call to Blas...

[bodono]

That could be something to do with the type of integer MKL is expecting and what is being built. From your flags it seems that MKL is expecting 64 bit integers, but SCS might be building using 32 bit. You can compile SCS with 64 bit blas integers by adding the flag -DBLAS64 to cflags, as done here https://github.com/JuliaOpt/SCS.jl/blob/master/deps/build.jl#L53.

[kalmarek]

yep, that was stupid me ;-)
all tests pass, with two warnings (for infeasible and unbounded problems):

WARNING: Problem is infeasible, but infeasibility ray ("Farkas proof") is unavailable; check that the proper solver options are set.
WARNING: Problem is unbounded, but unbounded ray is unavailable; check that the proper solver options are set.

Now I have no idea how to check if mkl uses 64 or 32 bits integer from within julia. Any ideas?

[mlubin]

I think it's safe to ignore those warnings.