Closed codecnotsupported closed 6 months ago
IncompatibleSize Enum isn't very descriptive: "requested type cannot possibly work".
Fair enough.
However now it can't find the symbol. Which is odd since objdump can find it.
If you're on linux, you can run with the LD_DEBUG=all
environment variable set. It'll show you what the loader is doing. Testing locally I see indications that it is attempting to inspect the binary for symbols. Why it won't find anything is going to be up to yourself to figure out, but most likely reason is that ld.so
does not consider the binary DSO enough or the symbols sufficiently visible.
A relevant linker flag to look into may be --export-dynamic-symbol
Thanks, Adding
[build]
rustflags = ["-C", "link-args=-rdynamic"]
to .cargo/config
resolves the issue.
Relevant stackoverflow page: https://stackoverflow.com/questions/43712979/how-to-export-a-symbol-from-a-rust-executable
I'm trying to load a static symbol using libloading but it returns a IncompatibleSize error, yet I don't know why.
Results in
IncompatibleSize
Enum isn't very descriptive: "requested type cannot possibly work". Looking at the code that generates the error: https://github.com/nagisa/rust_libloading/blob/dc8664fd23a34b16e240c1bd48acbe3596cb8eef/src/os/unix/mod.rs#L214 Which is https://github.com/nagisa/rust_libloading/blob/dc8664fd23a34b16e240c1bd48acbe3596cb8eef/src/util.rs#L28-L34 It checks if the requested value is the size of a*mut raw::c_void
(A raw pointer)?So you're required to put in a pointer-like type in Library::get? Changing it to
&u32
seems to fix that issue. However now it can't find the symbol. Which is odd since objdump can find it.