-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Small fixes for --crate-type staticlib #106224
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
Conversation
This breaks tools that depend on the prefix
Otherwise we may pick the dependency formats for say a dylib when linking a staticlib.
r? @wesleywiser (rustbot has picked a reviewer for you, use r? to override) |
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki |
⌛ Testing commit ed77a61 with merge aaeecca1456e1f5d90a3f5e2cb56686816f3a287... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
I didn't account for it being possible for a crate to have 0 crate types like would happen if you use |
7d29b02
to
7705116
Compare
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d9e317a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
The first commit doesn't have an effect until we start translating error messages. The second commit fixes potential linker errors when combining
--crate-type staticlib
with another crate type and I think-Cprefer-dynamic
.