3 ms·
> All this while Rust, go, and all the new kids on the block use only static linking. This is trivially disproven: $ ldd /usr/bin/rustc linux-vdso.so.1 (
by cesarb 4y ago
> All this while Rust, go, and all the new kids on the block use only static linking.
This is trivially disproven:
$ ldd /usr/bin/rustc
linux-vdso.so.1 (0x00007ffd3de9b000)
librustc_driver-e4385bf403336f76.so => /lib64/librustc_driver-e4385bf403336f76.so (0x00007ff832a00000)
libstd-d371b708c754b3bb.so => /lib64/libstd-d371b708c754b3bb.so (0x00007ff832886000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff832600000)
libLLVM-14.so => /lib64/libLLVM-14.so (0x00007ff82be00000)
[...]
Not only does rustc dynamically link against rust's "std" library, but also parts of rustc are implemented in a dynamic library ("librustc_driver").
The only reason projects written in Rust (other than rustc itself) don't use dynamic linking to other Rust code yet, is that there still isn't a stable ABI for Rust code (for good reason: that allowed them to introduce not only reordering of struct fields and niche optimizations, but also passing and returning slices as a pair of registers instead of a pointer to a two-word structure in the stack). I fully expect that, as the language matures, a stable (possibly opt-in) ABI will be introduced, together with freezing some of its standard library (for instance, the contents of the Vec structure, and how its inline functions work), allowing for dynamic linking against Rust's "std" (and as a consequence, passing Rust types between separate dynamically linked modules compiled with different releases of Rust).
(As an aside: back when C was the "new kid on the block", it also used only static linking, dynamic linking of C code came later.)
- Shorel 4y agoDon't be that misleading. That's the rust compiler. You should analyze an executable created by the rust compiler instead. AFAIK only glibc and libgcc are linked dynamically in a program written in rust, and there's a way to statically link these.
- steveklabnik 4y agoThe Rust compiler is an executable created by the Rust compiler.
- Shorel 4y agoAnd one of the very few, if not the only one, that have to link with LLVM.
- steveklabnik 4y agoThat's true, but many of them that use C libraries dynamically link to those libraries, even if it's not LLVM. OpenSSL is classic example.
- Shorel 4y agoThis entire conversation has managed to diminish my enthusiasm for Rust. =/
- imtringued 4y agoYou can write C libraries in Rust. The entire operating system could be written in Rust and there would still be be dynamic linking between programs. What you are complaining about is ABI stability between versions of Rust but you are hiding that by arguing steveklabnik is violating the spirit of your secret ideals.
- mwcampbell 4y agoIIUC though, the Rust compiler executables are highly unusual in that they dynamically link their main top-level dependency. The vast majority of executables built with cargo do not, and I'm not sure how easy it is for a cargo project to do what the compiler does, i.e. build a top-level crate as a DLL and dynamically link that, while using plenty of static linking within that DLL.
- eddyb 4y ago> but also parts of rustc are implemented in a dynamic library ("librustc_driver") Nit: 100% of rustc is found within librustc_driver-*.so (I mention it in https://news.ycombinator.com/item?id=32329062 https://news.ycombinator.com/item?id=32329062 - which also touches on stable ABI). `rustc` just calls into the .so without any custom configuration: https://github.com/rust-lang/rust/blob/e141246cbbce2a6001f3181d3d0f661bbfd9c7ea/compiler/rustc/src/main.rs#L61-L62 https://github.com/rust-lang/rust/blob/e141246cbbce2a6001f31... (but rustdoc/clippy/miri all have additional configuration, passes, etc. specific to them) Also, if you look at the `rustc` executable's size: $ du -bh ~/.rustup/toolchains/nightly-*/bin/rustc 17K /home/eddy/.rustup/toolchains/nightly-2018-01-01-x86_64-unknown-linux-gnu/bin/rustc 2.9M /home/eddy/.rustup/toolchains/nightly-2021-12-02-x86_64-unknown-linux-gnu/bin/rustc 2.9M /home/eddy/.rustup/toolchains/nightly-2022-01-13-x86_64-unknown-linux-gnu/bin/rustc 2.7M /home/eddy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc 17K is what it should be, I'm not sure where the extra 2.7M are coming from - my current suspicion is that it's entirely statically linked jemalloc, which I guess we didn't want to impose on all users of rustc_driver, but it might be worth doing it anyway.