Hello,
trough random i have seen dylib functioned very well with the nightly branch. All what i have wanted with dylibsmile.
The dy_lib_test.dll is the only dependency and when i delete this dll an error popup, great.
Buut the size of the dy_lib_test.dll is very hugh. When i use all my size optimization based on nightly and i use all functions in the main-binary then this functions cost only a few kbytes in the static binary but the dll is about 1mb large.
No standard optimizations lto,strip, build lib-std and so on are used for the dylib. How can i more crunch that dylib with nightly best with all optimizations???
When you build a DLL, then it has to include all public methods, because it can't know which ones will be used later. Every DLL will also have its own copy of the Rust's standard library (because the DLL can be used by non-Rust executables too), which adds about 300KB.
When you build with a static library, only methods that you use are included, and unused code is discarded, and there's only one copy of the standard library.
Use cargo doc in your library project to see what is exported from it, and make methods private wherever you can. Also try cargo bloat --release.
@kornel Ah okay its clear. Hmm a dll or rlib that doesn't include the standard library is not possible? The dlls/libs are at the moment only to swap out functions from the binarys and not to use as an complied crate.
btw: at the moment i must say for me personally is a dynamic lib not usefull any more.
Technically it’s possible to have libstd as a separate shared library. But Rust doesn’t promise stability of its interface, and operating systems don’t ship it, so unfortunately you still have to pay the cost of embedding libstd everywhere. The best you can do is enable LTO.
can i something optimize for the dylib? I have seen i have dylib_lto activated and the size of the dll, what i had problem with (around 1 mb), are with all that settings. My last hope are that is give still one little nice tricksmile.
When not thx for your explaining. We are in a time where an electron app with hundeds of mbs and little function are acceptable and it feels like a freaky thing to have a little dll under 1mbsmile.
Note that a cdylib can get a lot smaller because it reduces everything down to a concrete C interface. This should be closer to your main-binary, though obviously that comes with the downside of needing C ffi.
@chrisd My mission is to code complete pure safe rust software. Thats only a try, many crates have unsafe function, i know. But to an crate that automaticly all dyn-lib-functions rewrite (when cdylib) with compiler-conditions i don't push it from edge of bed smile. But i hope that dynamicly rlibs or dlls will be get better. In the nightly dylib compiles without cut sdlib from called binarys that an beginning.rust must become more independent.