Since there are plenty of blogposts about what people would like to have or will implement in rust in 2019 here is mine.<\/p>\n
I spent the last few weeks of my spare time making a C-api for rav1e<\/a> called crav1e<\/a>, overall the experience had been a mixed bag and there is large space for improvement.<\/p>\n Ideally I’d like to have by the end of the year something along the lines of:<\/p>\n So that it would: All of this requiring a quite basic Building and installing properly shared libraries is quite hard, even more on multiple platforms.<\/p>\n Right now cargo<\/a> has quite limited install capabilities with some work<\/a> pending on extending it and has an open issue<\/a> and a patch<\/a>.<\/p>\n Distributions that, probably way too early since the rust<\/a> is a pretty good language and has a fairly simple way to interact in both direction with any other language that can produce or consume C-ABI-compatible object code.<\/p>\n This is already quite useful if you want to build a small static archive and link it in your larger application and\/or library.<\/p>\n An example of this use-case is librsvg<\/a>.<\/p>\n Such heterogeneous environment warrant for a modicum of additional machinery and complication.<\/p>\n But if your whole library is written in rust, it is a fairly annoying amount of boilerplate that you would rather avoid.<\/p>\n If you want to provide C-bindings to your crates you do not have a single perfect solution right now.<\/p>\n Currently building the library itself works fine and it is really straightforward:<\/p>\n Now issuing Once have a static library, you need an external mean to track what are its dependencies.<\/p>\n Back in the old ages there were My, fairly ugly, hack had been adding a dummy empty subcrate just to produce the link-line using<\/p>\n And then generate the This is anything but straightforward and because how Once you have your library, your header and your pkg-config file, you probably would like to install the library somehow and\/or make a package out of it.<\/p>\n For And with that at least a pure-rust static library can be built and installed with the common:<\/p>\n Given Sadly not. A dynamic library (or shared object) requires in most of the common platform some additional metadata to guide the runtime linker.<\/p>\n The current widespread practice is to use tools such as patchelf<\/a> or Since kind of metadata is platform-specific so would be better to have this information produced and passed on by something external to the main cargo. Having it as applet or a The applet could also take care of properly create the Some efforts could be also put on streamlining the process of extracting the library link line for the static data and spare some roundtrips.<\/p>\n I guess that’s all for what I’d really like to have next year in rust and I’m confident I’ll have time to deliver myself \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":" Since there are plenty of blogposts about what people would like to have or will implement in rust in 2019 here is mine. I spent the last few weeks of my spare time making a C-api for rav1e called crav1e, overall the experience had been a mixed bag and there is large space for improvement. … Continue reading Making and using C-compatible libraries in rust: present and future<\/span><\/a><\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[24],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1aGWH-bv","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/713"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/comments?post=713"}],"version-history":[{"count":5,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/713\/revisions"}],"predecessor-version":[{"id":718,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/713\/revisions\/718"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/media?parent=713"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/categories?post=713"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/tags?post=713"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}$ cargo install-library --prefix=\/usr --libdir=\/usr\/lib64 --destdir=\/staging\/place\n<\/code><\/pre>\n
\n– build a valid cdylib<\/code>+staticlib<\/code>
\n– produce a correct header
\n– produce a correct pkg-config file
\n– install all of it in the right paths<\/p>\nbuild.rs<\/code> and, probably, an applet.<\/p>\nWhat is it all about?<\/h2>\n
rust-ABI<\/code> is not stable nor being stabilized yet, are experimenting in building everything as shared library also have those problems.<\/p>\nWhy it is important<\/h2>\n
Current status<\/h2>\n
What works well already<\/h3>\n
\n
#[repr(C)]\npub struct Foo {\n a: Bar,\n ...\n}\n\n#[no_mangle]\npub unsafe extern \"C\" fn make_foo() -> *mut Foo {\n ...\n}\n<\/code><\/pre>\n\n
crate-types<\/code>, selecting staticlib<\/code> produces a valid library<\/li>\n<\/ul>\n[lib]\nname = \"rav1e\"\ncrate-type = [\"staticlib\"]\n<\/code><\/pre>\n\n
C-header<\/code> from a crate using few lines of build.rs<\/code> or a stand-alone applet and a toml<\/code> configuration file.<\/li>\n<\/ul>\nextern crate cbindgen;\n\nfn main() {\n let crate_dir = std::env::var(\"CARGO_MANIFEST_DIR\").unwrap();\n let header_path: std::path::PathBuf = [\"include\", \"rav1e.h\"].iter().collect();\n\n cbindgen::generate(crate_dir).unwrap().write_to_file(header_path);\n\n println!(\"cargo:rerun-if-changed=src\/lib.rs\");\n println!(\"cargo:rerun-if-changed=cbindgen.toml\");\n}\n<\/code><\/pre>\nheader = \"\/\/ SPDX-License-Identifier: MIT\"\nsys_includes = [\"stddef.h\"]\ninclude_guard = \"RAV1E_H\"\ntab_width = 4\nstyle = \"Type\"\nlanguage = \"C\"\n\n[parse]\nparse_deps = true\ninclude = ['rav1e']\nexpand = ['rav1e']\n\n[export]\nprefix = \"Ra\"\nitem_types = [\"enums\", \"structs\", \"unions\", \"typedefs\", \"opaque\", \"functions\"]\n\n[enum]\nrename_variants = \"ScreamingSnakeCase\"\nprefix_with_name = true\n<\/code><\/pre>\ncargo build --release<\/code> will get you a .h<\/code> in the include\/<\/code> dir and a .a<\/code> library in target\/release<\/code>, so far it is simple enough.<\/p>\nWhat sort of works<\/h3>\n
libtool archives<\/code> (.la), now we have pkg-config<\/code> files providing more information and in a format that is way easier to parse and use.<\/p>\nrustc<\/code> has --print native-static-libs<\/code> to produce the additional libraries to link, BUT<\/strong> prints it to stderr and only as a side-effect of the actual build process.<\/p>\ncargo rustc -- --print native-static-libs 2>&1| grep native-static-libs | cut -d ':' -f 3\n<\/code><\/pre>\n.pc<\/code> file from a template.<\/p>\ncargo rustc<\/code> works, you may end up adding an empty subcrate just to extract this information quickly.<\/p>\nWhat is missing<\/h3>\n
cargo install<\/code> does not currently cover it. It works only for binaries and just binaries alone. It will<\/a> hopefully change, but right now you just have to pick the external build system you are happy with and hack your way to integrate the steps mentioned above.<\/p>\ncrav1e<\/code> I ended up hacking a quite crude Makefile<\/a>.<\/p>\nmake DESTDIR=\/staging\/place prefix=\/usr libdir=\/usr\/lib64\n<\/code><\/pre>\nDynamic libraries<\/h3>\n
rustc<\/code> and cargo<\/code> have the cdylib<\/code> crate type, one would assume we could just add the type, modify our build-system contraption a little and go our merry way.<\/p>\ninstall_name_tool<\/code>, but it is quite brittle and might require tools.<\/p>\nMy plans for the 2019<\/h2>\n
rustc<\/code> has a mean to pass the information to the compile-time linker but there is no proper way to pass it in cargo<\/code>, I already tried to provide a solution<\/a>, but I’ll have to go through the rfc<\/em> route to make sure there is community consensus and the feature is properly documented.<\/p>\nbuild.rs<\/code> dependency makes easier to support more platforms little by little and have overrides without having to go through a main cargo update.<\/p>\n.pc<\/code> file and installing since it would have access to all the required information.<\/p>\n