-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
For dylib crates, warn about GNU ld <=2.28 #66839
For dylib crates, warn about GNU ld <=2.28 #66839
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
We may well not want to do this. (We might be better off just closing #61539 at this point.) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I definitely feel weird not having implemented something like this soon after opening #61539 (but I don't remember the context very well, I think it was low priority for me, someone having stumbled over it by doing very unstable proc macro manual loading). I wish there was a https://caniuse.com but for the GNU/Linux ecosystem... |
Could this also be sure to not do any detection unless something goes wrong? This sort of version detection can be pretty expensive and it runs a risk of being added to all compilations by default (those calling the linker). Ideally the diagnostics could be improved but not at the cost of when the diagnostic doesn't fire |
@alexcrichton The problem is that it goes wrong when you go to Then again, it's very unstable to |
@eddyb wasn't the problem originally exposed by a (maybe there's some detail I'm missing, e.g. as outlined in #60593 (comment) ...?) |
Ah, I overlooked this part of a comment from @eddyb from #60593:
So maybe the answer is that yes, the problem can arise for proc-macros, but not in any usage state that we officially support, ... ... and therefore we could plausibly revise this PR to only warn about |
That issue is what I'm referring to by "very unstable to Looking at the linked comment, I wrote:
So I guess there would be a scenario where rustc is handling the |
Someone at my office did point me at the whohas tool as a way to query package versions with various distributions. I tried running it to get a survey of what versions of |
We could use https://repology.org/project/binutils/versions: |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@eddyb ah ok. I guess I basically just wanted to point out then that this is going to add a cost to all compilations which invoke the linker, and a relatively nontrivial cost. I also suspect that almost all compilations will not actually run into this issue, so it may or may not be worth having a warning specifically for this. |
Its not meant to be run on all compilations that invoke the linker. (But maybe that was just hyperbole on your part?) As originally drafted, I meant for it to run on just compilations of Based on the conversation with @eddyb, I am inclined to further restrict it to just But I will admit it is possible that even restricting it to |
…NU ld bugs like issue 61539.
…reduce false-positive rate.
d8c2fb9
to
6644747
Compare
…han assuming it starts with "GNU ld version "
…e check. (The first version of the PR had this implicitly by always searching for the string literal "GNU ld version " when looking for where to start the search for the version number.)
6644747
to
c4a76c4
Compare
If this is restricted to just |
I'm unfortunately probably not the best reviewer for this. I personally don't think that rustc should be doing any verison checking at all, in my opinion it's far too low-level of a tool to do so. I also have basically no understanding of what this bug is or what this has to do with a linker, so I think I'm not necssarily qualified to review the intention of the PR either. @eddyb would you be willing to review this? |
Some GNU ld versions have a bug that makes them incompatible with the post-#54592 "no PLT" world. However, most things work, just not some situations where an executable loads a I'm also unsure we should land this. The benefits appear to be marginal, I don't think we've seen a bug report other than manually loading proc macros through very unstable internal implementation details. |
Ah unfortunately while that describes the bug at a high level I still don't really understand what all is in play here. I don't know, for example, how our usage of the PLT changed over time, how this is running afoul of a linker bug, what possible solutions would be, etc. Sounds like you do though! I'll go ahead and... r? @eddyb |
er oops... r? @eddyb |
I don't think we figured out what commit actually fixed that bug though, just that it was at some point between 2.28 and 2.29, IIRC. r? @nagisa |
based on above comment with data on the |
Okay well I made the effort but I don't think there is general interest in landing this lint at this time. . . closing PR. |
This is a heuristic diagnostic to try to help prevent issues related to issue #61539.