Instructions in Readme.md assume rustup without mentioning it

[glaubitz]

I was just following through the instructions in the Readme.md and noticed that the setup scripts require rustup to be present without ever mentioning how to install rustup. rustup is an upstream tool that is usually not available in Linux distributions due security implications.

Thus, the build instructions should be extended to include the installation of rustup. Alternatively, it would be preferable not to use rustup at all but rather rely on the tools supplied by the distribution repositories.

[antoyo]

Sure, I'll update the README.

rustc_codegen_gcc uses the unstable flag -Zcodegen-backend, so it requires rust nightly. Do some distributions provide packages for specific Rust nightly?

[glaubitz]

Thanks for the clarification. Is the -Zcodegen-backend flag generally disabled for stable Rust releases?

[antoyo]

My understanding is that it's always disabled for stable releases. Any -Z flag is and an attempt to use one on stable would result in:

error: the option `Z` is only accepted on the nightly compiler

And I bet this codegen-backend will remain unstable for a long time since its API keep changing. But I could be wrong about this.

[glaubitz]

OK. I would have assumed that you would build Rust from source yourself anyway. And I'm not sure why you would need rustup for that.

[antoyo]

Since I don't have to build rustc (as I only build a .so that is loaded by rustc), I avoid it.
I pick a nightly version and pin to it in this file.

[antoyo]

If the concern is the distribution of the gcc-based rustc to Linux distros, perhaps the best would be to build rustc with codegen-backends = ["gcc"] in the config.toml.
That would not require rustup.

[bjorn3]

And I bet this codegen-backend will remain unstable for a long time since its API keep changing. But I could be wrong about this.

-Zcodegen-backend may end up getting stabilized as -Ccodegen-backend in the future, but in that case it will only allow switching between codegen backends distributed with rustc itself (which cg_gcc may become in the future), not external backends. For external backends it will likely remain unstable for a long time if not permanently.

If the concern is the distribution of the gcc-based rustc to Linux distros, perhaps the best would be to build rustc with codegen-backends = ["gcc"] in the config.toml.

It isn't wired up to ./x.py dist yet unfortunately. Part of rust-lang/rust#81746 is wiring this up.

[glaubitz]

If the concern is the distribution of the gcc-based rustc to Linux distros, perhaps the best would be to build rustc with codegen-backends = ["gcc"] in the config.toml. That would not require rustup.

Ah, that sounds like a good idea. If it's actually possible to build Rust with both backends enabled without running into any build failures, I will look into enabling that for Debian's rustc package. Then it should be much easier to test the GCC backend on Debian and Ubuntu.

[bjorn3]

I think it is a bit premature for that. Building with multiple backends has been supported for several years, but producing dist packages containing backends other than llvm is not yet possible. In addition switching backends is not yet possible on stable.

[glaubitz]

I'm aware of the fact that alternative backends are not mature yet. I'm more interested in making it easier to test alternative backends so that more developers and users can provide feedback and fixes.

But I guess we will have to wait at least until all GCC patches have been merged upstream so that a standard distribution GCC package can be used.

[Gerson2102]

PR is up, i don't know if still necessary to assign this issue to me.

[GuillaumeGomez]

Not necessary but assigned you anyway.