undefined symbols in .so file #138
Comments
ArbitRandomUser
changed the title
|
Any of those instructions look familiar to you @chriselrod? |
|
LV will generate |
|
I just tried it and got julia> ptr = Libdl.dlopen("./mult2.so", Libdl.RTLD_NOW)#error
ERROR: could not load library "./mult2.so"
./mult2.so: undefined symbol: llvm.x86.bmi.bzhi.32which I didn't see listed as So I've seen issues like this before from PackageCompiler. Does |
|
While it might be possible to change, Ah, interesting.. |
Targeting the host should be fine, as that's what LV assumes. |
just tried on a cpu with avx512 and i get the same error, infact the |
|
Minimal example: julia> using StaticCompiler, VectorizationBase, Libdl
julia> function test(n::Int64)::Float64
VectorizationBase.assume(n>0)
1/n
end
test (generic function with 1 method)
julia> function test2(n::Int64)::Float64
VectorizationBase.assume(n>0)
2/n
end
test2 (generic function with 1 method)
julia> compile_shlib([(test,(Int64,)),(test2,(Int64,))],filename="inv2",demangle=true)
"/home/chriselrod/Documents/progwork/cxx/LoopModels/inv2.so"
julia> ptr = Libdl.dlopen("./inv2.so", Libdl.RTLD_NOW)#error
ERROR: could not load library "./inv2.so"
./inv2.so: undefined symbol: llvm.assume
Stacktrace:
[1] dlopen(s::String, flags::UInt32; throw_error::Bool)
@ Base.Libc.Libdl ./libdl.jl:117
[2] dlopen(s::String, flags::UInt32)
@ Base.Libc.Libdl ./libdl.jl:116
[3] top-level scope
@ REPL[10]:1 |
|
Any idea why this seems to cause a problem here but not in the normal Julia compilation pathway? Maybe we need to add some cleaning passes or something?
|
|
No, but @pchintalapudi might. |
|
Building with LLVM assertions, I get a different error: This indicates we're generating a malformed intrinsic, and indeed stepping through gdb we find a As for why LLVM claims it wants to replace that with a different intrinsic type, I'm not entirely sure. |
|
Turns out it's not trying to replace with a different intrinsic type, it's that someone's trying to link two modules with different contexts together. Most likely this is an issue in StaticCompiler, where it doesn't ensure that the linked modules are in the same context? |
|
yes looks like StaticCompiler.jl/src/StaticCompiler.jl Line 602 in f552ce0 I could get it to work by making a context and then doing whatevr i was able to get it working with this |
|
Go ahead on the PR. At first glance, that fix looks reasonable to me. |
|
i seem to be getting into errors with demangling in the tests I'm a little new to using GPUCompiler , i'll look around , meanwhile if its apparent to you why ,let me know |
|
managed to fix that issue , tests are passing as well |
mwe...
the former compilation , generating seperate
.ofiles for both functions and compiling them to shared library with clang works.the later way of compiling both functions into a single
.sofrom within julia includes undefined symbols in the.sothis is specific when both functions use the
@turbomacro fromLoopVectorization.if either of them do not , the generated
.soworks fineproject :
The text was updated successfully, but these errors were encountered: