Release binaries dynamically links to rustc libraries

[williamboman]

Hello! Starting with the 1.5.3 release it seems like the provided binaries dynamically links to rustc libraries:

$ ldd rustfmt_linux-x86_64_v1.6.0/rustfmt
        linux-vdso.so.1 (0x00007ffc5d7b2000)
        librustc_driver-5d7211076ef5de36.so => not found
        libstd-c1ef87628285f700.so => not found
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc3f02aa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc3f015b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc3eff69000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc3f074f000)

Are the release binaries meant for public consumption or are they merely just an artifact of the CI process? If the new links wasn't intentional and were to be fixed, are there any drawbacks of using these instead of managing installation via rustup component?

[calebcartwright]

Thanks for reaching out. I'll answer your questions inline below, but I'm also going to close as this is a duplicate of other issues/PRs

Are the release binaries meant for public consumption or are they merely just an artifact of the CI process?

Once upon a time, yes they were, though not as a preferred/primary means of acquiring rustfmt.

If the new links wasn't intentional and were to be fixed, are there any drawbacks of using these instead of managing installation via rustup component?

Please see discussion in #5761 as well as #5675 (comment) and #5675 (comment) for more info. The dynamic linkage comes from upstream rustc components, and isn't something we can control.

I don't think we're likely to continue including binaries in the GitHub releases, not only because it's now impossible (or at least difficult) to ship fully self-contained binaries, but also just for practical reasons. None of the other official tools ship their own binaries outside the official Rust distribution channels, and I'm not aware of any realistic use cases where a user would want a rustfmt binary and not want/need to have a Rust toolchain

[williamboman]

I see, thanks for explaining! Would you completely rule out the option of bundling these libraries in the release archive and rpath-ing these in the binaries?

None of the other official tools ship their own binaries outside the official Rust distribution channels, and I'm not aware of any realistic use cases where a user would want a rustfmt binary and not want/need to have a Rust toolchain

This is perhaps the wrong place to ask, but do you know if this will this apply to rust-analyzer as well in the future? I maintain https://github.com/mason-org/mason-registry which has a Neovim plugin that allows users to manage external editor tooling through a single convenient interface (rust-analyzer is one of the most popular one), and there's only a few (often archaic) packages that are not feasible to add due to a reliance on some external toolchain. I'm a bit surprised to see Rust packages being one of these, although I understand the constraints.

Just to make sure I'm not missing something - by Rust distribution channel you mean the rustup component system?

[calebcartwright]

Apologies for the delayed response. This got buried pretty deeply in my notification inbox

Would you completely rule out the option of bundling these libraries in the release archive and rpath-ing these in the binaries?

If you or someone else was willing to submit and test a PR then I'd be willing to try to support it for the next few releases as a tactical measure. However, long term this is still something that's going to have to go away. Rustfmt was unique in doing this in the first place (you'll not find binary distributions of clippy, miri, and the other official tools), and trying to support this is a big part of what complicates our release process that in turn has some knock-on effects that slow down other aspects of rustfmt development/delivery

This is perhaps the wrong place to ask, but do you know if this will this apply to rust-analyzer as well in the future?

I don't think so, although I can't speak authoritatively on the subject. My understanding is that RA uses its own front-end vs rustc's internal modules like rustfmt and the other tools do, so I suspect RA isn't as effect by such upstream changes made in the compiler.

by Rust distribution channel you mean the rustup component system?

Correct, getting the tools as part of a toolchain via rustup is really the "official" way to get rustfmt