Unreadable error messages on linking failure

[fschutt]

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:

   Compiling deflate v0.7.17
error: could not exec the linker `cc`: No such file or directory (os error 2)
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/felix/.rustup/toolchains/stable-
x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" 
"/home/felix/Development/srtmtoimage/target/debug/build/kernel32-sys-
23866d7aeb753806/build_script_build-23866d7aeb753806.build_script_build0.rust-cgu.o" "-o" 
"/home/felix/Development/srtmtoimage/target/debug/build/kernel32-sys-
23866d7aeb753806/build_script_build-23866d7aeb753806" 
"/home/felix/Development/srtmtoimage/target/debug/build/kernel32-sys-
23866d7aeb753806/build_script_build-23866d7aeb753806.crate.allocator.rust-cgu.o" "-Wl,--gc-
sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" 
"/home/felix/Development/srtmtoimage/target/debug/deps" "-L" "/home/felix/.rustup/toolchains/stable-
x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" 
"/home/felix/Development/srtmtoimage/target/debug/deps/libbuild-055e23f8aa405a7b.rlib" 
"/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-
gnu/lib/libstd-fe0b1b991511fcaa.rlib" "/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-
gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-3d7b10e850a67e89.rlib" 
"/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-
gnu/lib/liballoc_jemalloc-28484309357fd6f1.rlib" "/home/felix/.rustup/toolchains/stable-x86_64-
unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-751808ba756769d5.rlib"
 "/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-
gnu/lib/libpanic_unwind-8cb97051d8238386.rlib" "/home/felix/.rustup/toolchains/stable-x86_64-
unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-25cc9b024a02d330.rlib"
 "/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-
gnu/lib/liblibc-d42e80cee81b06ce.rlib" "/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-
gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-78c21267a2dc15c1.rlib" 
"/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-
gnu/lib/libstd_unicode-0e1b544c94586415.rlib" "/home/felix/.rustup/toolchains/stable-x86_64
-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-0c5e3d6c117f8c44.rlib"
 "/home/felix/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-
gnu/lib/libcompiler_builtins-bd7cc5ada1e908e0.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l"
 "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util"

error: aborting due to previous error

error: Could not compile `rayon-core`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `kernel32-sys`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Right, now try and read what the actual error is. In this case, the linker cc is 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:

• Don't just quit with "No such file or directory" - it's one of the most useless error messages ever. Please include at least the file name where rustc expected the linker / library to be.
• If it is a linker error, please don't output the whole paths to the libraries. Just tell me which library wasn't found
• Maybe include the folders that rust searched for the libraries (helpful for debugging $PATH issues)
• Don't output the location of every object file / library, it's not helpful.

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

[estebank]

The problem here is that the error you're seeing is not coming from rustc, but rather from shelling out and trying to run cc. We can improve this error in particular by indeed verifying that the linker we're trying to run is there and emitting a different error for it in link.rs and write.rs, including the path information from the environment.

As further improvement, rustc could also probably scrape the output of the linker for known errors to minimize the output in those cases, and fall back to the current behavior (printing the entirety of the linkers output).

[retep998]

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 rustc tried to look for the linker would be more useful (in particular this would be very useful for msvc where finding the linker is actually really complicated).

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 -L or /LIBPATH flags. Oftentimes there is a lot of irrelevant junk in the command line but trying to filter it down is a really difficult challenge because sometimes the stuff that seems like junk contains some vital detail.

[fschutt]

@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:

• Can we agree that this is undesired behaviour and should be fixed?
• How would you think the output should look like (i.e. what should the error message tell)? I'd personally agree with @retep998:
  • If the linker doesn't exist, the linker arguments are not printed, because it wouldn't make sense, instead the paths where the linker was searched for are printed in some way.
  • If the linker exists, but failed to build, we need to somehow identify the library that could not be linked and the paths the library was searched for.
• I don't know exactly how the error handling in rustc works - are errors handled with abstractions (error_chain, failure, etc.) or does the compiler just panic / abort in place?

Does rustc already know the name of the library it's linking?Theoretically speaking, the strategy I'd think about: If rustc invokes the linker with let's say -lcurl it has to give the string "curl" somehow to the linker right? So what the compiler could do is to track what the latest linker argument was - and if the linker throws an error, we parse the output, print the paths and exit.

So for case 1:

error: could not exec the linker `cc`: linker not found (os error 2)
  |
  = note: this error originates in the crate "deflate"
  = note: searched for linker in the following paths:
     /usr/bin/
     /usr/local/bin
     /usr/sbin

and for case 2:

error: linking with `cc` failed: exit code: 1
 --> deflate/build.rs:2:5
  |
2 |     println!("cargo:rustc-link-lib=asdfasdf");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
= note: /usr/bin/ld: cannot find library "asdfasdf"
= note: searched for library in the following paths:
     /usr/bin/
     /usr/local/bin
     /usr/sbin
= note: collect2: error: ld returned 1 exit status

[retep998]

Trying to tell which paths were searched for the library is going to be really hard because rustc does not actually know all the paths where the linker searches for libraries. Environment variables and system configuration can determine additional directories where the linker will search which rustc never told the linker to search in, and this differs between different toolchains (msvc again being significantly different in this regard).

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 pc-windows-msvc and the linker output contains link: extra operand then that is definitely not the linker we want but the coreutils command link, in which case rustc needs to print out a very helpful message telling the user they need to install the VC++ build tools.

[estebank]

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.

That is great!

• Can we agree that this is undesired behaviour and should be fixed?

Yes, I believe we can improve significantly over the current output.

• How would you think the output should look like (i.e. what should the error message tell)? I'd personally agree with @retep998:
  • If the linker doesn't exist, the linker arguments are not printed, because it wouldn't make sense, instead the paths where the linker was searched for are printed in some way.

I definitely believe this is the main fix for this issue.

• If the linker exists, but failed to build, we need to somehow identify the library that could not be linked and the paths the library was searched for.

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 rustc errors would be the best bet, if not exhaustive.

• I don't know exactly how the error handling in rustc works - are errors handled with abstractions (error_chain, failure, etc.) or does the compiler just panic / abort in place?

It depends, on cases like this the compiler usually bails out. We have a struct DiagnosticBuilder which encodes the errors you normally see, which can have a message, an error code, a bunch of spans with labels, and a bunch of note/help with optional span information. The proposed output

error: could not exec the linker `cc`: linker not found (os error 2)
  |
  = note: this error originates in the crate "deflate"
  = note: searched for linker in the following paths:
          /usr/bin/
          /usr/local/bin
          /usr/sbin

would be created by an let mut err: DiagnosticBuilder with err.note(&format!("this error originates in the crate \"{}\"", crate_name)); and err.note("searched for linker in the following paths:\n/usr/bin/\n/usr/local/bin\n/usr/sbin");.

Does rustc already know the name of the library it's linking? Theoretically speaking, the strategy I'd think about: If rustc invokes the linker with let's say -lcurl it has to give the string "curl" somehow to the linker right? So what the compiler could do is to track what the latest linker argument was - and if the linker throws an error, we parse the output, print the paths and exit.

I believe it should know that, but in this case where cc is not available, the crate failing to compile is not as relevant, and will be pointed out right before:

   Compiling deflate v0.7.17
error: could not exec the linker `cc`: linker not found (os error 2)
  |
  = note: searched for linker in the following paths:
          /usr/bin/
          /usr/local/bin
          /usr/sbin

and for case 2:

error: linking with `cc` failed: exit code: 1
 --> deflate/build.rs:2:5
  |
2 |     println!("cargo:rustc-link-lib=asdfasdf");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
= note: /usr/bin/ld: cannot find library "asdfasdf"
= note: searched for library in the following paths:
     /usr/bin/
     /usr/local/bin
     /usr/sbin
= note: collect2: error: ld returned 1 exit status

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?

[fschutt]

Sure, doing the easy things first. The thing I'm currently running into is this:

info: looks like you are running this command under `sudo`
      and so in order to preserve your $HOME this will now
      use vendored sources by default. Note that if this
      does not work you should run a normal build first
      before running a command like `sudo make install`
Updating submodules
error: failed to load source for a dependency on `cc`

Caused by:
  Unable to update registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to update replaced source registry `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to read root of directory source: ~/rust/src/vendor

Caused by:
  No such file or directory (os error 2)

I am not sure what "you should run a normal build first" means - I just ran sudo ./x.py build. Not sure what "normal build" means I should do. I cloned into ~/rust, but the folder ~/rust/src/vendor doesn't exist. I tried configure + make, but that seems to do the same. This happens even with a clean install.

[estebank]

Why are you running with sudo? The build should work as expected running as your user (./x.py build).

[fschutt]

Thanks, I got it to build. I'll try to do a PR.

[fschutt]

So I now changed it to output:

error: could not exec the linker `cc`: linker not found: No such file or directory (os error 2)

error: aborting due to previous error

... however, I think it's easier shortening the error message to:

error: linker `cc` not found: No such file or directory (os error 2)

error: aborting due to previous error

It's better to read imho, because if you use a terminal, you need less time to understand the error.

[estebank]

Could you move the OS error to a note? That way people the error message itself is short and to the point, while the extra context still available to the user.

error: linker `cc` not found
  |
  = note: No such file or directory (os error 2)

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

[fschutt]

@estebank See #47052

[fschutt]

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:

error: could not find -lsomethingsomething

.. to tell you that a certain library is not installed. Which could be a bit more nicely formatted like could not find library "somethingsomething" in $PATH. I think in MSVC there are additional paths that can be set (via linker arguments), those should be printed, too.

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 cargo/.config).

I think getting the code section that caused the linking:

 --> deflate/build.rs:2:5
  |
2 |     println!("cargo:rustc-link-lib=asdfasdf");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |

... 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.

[retep998]

Both link.exe and gcc have parameters to add directories to search for libraries: /LIBPATH:C:\foo\bar for link.exe and -L/foo/bar for gcc. However they both search additional paths based on environment variables. This means that it is quite difficult for rustc to know all the directories that the linker is searching for a given library. Also PATH has absolutely no bearing when it comes to searching for libraries.

[fschutt]

@retep998 Oh, ok, sorry. But what (exact) environment variables do you mean - do you have any references or sources?

GCC has a -print-search-dirs option, which should, in theory at least, print all the folder where it searched for libraries.

[retep998]

@fschutt For example link.exe will look in LIB for additional library search directories. It will also add arbitrary parameters specified in LINK and _LINK_ which could specify additional library search directories among other parameters. https://docs.microsoft.com/en-us/cpp/build/reference/link-environment-variables

I don't know of any flag to ask link.exe to print out all the directories it searches.

Also keep in mind for gcc the directories it searches depends on the order of parameters. -L/foo/bar only applies to -lfoo directives specified after it.

[estebank]

Also keep in mind for gcc the directories it searches depends on the order of parameters. -L/foo/bar only applies to -lfoo directives specified after it.

@retep998 the advantage we have is that is is rustc that is calling the linker, so we can assure the order of the arguments/flags to be correct.

GCC has a -print-search-dirs option, which should, in theory at least, print all the folder where it searched for libraries.

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 link.exe.

[fschutt]

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.

[mcandre]

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 :/

[estebank]

Specific case we could also handle more gracefully:

error: linking with `C:\msys64\mingw64\bin\gcc.exe` failed: exit code: 1
  |
  = note: "C:\\msys64\\mingw64\\bin\\gcc.exe" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\msys64\\mingw64\\x86_64-w64-mingw32\\lib\\dllcrt2.o" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\msys64\\mingw64\\x86_64-w64-mingw32\\lib" "-L" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.10yym40hrkk60fld.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.11pecpngb6c09tbm.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.11wtqrxgr3s4ov3p.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.12ghoy67h40koqw0.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.12ovmk5s9gpmdqxh.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.17xppg7s4qx2oay3.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.19h3c893yr9lq4lg.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1aioe5s3mjfmcijk.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1bvys9b5laompazb.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1cfabbs38usal6uc.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1eupty4xsqt65l69.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1fa8z79xhzg59tjy.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1gcvg4b0jcfo2g3r.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1gr6jpyzh018liof.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1h4h9o8u19tb8taq.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1j0sthr01m0t0p66.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1loeia1abl1ncrrb.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1rrobblqlwm0eswt.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1srmcgeysj8mqz7f.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.1sxyodf0dh6s8fr.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.216ot1a90el4vsqt.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.259z9r0doa6p13ja.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.26f7j8thkx6ca848.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.2au8k5tywv0pwhvl.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.2dyhxakpd7pe4r2i.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.2k3navlzk7nu0var.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.2n4c240qn7dhreq.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.2nocuvuqp8811d57.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.32nuk6guu7trpvu8.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3a8uey96f8czo3y.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3axxuxtmce3cwsb.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3b02k6pfg5ybrg0m.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3fqdbqhg4iwet93x.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3gztn0rgv9ojtu40.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3hg2y89bxf918apt.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3hxuwzt3g2kbxtso.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3isp4zyge98gdj3o.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3itlasudtchyju7b.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3kzwkpa03h83f3tx.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3mpkjmqx5ho0b6bq.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3mwransn8gkx4y42.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3nb6mbyfcnpotx9w.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3s9v6dyll0whqnmb.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3tc37i6jpchn36v7.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3u0y853cauaej683.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3ugnuc6rt2c1ra1l.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3v430r1bdg7lbits.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3vs5vjxh9revqcs0.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3y7625ysoxn6or51.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.3z0al9k7hdf4ciex.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.43c0gaasvhmmfatf.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.49vdy5lkme4nlyih.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.49xoo1quo54uk4p0.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4adk1z64itthxuse.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4bjdsfdvztj69hd2.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4ema0tqt2gkazfjk.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4gjozm2yizyqfvku.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4h2lcampdiba4qmw.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4pr0eteglnm9vcdr.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4q1qv64aimf2zv74.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.51kohyqi2tptkszg.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.5bb9rqdpnmvljz4m.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.5cwhllrr8u9xf2t0.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.7xnb90q7l8lws4r.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.bj8quq3ibzji58u.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.dxb0oyenmb1e1pn.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.fn94duskpew6cjr.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.jlo2jrtx6aklwyg.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.jycumisnj13furb.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.kqpfjdekq5zx99x.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.lfqugv1ill1nauf.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.mvi9ekd7hsf8vk7.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.o23rvngxdtwt3dw.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.rz2z6cbsegga4xj.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.th35iixpt96qpqz.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.tukmv0c7u59fuhg.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.vug9fo78hwinszg.rcgu.o" "-o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.dll" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.13jybnuwtxuk0gmy.rcgu.o" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.4dizn1lqx1iitrp3.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps" "-L" "C:\\Users\\jasper\\.cargo\\registry\\src\\github.jparrowsec.cn-1ecc6299db9ec823\\winapi-x86_64-pc-windows-gnu-0.4.0\\lib" "-L" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libcdrs_con-943f2ff06774570b.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libcdrs_transform-32ce559fa8106ecb.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libcdrs-685c6f4349ff6c79.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libcdrs-9837fc72e2bfc612.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libuuid-1464d32ce6c7549f.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libtime-cbd53b6c833a080c.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\librand-016a7d6fdd7f93dd.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libr2d2-bf187d7614b95353.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libscheduled_thread_pool-b463adf965a4ec31.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libparking_lot-3d5c4f226384c651.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libparking_lot_core-719b7eb7e567a0ce.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libwinapi-d58e67ccfbdca0e1.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libsmallvec-ce915d4ae1fc9fcf.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\liblock_api-e4268f5db5cc955d.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libscopeguard-1e3937f3df9e247a.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\liblz4_compress-b3fb6b82de20213f.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libbyteorder-1889e7f61c7b8e10.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\liblog-39a8b9c3c6f79d99.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libcfg_if-5bc5725eeb91809d.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libsnap-32235058df2da79b.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\liblazy_static-e4db2369f50ab5ed.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libbyteorder-5973734557b5ae08.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libsyn-56a3e9b5c1d2d051.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libquote-dbf6c0275016ed4e.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libproc_macro2-a8292559a31f508b.rlib" "C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\libunicode_xid-6c634753621b18e1.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libproc_macro-2b7fef7b67ce54d0.rlib" "-Wl,--start-group" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-b856675eeb99d410.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-7d9318240b1ba43e.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libhashbrown-1ea2d9c4ec771682.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_alloc-d40a2a1378721a73.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libbacktrace-e7c77cc61316712f.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libbacktrace_sys-160c2ebb98665c54.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_demangle-bd6bce6239a05021.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-c933f93cd63b2ad0.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcfg_if-cabd342650cb5eba.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-14fea7a91cbd1d65.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-13f8aa678796468f.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_core-d5b2602ca33debca.rlib" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-d0a6bfc5adb4da72.rlib" "-Wl,--end-group" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-9bf35bb038f7db43.rlib" "-Wl,-Bdynamic" "-lwinapi_advapi32" "-lwinapi_cfgmgr32" "-lwinapi_credui" "-lwinapi_gdi32" "-lwinapi_kernel32" "-lwinapi_msimg32" "-lwinapi_opengl32" "-lwinapi_secur32" "-lwinapi_user32" "-lwinapi_winspool" "-ladvapi32" "-lws2_32" "-luserenv" "-Wl,-Bstatic" "-lgcc_eh" "-lpthread" "-shared" "-Wl,--out-implib,C:\\Users\\jasper\\CLionProjects\\cdrs_query\\target\\debug\\deps\\cdrs_query_proc-a9f994fa46a9363e.dll.lib" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\jasper\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Error: export ordinal too large: 72382
          collect2.exe: error: ld returned 1 exit status

[estebank]

CC #41151 #39044 #17346

[danakj]

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.

--error-format=short omits the lengthly command line, but also omits the error that occured in the sub-process, as it does not print any of its stderr. It only prints

error: linking with `../../third_party/llvm-build/Release+Asserts/bin/clang++` failed: exit status: 1

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: ld.lld: error: undefined symbol: base::rs_glue::NewRunLoopA()
          >>> referenced by mod.rs.cc:504 (gen/base/rs_glue/mod.rs.cc:504)
          >>>               base/mod.rs.o:(base$rs_glue$cxxbridge1$NewRunLoopA) in archive obj/base/libbase.a
          clang++: error: linker command failed with exit code 1 (use -v to see invocation)

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:

          clang++: error: linker command failed with exit code 1 (use -v to see invocation)

[danakj]

@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?

[jyn514]

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 error

it would be nice to print PATH like fschutt suggested, though.

Maybe include the folders that rust searched for the libraries (helpful for debugging $PATH issues)

this is interesting. rustc will do this today if you pass RUSTC_LOG=rustc_codegen_ssa::back::link -C link-arg=-Wl,--verbose. after my change in #119286 RUSTC_LOG will do nothing and you have to use -C link-arg=-Wl,--verbose --verbose instead. i am reconsidering whether rustc should just always show the linker stdout by default, not just stderr.

the other parts of this issue are tracked by #83436 and #109979.

[jyn514]

Maybe include the folders that rust searched for the libraries (helpful for debugging $PATH issues)

this is interesting. rustc will do this today if you pass RUSTC_LOG=rustc_codegen_ssa::back::link -C link-arg=-Wl,--verbose.

this ends up being very verbose, though - i wonder if rustc should suggest gcc -print-search-dirs instead. that might not include all the -B/-L flags, though? maybe it can include the relevant flags it would pass through to the linker in that suggestion?

[estebank]

@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 --verbose also imply those linker flags and suggest just --verbose in the output?