Unreadable error messages on linking failure #46998
Comments
estebank
added
A-diagnostics
|
The problem here is that the error you're seeing is not coming from As further improvement, |
estebank
added
the
E-mentor
|
There's two typical kinds of linking failure 1. the linker does not exist 2. the linker does exist but failed to link successfully. In the former case we definitely should not print the linker command line because it's meaningless when we couldn't find a linker to begin with. Instead printing out some diagnostic information about where In the latter case the linker command line is important as it contains all the information needed to debug issues due to the linker failing to succeed. If you want to know what folders were searched for libraries by the linker you just look for the relevant |
|
@retep998 @estebank If this is an actual bug, I'd love to do this as my first contribution to the rust compiler. I'm not the best Rust developer, but I'm not exactly new to the language either. So my question would be:
Does So for case 1: and for case 2: |
|
Trying to tell which paths were searched for the library is going to be really hard because There is one linker output that I know we can reliably parse and use to print out a much more informative message. If we're targeting |
That is great!
Yes, I believe we can improve significantly over the current output.
I definitely believe this is the main fix for this issue.
We already output the linker's result, which should be enough but not great. Scraping the output in order to output the error in a consistent way as the rest of
It depends, on cases like this the compiler usually bails out. We have a struct would be created by an
I believe it should know that, but in this case where
I believe this is gonna be trickier to accomplish (would have to dig deeper in the code to see if it is even possible at the moment), I would keep that feature as a follow up PR, so that you can focus on a single smaller task to get a feel for the compiler codebase. Once you're acquainted with it, we can look to see if we can get the relevant span (I'm not sure if it's possible), how to expose the missing library name and the search paths. How does that sound, @fschutt? |
|
Sure, doing the easy things first. The thing I'm currently running into is this: I am not sure what "you should run a normal build first" means - I just ran |
|
Why are you running with |
|
Thanks, I got it to build. I'll try to do a PR. |
|
So I now changed it to output: ... however, I think it's easier shortening the error message to: It's better to read imho, because if you use a terminal, you need less time to understand the error. |
|
Could you move the OS error to a It would also be amazing if depending on the environment being run we had an error message with a targeted description similar to the troubleshooting in the first edition of The Book telling you how to fix the problem without having to google it. Nitpicks aside, feel free to post the PR at your earliest convenience! I love seeing this kind of small, incremental but dramatic usability improvements :D |
Improved error messages for linking failure Partial fix for #46998 It's unnecessary to print the linker options if there is no linker installed in the first place. Currently, for libraries, the output is still printed, but that should be cleaned up in the future. If you don't have gcc or g installed, so that no linker is installed on the system, the output is now this: ``` $ ./rustc hello.rs error: linker `cc` not found | = note: No such file or directory (os error 2) error: aborting due to previous error ``` For libraries, the linker arguments are still printed, but they should be cleaned up in further commits.
|
Now that #47052 is merged, I'd think I should work on the help and other error messages. For missing libraries, the linker arguments are largely useless, at least for gcc, not sure about MSVC. Basically, with gcc, it's often enough to see the message: .. to tell you that a certain library is not installed. Which could be a bit more nicely formatted like For help, I'd print out at least the $PATH (which is just a convenience). There is (I think) already a function to parse the PATH variable in the compiler, I saw it somewhere. Additionally, cargo can specify additional library search directories (in I think getting the code section that caused the linking: ... is impossible, so I'd drop that. Also it's not really helpful, the only time where this message would be helpful is when the package maintainer first builds the crate, at which point he probably knows what code section links the external library. So it wouldn't be useful except for the crate maintainer. I'll do another PR on how I think the help section should / could look like. |
|
Both |
|
@retep998 Oh, ok, sorry. But what (exact) environment variables do you mean - do you have any references or sources? GCC has a |
|
@fschutt For example I don't know of any flag to ask Also keep in mind for |
@retep998 the advantage we have is that is is
This seems like the best possible option at the moment. I think that you should tackle this one step at a time, improving what can be improved, even if that means keeping the current output when using |
|
It could take a while until I can work on this issue again. If somebody else wants to do this, go ahead. I haven't worked on this so far. |
|
I also get the linker cc not found error for the "rust" package with clang in Void Linux 3.7. It turns out to be an issue with how the Void Linux clang package fails to install a shim for "cc". As a workaround, I'm using gcc instead of clang :/ |
jonas-schievink
added
the
A-linkage
|
Specific case we could also handle more gracefully: |
crlf0710
added
the
T-compiler
|
I've encountered this bug due to the linking errors when linking targets with rustc in Chromium. Chromium is a large project, so the number of command line arguments passed to the linker is very many. Since rustc prints the whole command line of the linker when it encounters an error, the terminal is spammed with thousands of lines of (wrapped) output.
With the default error-format, you can see an example of the length of the error message here: https://pastebin.com/raw/UKLFErKE The actual error is short, but is lead with many lines of spam to print out the command-line: Note that clang does not print the invocation of the linker command line unless you pass -v, and it mentions this in its own error message: |
|
@michaelwoerister You've assisted me in the past (thank you!), could you advise if the issue of the linker invocation always being part of the output should be raised as a separate bug, and if an MCP would be needed to change the default behaviour and/or add a new option for --error-format? |
|
note that this is the current output if the linker can't be exec'd: ; rustc src/main.rs -C linker=not-found
error: linker `not-found` not found
|
= note: No such file or directory (os error 2)
error: aborting due to 1 previous errorit would be nice to print PATH like fschutt suggested, though.
this is interesting. rustc will do this today if you pass the other parts of this issue are tracked by #83436 and #109979. |
this ends up being very verbose, though - i wonder if rustc should suggest |
|
@jyn514 the only thing I'd like to add as a check is confirming that the flags will work for the linker being used, but other than that I think it is reasonable to suggest the appropriate flags to add. I think it might be reasonable to make |
show linker output even if the linker succeeds - show stderr by default - show stdout if `--verbose` is passed - remove both from RUSTC_LOG - hide the linker cli args unless `--verbose` is passed fixes rust-lang#83436. fixes rust-lang#38206. fixes rust-lang#109979. helps with rust-lang#46998. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134 this is based on rust-lang#119129 for convenience so i didn't have to duplicate the changes around saving `--verbose` in rust-lang@cb6d033#diff-7a49efa20548d6806dbe1c66dd4dc445fda18fcbbf1709520cadecc4841aae12 r? `@bjorn3`
show linker output even if the linker succeeds - show stderr by default - show stdout if `--verbose` is passed - remove both from RUSTC_LOG - hide the linker cli args unless `--verbose` is passed fixes rust-lang#83436. fixes rust-lang#38206. fixes rust-lang#109979. helps with rust-lang#46998. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134 this is based on rust-lang#119129 for convenience so i didn't have to duplicate the changes around saving `--verbose` in rust-lang@cb6d033#diff-7a49efa20548d6806dbe1c66dd4dc445fda18fcbbf1709520cadecc4841aae12 r? `@bjorn3`
This is a very annoying aspect of rustc - if it fails to link a library, it doesn't tell you the path, it doesn't tell you which library it couldn't find, it just spits out a completely unreadable error message and quits. For example:
Right, now try and read what the actual error is. In this case, the linker
ccis missing, but the error message is similar if a system library is missing - ex. you tried to use curl-rs but you don't have libcurl installed. In that case, you have to search for the missing library somewhere in the last arguments.Please:
That would be my suggestion for improving cargo. It's simply annoying to figure out which library is missing (99,99% it's a system dependency).
Linked from rust-lang/cargo#4863
The text was updated successfully, but these errors were encountered: