> 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 htt

> 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.