-
Notifications
You must be signed in to change notification settings - Fork 13.4k
make RUSTFLAGS="-Ccodegen-units=N"
always starts building at rsbegin.o
#30063
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've noticed something like this too.
I'm on Windows/MSYS2 as you can see. |
This may be because we don't actually emit |
@alexcrichton disabling |
I guess this would also be stronger than necessary, since as stated it would even cover cases where one is generating a binary to execute (which today is compatible with So maybe what I really wanted to ask about was disabling |
Well specifically I would expect Note that emission of a binary is fine because we link the objects together into one binary, so it's unaffected by codegen units. |
@alexcrichton that's interesting; I had thought it would at least acceptable (if perhaps unexpected) for I'll admit that does not sound like an ideal user interface. But since the workaround is easy when one does want one particular output file (namely to use By the way, on the subject of selecting file names for outputs, see also #30204 |
Hm I guess I just see codegen units as a bit of an optimization (e.g. along the lines of |
@alexcrichton Sure, I am not suggesting that we try today to make multiple codegen units work with one output object file. I'm more saying that we can embrace the semantics we are already providing, where e.g. |
Yeah I guess I'm not totally opposed to that either, but I feel like it makes bugs like this surprising and hard to solve. If you've gone out of your way to say |
@alexcrichton okay well I'm about to put up a PR to "fix" the narrow case of combining all of So once that's up I'll ask you to make a call as to whether to go with that short-term worse-is-better solution, or if we should hold out for a more principled design. |
Ok, sounds good to me, thanks @pnkfelix! |
(another option could be to add plural variants for each of the emit-types in question, e.g. |
Yeah that seems reasonable, although I wouldn't want to push forward with that just quite yet. |
…ts back to 1. Fix rust-lang#30063 Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream.
The `rsbegin.o` and `rsend.o` build products should not be generated on non WinGnu platforms. This is another path to resolving rust-lang#30063 for non win-gnu targets. (And it won't require a snapshot, unlike PR rust-lang#30208.)
When given `rustc -C codegen-units=4 --emit=obj`, reset units back to 1. Fix #30063 Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without `-o PATH` will "work", though it will downgrade codegen-units to 1 just like all the other cases.) r? @alexcrichton
…alexcrichton The `rsbegin.o` and `rsend.o` build products should not be generated on non WinGnu platforms. This is another path to resolving #30063 for non win-gnu targets. (And it won't require a snapshot, unlike PR #30208.) r? @alexcrichton
Needless to say, this is really inconvenient. This is happening because the make recipe calls rustc with
-o
, which is ignored whencodegen-units
is present. Make will then always recompilersbegin.o
andrsend.o
, since they aren't actually created.The build still works for me, since the files aren't actually needed on Linux, but would probably fail on
x86-windows-gnu
according torsbegin.rs
(I haven't actually checked).RUSTFLAGS
should probably be ignored for these targets. I have no idea how, since the makefiles look like something straight out of/dev/random
.The text was updated successfully, but these errors were encountered: