-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Building rustc without using the system defaults #12097
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm attempting:
.. based on feedback in IRC - will update once I know if it works or not. |
Closing, the recent changes to the configure script and the makefiles should allow for the standard |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jul 25, 2022
Revert rust-lang#11490 Closes rust-lang#11725 rust-lang#11490 was a little misguided. Quoting the test name should be a client concern, since it's the client that actually runs `cargo`.
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jan 11, 2024
don't change eagerness for struct literal syntax with significant drop Fixes the bug reported by `@ju1ius` in rust-lang/rust-clippy#9427 (comment). `eager_or_lazy` already understands to suppress eagerness changes when the expression type has a significant drop impl, but only for initialization of tuple structs or unit structs. This changes it to also avoid changing it for `Self { .. }` and `TypeWithDrop { .. }` changelog: [`unnecessary_lazy_eval`]: don't suggest changing eagerness for struct literal syntax when type has a significant drop impl
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are use-cases where one might want to build
rustc
from source without having the build process use the default system gcc/glibc.Right now, I can't see a way to achieve this with a flag. One possible solution is to create a wrapper script for the stage0 rustc which calls the real stage0 rustc with
--link-args
,--linker
and so forth.The reason I don't like this is it essentially involves a prebuild/patch step - these are usually quite brittle and difficult to maintain.
A possible future solution might be to have some env var,
STAGE0_FLAGS
or similar, which one could export before runningmake
./cc @cmr
The text was updated successfully, but these errors were encountered: