Support dylib LTO

[steveklabnik]

Issue by mprobinson
Tuesday Nov 11, 2014 at 00:52 GMT

For earlier discussion, see rust-lang/rust#18863

This issue was labelled with: in the Rust repository

---

Dylibs are currently bloated with useless library code, see #18541. This can be worked around in a platform specific manner using linker scripts, but the correct solution would be to build them with LTO.

[alexchandel]

Why hasn't this happened yet? LTO is necessary for programs that attempt to dynamically load modules/algorithms, when you want to implement such a module in Rust. The fact that this,

#![crate_type = "dylib"]
#![feature(no_std)]
// ...use stmts, C struct&enum declarations...
#[no_mangle]
pub unsafe extern "system" fn alg_run(p: *mut c_rect, dt: f64, stage: c_stage) -> c_int {
    (if let Some(r) = p.as_mut() {
        r.outputs[0] = 0.;
        r.outputs[1] = 1.;
        r.outputs[2] = 2.;
        r.outputs[3] = 3.;
        OK
    } else {
        NullPtr
    }) as c_int
}

compiles to a 724K dylib after optimization is revolting. I agree that static linking is better. But on platforms where it exists, for programs that use it, dynamic linking is sometimes absolutely necessary. Please stop neglecting it.

[steveklabnik]

Please stop neglecting it.

Please try to recognize that the Rust project has a lot going on, in many different directions. There are tons of things which would be nice to have, but there are only so many hours in the day.

[comex]

Just for the record, you can simulate this by compiling to a staticlib and then converting it to a dylib. For example, on OS X:

rustc --crate-type staticlib test.rs -O -C lto 
clang -dynamiclib -o libtest.dylib libtest.a -Wl,-exported_symbol,_foo -Wl,-dead_strip

[hanna-kruppe]

We have the cdylib crate type now, which should address all cases where one wants to export only extern fns. dylib is just an intermediate Rust-specific output to be consumed by other Rust crates that are compiled with -C prefer-dynamic.