-
Notifications
You must be signed in to change notification settings - Fork 13k
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
linker failure on macOS when building Miri: "linker stderr: ld: ignoring duplicate libraries" #136086
Comments
i am not sure what to tell you. those warnings were already there before, they were just unconditionally silenced instead of being silenced by a lint. i saw these “duplicate library” warnings in CI when landing the PR and i did not investigate them because there were about a dozen other types of warnings too, and each takes me a couple weeks to track down: #135828 i still think giving you the option between using -A linker-messages and investigating yourself is better than unconditionally silencing the messages. @rustbot label L-linker_messages |
I'm not convinced failing my build is the right call here; I asked for Rust warnings to be made errors (which are generally well-documented and understandable), but I didn't ask for inscrutable unactionable linker warnings that apparently do not reflect an actual problem to become hard errors. |
The other option, which I implemented initially, is to make this a hard warning instead of a lint. But that’s worse in other respects, because now you can’t allow it at all. So people will end up with unsilencable warnings when building locally. I do not think it is a good idea to go back to silencing this unconditionally. In your case the warnings are not useful, but in other cases like #83436, the warnings are very useful and could have helped identify a very tricky bug earlier. |
it does seem like macOS LD is more chatty than other linkers, and if we can find some way to silence these particular warnings you’re getting for everyone, I would be OK with that. But I do not think we should silence all warnings unconditionally, not even if we scope that to macOS. |
given this, and that @saethlin tells me he has seen this warning on almost every macOS linker error, I plan to do three things:
|
We've discussed this a bit more and came to the conclusion that we should make it fully allow by default for now and at least do a (GNU/Linux only of course) crater run to see some more warning patterns that we may want to filter out. |
Sounds good :)
|
Downgrade `linker-warnings` to allow-by-default This needs more time to bake before we turn it on. Turning it on early risks people silencing the warning indefinitely, before we have the chance to make it less noisy. cc rust-lang#136096 fixes rust-lang#136086 (comment) r? `@saethlin` cc `@Noratrieb` `@bjorn3` `@rustbot` label A-linkage L-linker_messages
Downgrade `linker-warnings` to allow-by-default This needs more time to bake before we turn it on. Turning it on early risks people silencing the warning indefinitely, before we have the chance to make it less noisy. cc rust-lang#136096 fixes rust-lang#136086 (comment) r? `@saethlin` cc `@Noratrieb` `@bjorn3` `@rustbot` label A-linkage L-linker_messages
Builds with |
Experimentation locally indicates no. I tried the reproducer for #136109 on the nightly that just released and it now builds fine even with |
Ah right, it's not a "warning" any more so not affected by that flag. |
Downgrade `linker-warnings` to allow-by-default This needs more time to bake before we turn it on. Turning it on early risks people silencing the warning indefinitely, before we have the chance to make it less noisy. cc rust-lang/rust#136096 fixes rust-lang/rust#136086 (comment) r? `@saethlin` cc `@Noratrieb` `@bjorn3` `@rustbot` label A-linkage L-linker_messages
Miri is failing to build on macOS:
Regression range: 814ebca...2f0ad2a
The text was updated successfully, but these errors were encountered: