Compiler build depends on libstdc++-static

[kubycsolutions]

Location

https://github.com/rust-lang/rust#building-on-a-unix-like-system

Summary

The README lists a number of packages which have to be present for ./x.py build to succeed.

In my Win10/WSL/fedoraremix environment, I found I had to also install libstdc++-static before compilation could start. It now seems to be running without errors (though with some warnings in the .cpp files on -Warray-bounds, -Wnonnull, and -Wcast-function-type).

This may be a quirk of how this fedora was adapted to run under WSL. But adding that dependency to the instructions seems worth considering; it shouldn't hurt anything and might help some.

[jyn514]

Seems useful :) Happy to take a PR.

[mati865]

It's a bit unfortunate default for local development but you can change it with config.toml by setting this line to false:

rust/config.toml.example

Line 92 in 77e7b74

#static-libstdcpp = true

(Also remove .example from the name).

[jyn514]

Changing the default also seems fine; maybe not the global default, but the named profiles in src/bootstrap/defaults at least.

[kubycsolutions]

OK, folks, I need a decision on that. This is the default build configuration, which beginners will not look inside until later. It would seem odd to me to have the basic README.md immediately tell folks they have the option of changing this one parameter. I think we would want their first build to succeed with as little manual work as possible.

So our choices seem to be to add the static C++ library to the dependencies (and let them decide not to use it later, if so inclined), or to ensure x.py build runs without it -- either by changing config.toml.example, or by changing the default in the code (stylistically better than having the example override the defaults), possibly on a selective basis as @jyn514 proposed.

The first option is strictly a one-line text change, which I can submit a pull request for. Changing the build's defaults would need to either wait for me to dive significantly deeper into this codebase, or be done by someone else.

As a raw newbie in Rust, I don't think I should be the one to make that decision -- it's stylistic as much as coding, and I don't yet have any sense of the community's preferences or have a strong opinion either way.

[jyn514]

I don't know the history of this option. @jonhoo @mati865 why would you ever want to turn it on, given that it requires you to have an extra dependency turned on?

@kubycsolutions I think adding a note to the readme that you need the dependency is a good change in the meantime.

[mati865]

It's useful for dist builds because with that option disabled your binaries will depend on compatible libstdc++. Which might be hard to supply when building rustc for other system.
For local development I think there is no visible differences (there might be 1% perf improvement with static lib but it doesn't really matter).

[jyn514]

Ok, cool. Sounds like we should disable it by default and reenable it in dist builders. @kubycsolutions are you interested in making that change? :)

Mentoring instructions:

• remove

  rust/src/bootstrap/config.rs

  Line 784 in b0f3940

  config.llvm_static_stdcpp = true;

• flip

  rust/config.toml.example

  Line 92 in b0f3940

  #static-libstdcpp = true

• add --set build.static-stdcpp in

  rust/src/ci/run.sh

  Line 65 in 2afca78

  RUST_CONFIGURE_ARGS="$RUST_CONFIGURE_ARGS --set rust.codegen-units-std=1"

[kubycsolutions]

Soitenly. Expect pull request a bit later. I need to check your practice -- fork first, or for something this simple just submit PR? (Most projects prefer fork. I tend to cheat on my own.)

(Woke up, got my eyes uncrossed, edited, noted that gettext needs to be added to the dependencies in the README.md and edited that, build in progress.)

[kubycsolutions]

Might be overkill for this, but for future reference: What's the recommended smoketest before a PR against rust? (I know the compiler built, and I believe the change is correct, but... (Belt, suspenders, helium balloons, drones.)

[jyn514]

@kubycsolutions x test tidy is a good smoke test, or if you're refactoring code, x check. If you've built the compiler successfully that's more than enough; PR CI will catch most of the rest.

[kubycsolutions]

Good 'nuff.