# Do you compile a dylib? **URL:** \ **Category:** Uncategorized\ **Created:** [April 5, 2016, 11:02pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342 "2016-04-05T23:02:05Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [April 5, 2016, 11:02pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/1 "2016-04-05T23:02:05Z")
Hello! Are you someone who compiles with `crate-type = ["dylib"]`, `#![crate_type = "dylib"]`, or `--crate-type dylib`? If so, I either have terrible or amazing news! [RFC 1510](https://github.com/rust-lang/rfcs/pull/1510) has just moved into its week-long final comment period. At its core this RFC proposes changing the definition of the `dylib` crate type to be more tailored towards the Rust-in-other-applications use case. This is unfortunately a breaking change, however, for anyone who uses `extern crate foo` where `foo` is compiled as a `dylib` as that crate would now have to be compiled as an `rdylib` (more details in the RFC itself). So in general, I’m curious to get a broader survey of: - Do you compile dynamic libraries in Rust not used for embedding Rust? - Do you ever specify a crate type `dylib` in `Cargo.toml`, source, or build scripts? It’s possible to implement RFC 1510 as _not_ a breaking change, it’d just be unfortunate to give up the name `dylib`! ---
**Author:** ![sfackler](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sfackler/32/9_2.png) [@sfackler](https://internals.rust-lang.org/u/sfackler)\ **Post date:** [April 5, 2016, 11:14pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/2 "2016-04-05T23:14:25Z")
I compile a crate as a dylib that talks through JNI to Java - acting just like a normal C dylib. It’s specified as a dylib in Cargo.toml. ---
**Author:** ![awe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/awe/32/3902_2.png) [@awe](https://internals.rust-lang.org/u/awe)\ **Post date:** [April 6, 2016, 1:10am UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/3 "2016-04-06T01:10:26Z")
I compile a number of crates as dylibs (specified in `Cargo.toml`) as part of a plugin system that has Rust code loading Rust dylibs at runtime. I also compile using `-C prefer-dynamic`. It used to work well, and allowed hot-loading of plugins. However, it now crashes when any of the dylibs are updated. ---
**Author:** ![urschrei](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/urschrei/32/1503_2.png) [@urschrei](https://internals.rust-lang.org/u/urschrei)\ **Post date:** [April 6, 2016, 8:24am UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/4 "2016-04-06T08:24:56Z")
I compile two crates both as `rlib` and `dylib` (specified in `Cargo.toml`), so they’re available both to other crates, and to external processes via FFI. ---
**Author:** ![emoon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/emoon/32/1333_2.png) [@emoon](https://internals.rust-lang.org/u/emoon)\ **Post date:** [April 6, 2016, 9:50am UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/5 "2016-04-06T09:50:04Z")
I’m using `dylib` as well for dynamic (re-loadable) plugins (main app is also in Rust) I’m very much in favor of this change as that is exactly what I want to have. ---
**Author:** ![Firstyear](https://avatars.discourse-cdn.com/v4/letter/f/a5b964/32.png) [@Firstyear](https://internals.rust-lang.org/u/Firstyear)\ **Post date:** [April 6, 2016, 10:08am UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/6 "2016-04-06T10:08:28Z")
I have a project that uses a standard rust crate, and it drawn in by another project to build a dylib (.so) that is loaded on the fly into another major C application. I’m in favour of this change, and it would NOT break my current application. ---
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [April 6, 2016, 5:11pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/8 "2016-04-06T17:11:49Z")
Thanks for the responses everyone! * * * @awe Interesting! So you’re compiling Rust libraries as dynamic libraries to allow reloading the Rust code at runtime? That would indeed break if we changed the definition of the `dylib` crate type, and is a good data point towards just adding a new crate type `cdylib`. * * * @urschrei To clarify, when you compile crates as a `dylib` you don’t intend that downstream users link to the dynamic library, right? You just have dylibs with C ABI entry points? * * * @emoon Do your plugins have a C ABI or are they just loading Rust code into Rust? In the former case that’d continue working, but if it’s the latter we’ll need to call the new crate type `cdylib`. ---
**Author:** ![urschrei](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/urschrei/32/1503_2.png) [@urschrei](https://internals.rust-lang.org/u/urschrei)\ **Post date:** [April 6, 2016, 5:24pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/9 "2016-04-06T17:24:52Z")
Exactly. The `dylib` is solely for FFI use by non-Rust processes. ---
**Author:** ![awe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/awe/32/3902_2.png) [@awe](https://internals.rust-lang.org/u/awe)\ **Post date:** [April 6, 2016, 5:25pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/10 "2016-04-06T17:25:21Z")
Right, I am doing exactly that, but I believe it already broke because of other changes somewhere along the way (i.e. changes to the `dylib` crate, and earlier when it was in `std`, which were not well documented). The actual reloading part seems to always cause a crash on Linux. I haven’t tested recently on OS X. It sounds like @emoon might be doing something similar though. So, there’s probably already a better way to do it than how I am. ---
**Author:** ![geofft](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/geofft/32/1214_2.png) [@geofft](https://internals.rust-lang.org/u/geofft)\ **Post date:** [April 6, 2016, 5:33pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/11 "2016-04-06T17:33:16Z")
[redhook](https://github.com/geofft/redhook) builds LD\_PRELOAD libraries, i.e., they care about C linkage and not Rust linkage, with `crate_type = ["dylib"]`. So as far as I can tell, this change would be beneficial—Rust stdlib continues to be statically linked, and its symbols would _stop_ being exported in the resulting DSO, right? +1 then, and that’s sort of what I expected from `dylib` all along. ---
**Author:** ![emoon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/emoon/32/1333_2.png) [@emoon](https://internals.rust-lang.org/u/emoon)\ **Post date:** [April 6, 2016, 5:42pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/12 "2016-04-06T17:42:54Z")
@alexcrichton I have a C ABI. Also I wonder will the dylib now use `-C prefer-dynamic` as default? This is something that I had a bit of issue with before (10 Rust plugins would have 10 copies of stdlib) ---
**Author:** ![Jascha](https://avatars.discourse-cdn.com/v4/letter/j/bcef8e/32.png) [@Jascha](https://internals.rust-lang.org/u/Jascha)\ **Post date:** [April 6, 2016, 5:55pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/13 "2016-04-06T17:55:34Z")
[minject-rs](https://github.com/Jascha-N/minject-rs) injects DLLs into other processes on Windows. These DLLs are loaded dynamically and optionally specify an `extern "C"` entry point for initialization. So a stand-alone C ABI `dylib` is what I need. Whether `dylib` gets replaced or a new `cdylib` crate type is added doesn’t matter to me. ---
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [April 6, 2016, 6:42pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/14 "2016-04-06T18:42:29Z")
@geofft Yeah the standard library would be statically linked and not exported in the case of a “cdylib” in the RFC, regardless of whatever we end up naming that crate type. @emoon Ok! Right now you can use `-C prefer-dynamic` to not have 10 copies of libstd, but it means everything needs to be recompiled whenever Rust is update. Also judging @awe’s experiences it may just be broken right now? ---
**Author:** ![emoon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/emoon/32/1333_2.png) [@emoon](https://internals.rust-lang.org/u/emoon)\ **Post date:** [April 6, 2016, 6:56pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/15 "2016-04-06T18:56:08Z")
Yeah I’m unable to load the lib when I use `-C prefer-dynamic` (I haven’t looked into it but I figured that it was just because of not finding the dynamic version of stdlib) so right now I’m not using it but I would prefer to do it. ---
**Author:** ![larsberg](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/larsberg/32/250_2.png) [@larsberg](https://internals.rust-lang.org/u/larsberg)\ **Post date:** [April 6, 2016, 7:19pm UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/16 "2016-04-06T19:19:37Z")
We have two scenarios where we build a dylib in Servo: - When targeting Android, Servo will build a dylib, which I believe corresponds to the `cdylib` example from your RFC. I believe that this proposal should work exactly as we like things to work - expose a C/JNI API, all Rust code is linked into it statically, etc. It’s specified via the commandline as `--crate-type dylib` because this same Cargo.toml is also included as an rlib in a different build configuration. - When building a Chromium Embedding Framework (CEF) wrapper, that same previous crate is instead built as an `rlib` and the result is a dylib that exposes C APIs specified by that wrapper framework. We’ve talked in the past about possibly offering Servo as a reusable dylib with a _Rust_ API, but have never gotten around to doing so. So I agree that, at least for us, the `rdylib` case would not seem to apply to us. ---
**Author:** ![mark\_buer](https://avatars.discourse-cdn.com/v4/letter/m/d26b3c/32.png) [@mark\_buer](https://internals.rust-lang.org/u/mark_buer)\ **Post date:** [April 8, 2016, 7:08am UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/17 "2016-04-08T07:08:44Z")
We compile a rust library to a `dylib` for use in a Java based Android app via JNI. We welcome this change, especially if it reduces code size and/or increases runtime performance. ---
**Author:** ![alexcrichton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alexcrichton/32/4501_2.png) [@alexcrichton](https://internals.rust-lang.org/u/alexcrichton)\ **Post date:** [March 25, 2019, 8:26am UTC](https://internals.rust-lang.org/t/do-you-compile-a-dylib/3342/18 "2019-03-25T08:26:01Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.