Pardiso.jl icon indicating copy to clipboard operation
Pardiso.jl copied to clipboard

unable to create MKLPardisoSolver

Open ric-cioffi opened this issue 4 years ago • 16 comments

Hi, I have been trying to load Pardiso on a server (running julia 1.5.0), which already provides me with intel-mkl but I have been having issues creating the solver.

I fire up julia and immediately set ENV["MKLROOT"] to the right path. Then using Pardiso already gives me:

┌ Error: MKL Pardiso did not manage to load, error thrown was: could not load library "libgomp.so"
│ libgomp.so: cannot open shared object file: No such file or directory
└ @ Pardiso ~/.julia/packages/Pardiso/66TFF/src/Pardiso.jl:134

but the package seems to load just fine. In fact Pardiso.show_build_log() tells me

MKL Pardiso
=============
found MKLROOT environment variable, using it

However, when I try running ps = MKLPardisoSolver() I get:

ERROR: mkl library was not loaded, unable to create solver
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] MKLPardisoSolver() at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/mkl_pardiso.jl:17
 [3] top-level scope at REPL[4]:1

The problem seems related to #21 and #22 but I couldn't figure out a solution.

Note: I read in a different issue the latest version is somehow not compatible with julia < 1.6 so I have been working with Pardiso v0.4.2

ric-cioffi avatar Jul 24 '21 16:07 ric-cioffi

libgomp.so is the gnu openmp library which comes with gcc. Did you install gcc on your system ?

j-fu avatar Jul 25 '21 16:07 j-fu

Yes, gcc is also available (though I am not 100% sure julia knows where it is). Also, I might be wrong but I don't think libgomp is the problem because using Pardiso still works and the error I get when running MKLPardisoSolver() does not make any reference to libgomp.

ric-cioffi avatar Jul 25 '21 16:07 ric-cioffi

Yeah but it could be that " mkl library was not loaded" is a consequence of "could not load library libgomp". "using" the Julia package may seem ok even if loading of some library failed (this is an a priori assumption made without looking into the source).

You could try to force load libgomp using LD_PRELOAD or manage the LD_LIBRARY_PATH to help Julia to see the library. (see man ld.so).

j-fu avatar Jul 25 '21 17:07 j-fu

Can you try run:

julia> Pardiso.load_lib_fortran("libgomp", 8)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 9)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 10)
Ptr{Nothing} @0x0000000004370080

KristofferC avatar Jul 26 '21 07:07 KristofferC

Yeah but it could be that " mkl library was not loaded" is a consequence of "could not load library libgomp". "using" the Julia package may seem ok even if loading of some library failed (this is an a priori assumption made without looking into the source).

You could try to force load libgomp using LD_PRELOAD or manage the LD_LIBRARY_PATH to help Julia to see the library. (see man ld.so).

Fair point. I tried to understand how ld.so and ld-linux.so work bu couldn't figure out what I should be doing to let julia see libgomp.


Can you try run:

julia> Pardiso.load_lib_fortran("libgomp", 8)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 9)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 10)
Ptr{Nothing} @0x0000000004370080

In all three cases I get the following error:

ERROR: could not load library "libgomp.so"
libgomp.so: cannot open shared object file: No such file or directory
Stacktrace:
 [1] dlopen(::String, ::UInt32; throw_error::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Libdl/src/Libdl.jl:109
 [2] dlopen at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Libdl/src/Libdl.jl:109 [inlined]
 [3] load_lib_fortran(::String, ::Array{Int64,1}) at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/Pardiso.jl:78
 [4] load_lib_fortran(::String, ::Int64) at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/Pardiso.jl:70
 [5] top-level scope at REPL[2]:1

ric-cioffi avatar Jul 26 '21 09:07 ric-cioffi

Where is your gcc installed? Pardiso looks for it here: https://github.com/JuliaSparse/Pardiso.jl/blob/e0e08fcef1e4d8ff848b148cae31371360363037/src/Pardiso.jl#L76-L84.

It is very possible this detection could be improved..

KristofferC avatar Jul 26 '21 09:07 KristofferC

Also, just pointing out. Pardiso.jl should work fine if you don't give MKL_ROOT by using the bundled MKL. Is there a reason you want to provide your own MKL?

KristofferC avatar Jul 26 '21 09:07 KristofferC

Also, just pointing out. Pardiso.jl should work fine if you don't give MKL_ROOT by using the bundled MKL. Is there a reason you want to provide your own MKL?

When simply adding and using Pardiso without trying to provide it an MKLROOT I was getting:

ERROR: mkl library was not loaded, unable to create solver
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] MKLPardisoSolver() at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/mkl_pardiso.jl:17
 [3] top-level scope at REPL[12]:1

which is why I was trying to provide my own, already available, MKL.


Ah I guess the problem is that my gcc location is slightly different: /usr/lib/gcc/x86_64-redhat-linux/, how can I let Pardiso read from there?

ric-cioffi avatar Jul 26 '21 09:07 ric-cioffi

When simply adding and using Pardiso without trying to provide it an MKLROOT I was getting:

Maybe that was fixed in the most recent release (that only supports 1.6). Could you just try there to see how things work?

Ah I guess the problem is that my gcc location is slightly different: /usr/lib/gcc/x86_64-redhat-linux/, how can I let Pardiso read from there?

We would need to update Pardiso to handle that. Perhaps you can make a symlink in the meantime?

KristofferC avatar Jul 26 '21 10:07 KristofferC

Maybe that was fixed in the most recent release (that only supports 1.6). Could you just try there to see how things work?

Yes, adding and using Pardiso works fine in 1.6.

We would need to update Pardiso to handle that. Perhaps you can make a symlink in the meantime?

Unfortunately it looks like I don't have the permissions to create a symlink there. Is there any other way to change gcc_path locally? I tried to dev [email protected] but apparently I cannot specify a version when calling develop. Otherwise I guess I will have to try to update everything to 1.6

ric-cioffi avatar Jul 26 '21 10:07 ric-cioffi

Did you try to use LD_LIBRARY_PATH or LD_PRELOAD ? This should cirumvent the need for a symlink.

j-fu avatar Jul 26 '21 10:07 j-fu

Did you try to use LD_LIBRARY_PATH or LD_PRELOAD ? This should cirumvent the need for a symlink.

I'm not sure how I should do it. I tried reading the man ld.so page but couldn't figure out exactly what to do

ric-cioffi avatar Jul 26 '21 10:07 ric-cioffi

You use it in the same way as you have used MKL_ROOT.

You can do:

LD_LIBRARY_PATH=$(LD_LIBRARY_PATH):/usr/lib/gcc/x86_64-redhat-linux/ julia 

or

LD_PRELOAD=/usr/lib/gcc/x86_64-redhat-linux/libgomp.so julia

j-fu avatar Jul 26 '21 11:07 j-fu

I am not sure that will work since we are trying to open the library via an absolute path. Did you try it?

KristofferC avatar Jul 26 '21 12:07 KristofferC

Just tried, neither of the two worked

ric-cioffi avatar Jul 26 '21 12:07 ric-cioffi

I updated my packages to work with julia 1.6 so was able to load it directly with the bundled solver. Thank you both for your help.

I guess this issue can be closed now, unless you'd like to keep it open to reference the loading by absolute path.

ric-cioffi avatar Jul 29 '21 15:07 ric-cioffi