Closed ric-cioffi closed 8 months ago
libgomp.so is the gnu openmp library which comes with gcc. Did you install gcc on your system ?
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.
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).
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
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
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..
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?
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?
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?
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 Pardiso@0.4.2
but apparently I cannot specify a version when calling develop
.
Otherwise I guess I will have to try to update everything to 1.6
Did you try to use LD_LIBRARY_PATH or LD_PRELOAD ? This should cirumvent the need for a symlink.
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
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
I am not sure that will work since we are trying to open the library via an absolute path. Did you try it?
Just tried, neither of the two worked
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.
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. Thenusing Pardiso
already gives me:but the package seems to load just fine. In fact
Pardiso.show_build_log()
tells meHowever, when I try running
ps = MKLPardisoSolver()
I get: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