PoCL: pocl_jll links kernels against a build-time SLEEF path
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cmake, julia
- Domain
- backend, build-system
Research direction
Start by reading the Yggdrasil PoCL recipe at P/pocl/common.jl and the referenced PoCL CMakeLists.txt linker configuration; compare those flags with the runtime SONAME loading in pocl_llvm_orc.cc. Reproduce the prg.binaries query on x86_64 Linux and inspect the ahead-of-time link step. Done means the query no longer tries to open the build-time SLEEF path while generated binaries continue to work.
Written by the indexing model from the issue text.
Description
On x86_64 Linux, pocl_jll tries to link ahead-of-time compiled kernels against SLEEF at the path it had inside the BinaryBuilder sandbox. This happens when querying the binaries of a program:
using OpenCL, pocl_jll
src = "__kernel void foo(__global float *a) { a[get_global_id(0)] = sin((float)get_global_id(0)); }"
prg = cl.Program(source=src) |> cl.build!
bin = prg.binaries
ld.lld: error: cannot open /workspace/destdir/lib/libsleefgnuabi.so: No such file or directory
error: no such file or directory: '/workspace/destdir/lib/libsleefgnuabi.so'
ld.lld: error: cannot open /workspace/destdir/lib/libsleefgnuabi.so: No such file or directory
error: no such file or directory: '/workspace/destdir/lib/libsleefgnuabi.so'
The query still succeeds, and a program created from these binaries runs correctly, so presumably the binaries lack the native kernel code and get recompiled when loaded.
The Yggdrasil recipe points PoCL at ${prefix}/lib/libsleefgnuabi.so for vectorized math (-DLIBMVEC). The JIT was taught to load that library by its SONAME at run time (pocl_llvm_orc.cc), but PoCL also adds the absolute path to the linker flags used for ahead-of-time kernels (CMakeLists.txt, and the same for LIBSLEEF, used on aarch64). That path doesn't exist once the JLL is installed. The link step should find the library the same way the JIT does, e.g. by resolving the SONAME at run time, or link against the copy in the SLEEF_jll artifact.
pocl_jll 7.2.2+0, OpenCL.jl main, Julia 1.13.1, Linux x86_64.
- Dominant language
- Julia
- Stars
- 313
- Forks
- 50
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 41
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from JuliaGPU/OpenCL.jl
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
kernels latency regression
Difficulty 4/5 3-5 days Newbie friendliness 52/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
All issues in JuliaGPU/OpenCL.jl
Similar issues
-
io
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
docs
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
JuliaGPU/GPUArrays.jl#837 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day