Repository navigation
Compiler build depends on libstdc++-static #103606
Description
Activity
Seems useful :) Happy to take a PR.
It's a bit unfortunate default for local development but you can change it with
config.tomlby setting this line to false:Line 92 in 77e7b74
(Also remove.examplefrom the name).Changing the default also seems fine; maybe not the global default, but the named profiles in src/bootstrap/defaults at least.
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.mdimmediately 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 buildruns without it -- either by changingconfig.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.
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.
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).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:
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
gettextneeds to be added to the dependencies in theREADME.mdand edited that, build in progress.)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.)
@kubycsolutions
x test tidyis 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.Good 'nuff.
OK. Fixed the missing quote.
The pull request is still failing its sanity checks. Current failure seems to be
RuntimeError: failed to find config line for static-stdcppIt isn't entirely clear which file it's complaining about, but I'm guessing that it wanted
config.llvm_static_stdcpp = true;flipped rather than removed. Trying that.11 remaining items
Hmm, we could gate the default on
channel = dev, maybe. I think I should have a larger conversation with @Mark-Simulacrum about defaults based on the channel, I think defaulting toprofile = userfor a non-dev channel would sidestep a lot of these issues.Reacted by Jon GjengsetMost people working with
x.pyand developing rustc won't build their own LLVM, x.py will download the one from CI for them. Did this here also change the way that that LLVM is built? What does this change even mean for that setting? It will still affect what rustc_llvm does, but obviously it won't affect how LLVM is built...Reacted by Jon Gjengset- The intent was that it would leave LLVM unchanged, affecting only default build of the full compiler. I must admit I haven't done before-and-after comparison of the LLVM to validate that.…-- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ () Plaintext Ribbon Campaign /\ Stamp out HTML mail!________________________________ From: Ralf Jung ***@***.***> Sent: Sunday, November 13, 2022 1:16:31 PM To: rust-lang/rust ***@***.***> Cc: Joseph Kesselman ***@***.***>; Mention ***@***.***> Subject: Re: [rust-lang/rust] Compiler build depends on libstdc++-static (Issue #103606) Most people working with x.py and developing rustc won't build their own LLVM, x.py will download the one from CI for them. Did this here also change the way that that LLVM is built? — Reply to this email directly, view it on GitHub<#103606 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOKT7A5MY44Y47LCOWDZVWTWIEV77ANCNFSM6AAAAAARPQE7HU>. You are receiving this because you were mentioned.Message ID: ***@***.***>
- This started as a suggestion to just add static-libstdcpp to the list of dependencies in the README, rather than having the user go thru discovering its absence only by building. We could still discard my change set and go back to that, if it's the better answer I won't be offended.…-- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ () Plaintext Ribbon Campaign /\ Stamp out HTML mail!________________________________ From: Jon Gjengset ***@***.***> Sent: Sunday, November 13, 2022 1:02:20 PM To: rust-lang/rust ***@***.***> Cc: Joseph Kesselman ***@***.***>; Mention ***@***.***> Subject: Re: [rust-lang/rust] Compiler build depends on libstdc++-static (Issue #103606) Sorry it took me forever to get back to this! Note that the default was specifically changed to statically build against libstdc++ in #94832<#94832>. The reasoning was that it was already the default whenever llvm-tools was included, which seems fairly common, and so we didn't want to suddenly change the default (though aiui, the PR here does). The second part of the reasoning was that the upstream Rust build is statically linked, so that's probably what folks expect, and not statically linking stdc++ makes it decently likely that users of the build (if you ever send it to another host) will run into problems if their stdc++ is older than what was on the build host, which is a pain to work around. — Reply to this email directly, view it on GitHub<#103606 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOKT7A5JZ3JPM65XCCXZYV3WIEUKZANCNFSM6AAAAAARPQE7HU>. You are receiving this because you were mentioned.Message ID: ***@***.***>
To be clear I am happy about this change for entirely unrelated reasons.^^ It brings me one step closer to having rustc_llvm not be rebuilt when I share a build cache between the flatpak sandbox and the host.
I just don't understand why this helps, since I figured either way I must link to the downloaded LLVM. There is logic in bootstrap that prevents one from (un)setting LLVM options, but it seems when the default changes that still somehow has an effect...
That might be a bug ... Can you open an issue?
What is a bug? I don't know what I am talking about here.^^ I just observe that, if I understood the code correctly,
default_optsis used when using LLVM from CI. There are checks that will error if any of these settings is locally changed.But bootstrap then still invokes rustc_llvm as if llvm_static_stdcpp = false -- but the artifact we link against was built with llvm_static_stdcpp = true. Or am I misunderstanding?
We build dist with static libstdc++.
Yes. And then local bootstrap uses the default value for
llvm_static_stdcppwhich is nowfalse. So there is a mismatch. Right?It seems to work though...
- I can say for sure that changing the default of llvm_static_stdcpp changed some build details when using LLVM from CI - it no longer tells the rustc_llvm build script about where the static stdcpp is located. I am happy about the change, but the default is definitely not getting ignored.
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 buildto succeed.In my Win10/WSL/fedoraremix environment, I found I had to also install
libstdc++-staticbefore compilation could start. It now seems to be running without errors (though with some warnings in the.cppfiles 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.