-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MKL upgrade breaks support library #357
Comments
This is caused by the MKL upgrade on Conda. Maybe you're in a better position to figure out what's up here? |
@maleadt : This issue is due to failed to find libOpenCL package within conda packages for local builds
Ideally it should be looking for it here, /home/kali/.julia/scratchspaces/8f75cd03-7ff8-4ecb-9b8f-daf728133b1b/conda/lib/ By default libpi_opencl.so points to system path and search path must be set correctly. Please take a look.
|
@maleadt : how can we get the search path to into conda package under julia scratcspaces directory like before? what caused this behavioral change ? |
The change is with the binaries from Conda, I didn't change over here. Presumably the OpenCL dependency didn't exist before, or at least it didn't trigger with the functionality we're executing here. The solution is probably to copy the OpenCL library into the scratch space. We already do this for the JLLs we build on Yggdrasil. |
@maleadt We find that OpenCL library is already in the scratch space in Conda distribution but during execution of oneAPI.jl it is loaded from local system install. We need it to dynamically load from scratch space instead. how can we do this? |
I'd try to copy it to the location of the support library instead, like we do on Yggdrasil: https://github.com/JuliaPackaging/Yggdrasil/blob/9cfb94ebb0f33b9128f49aea81d9bc6cb9a0d9fc/O/oneAPI_Support/build_tarballs.jl#L75-L85 |
@maleadt we need to provide opencl library as part of oneapi.jl artifactory and it must be initialized as part of instantiate process like other libraries. when libpi_opencl is called for opencl initiation as part of build_local() it must pick the libopencl downloaded from artifactory. |
The generated library has a correct RPATH, so I don't see why it shouldn't be able to find libOpencl:
This looks like a design flaw with the plugin infrastructure. We cannot change the system-wide dynamic library search path, nor can we set LD_LIBRARY_PATH. I guess we could pre-load libOpencl.so though. |
How about the libpi_opencl.so in your case ? Reference to my comment above, it points to local directory. #357 (comment) |
In fact, our RPATH works just fine, as the process does open libOpenCL from the conda libdir:
So switching to OpenCL_jll doesn't help, as expected:
The fact that |
|
@maleadt : Thank you for the analysis and explanation. We will formulate a bug report to the libpi_opencl.so library to debug and fix this problem. |
Can we use temporary the trick suggested by @kballeda with |
Although we can do this for CI, we can't do this with JLLs. Previously, the bug that updating MKL surfaced didn't trigger with JLLs because we're using an older MKL in Yggdrasil, but in this PR you're also running into the OpenCL issue with the downgraded MKL, so I think we would also run into this with our JLLs (and again, we can't use the LD_LIBRARY_PATH hack there). |
Ok, I see. We can only wait a fix upstream by Intel. |
#386 |
You mean it's broken in other ways, or not released yet? |
They released it but conda packages for 2024.0.2 miss some of the llvm components. |
I had encountered following error when I run the onemkl.jl tests. This error goes away if I set oneAPI locally.
Intel MKL FATAL ERROR: Error on loading function 'clGetPlatformIDs'
This starts occurring since 2023.2 / Julia 1.9.3 onwards.
This has been observed as part of CI tests for open PRs,
https://buildkite.com/julialang/oneapi-dot-jl/builds/773
The text was updated successfully, but these errors were encountered: