cfallin edited issue #1164:
What I'd like to see is a way to use Cranelift apis from another (non rust) language. Currently the cranelift apis are rust only, but having a layer on top of that like "llvm-c" is, would make the cranelift api usable from all languages, and thus a much wider range of compilers could use it as a backend.
rishavs commented on issue #1164:
Is this likely to happen? I'd really like to try out cranelift for my toy language, but the lack of a simple c api will mean that I will have to stick with llvm instead.
cfallin commented on issue #1164:
I personally think it would be nice to have this, but it's not a small task to build, and no one currently has the time to do it. If you (or anyone) would like to contribute this, we'd be happy to talk further -- the first step would probably be gathering feedback in an RFC.
rishavs commented on issue #1164:
This is way out of my league so likely a stupid question; but if I build a so/dll of all the cranelift crates like
cranelift = "0.89.0"
using cargo, can I use this .so file in other languages which support FFI?
bjorn3 commented on issue #1164:
No, rust's ABI is not stable, so you can't call any of the methods in this dylib. You have to write a C interface for every function you want to call from non-rust code and then use this C interface.
cfallin commented on issue #1164:
This is way out of my league so likely a stupid question; but if I build a so/dll of all the cranelift crates like cranelift = "0.89.0" using cargo, can I use this .so file in other languages which support FFI?
To add a little more nuance: (i) Rust does have the ability to produce
.so
s that can be called with a C ABI; but (ii) that requires explicit work, in defining the C-ABI-compatible exports (#[no_mangle]
andextern "C" fn
are the relevant search terms, as well as care about data structure layout and use of#[repr(C)]
on structs where needed).
tgross35 commented on issue #1164:
Is there a place for a C API in-tree, or is that solidly out of scope?
@coffeebe4code did some reworking of @carlokok's gist, https://github.com/coffeebe4code/craneliftc. If the methodology looks correct enough, that could likely be a reasonable starting point.
tgross35 edited a comment on issue #1164:
Is there a place for a C API in-tree, or is that solidly out of scope for the time being?
@coffeebe4code did some reworking of @carlokok's gist, https://github.com/coffeebe4code/craneliftc. If the methodology looks correct enough, that could likely be a reasonable starting point.
Last updated: Dec 23 2024 at 12:05 UTC