Skip to content
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: Allow MSVC to use import libraries following the Meson/MinGW convention #123436

Conversation

amyspark
Copy link
Contributor

@amyspark amyspark commented Apr 3, 2024

Hi all,

This PR implements support for MsvcLinker to use import libraries following Meson and the MinGW toolchain's naming convention. Meson follows the libfoo.dll.a naming convention to disambiguate between static and import libraries.

This support already existed for static libraries (see #100101), but not for dynamic libraries. The latter case was added by duplicating the logic in native_libs::find_native_static_library, but a separate case was added in link_dylib_by_name for the Windows CRT libraries which must be handled by the linker itself.

See for prerequisites #129366, #126094, and #128370.

All feedback is appreciated!

Fixes #122455

cc @sdroege @nirbheek

@rustbot
Copy link
Collaborator

rustbot commented Apr 3, 2024

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 3, 2024
@mati865
Copy link
Contributor

mati865 commented Apr 4, 2024

Sorry for the offtpic but I'm curious whether there weren't compatibility issues regarding Meson decision.
Unlike import libraries and DLLs, static libraries are basically incompatible between MSVC and MinGW. So using the same extension for them is risky.

That said, making dylibs consistent with ribs and static libs sounds like a good idea.

@nirbheek
Copy link

nirbheek commented Apr 4, 2024

Meson follows the libfoo.dll.a naming convention

typo: libfoo.a naming convention for static libraries.

Sorry for the offtpic but I'm curious whether there weren't compatibility issues regarding Meson decision.
Unlike import libraries and DLLs, static libraries are basically incompatible between MSVC and MinGW. So using the same extension for them is risky.

This is not accurate, we wrote the above-linked Meson FAQ because it's a common misconception. I'll repeat and expand the relevant bits here for the benefit of everyone reading:

  1. MSVC and MinGW toolchains both use the ar format for static libraries (and also for import libraries, but that's a separate matter), so the file format is compatible.
  2. MSVC and MinGW have also been using UCRT for quite some time now. MSYS2 has a UCRT64 variant that is the recommended variant.
  3. You should not mix static libraries built with different CRTs, but that is true regardless of which toolchain you are using. You will get exactly the same problems if you link MSVC static libraries built with MSVCRT with MSVC static libraries built with UCRT.
    • In the current implementation, this configuration is considered user error, and outside of the purview of the linker.

In summation: there is no reason to treat MinGW-built and MSVC-built static libraries as incompatible. In fact, at GStreamer we have been linking them together for 5 years with no adverse effects, since everything is using UCRT.

FWIW, as of recently, CMake also accepts libfoo.a static libraries via pkg-config when building with an MSVC toolchain.

An important quality-of-life change for users there is to ignore static libraries presented by Strawberry Perl's pkg-config[1][2] (which is unconditionally added to PATH and must not be used as a MinGW distribution), since Strawberry Perl is included in PATH in Github CI images by default, and there is no way to turn it off.

Similar to CMake and Meson, this needs to be handled in pkg-config-rs, and I have filed an issue about it.

@petrochenkov petrochenkov self-assigned this Apr 4, 2024
@amyspark
Copy link
Contributor Author

amyspark commented Apr 4, 2024

typo: libfoo.a naming convention for static libraries.

@nirbheek I was thinking of the particular case of import libraries (libfoo.dll.a) for which I already experienced such a clash elsewhere: https://aomedia-review.googlesource.com/c/aom/+/173603

@compiler-errors
Copy link
Member

r? @wesleywiser

sorry, not the best person to review this

@mati865
Copy link
Contributor

mati865 commented Apr 9, 2024

@nirbheek at MSYS2 we've had many reports of broken builds when using static libraries made with MSVC in mingw-w64 based toolchains and we always referred to what I think was original MinGW (not mingw-w64) webpage or some mailing list message that said DLLs are the only supported interface between MSVC and MinGW.
Maintainer of mingw-w64 stuff at LLVM says the same thing: mstorsjo/llvm-mingw#305 (comment)
It's true UCRT fixed many of the issues but I doubt any mingw-w64 developer would claim static libraries to be fully compatible. I don't mean it doesn't work, it's just unsupported and shouldn't be considered as a bug if compatibly breaks.

Some of the issues on top of my head:

  • MSVCRT toolchains basically required __USE_MINGW_ANSI_STDIO to have working stdio but it's not compatible with MSVC (MSYS2 still enables it for all packages, even UCRT ones)
  • GCC (and IIRC Clang to match it) uses x87 for f64/double on 32-bit targets
  • Dwarf-2 debuginfo used by 32-bit toolchains is definitely not compatible with MSVC, IIRC SEH used by 64-bit toolchains is also somewhat different from MSVC
  • there used to be (maybe still is?) some discrepancy between MSVC and GCC/Clang at registers usage in edge cases, cannot recall the details after all those years, could be related to varargs
  • C and C++ libraries not distinguishable by the linker and accidental inclusion of any C++ library is a guaranteed broken build

MSVC and MinGW toolchains both use the ar format for static libraries (and also for import libraries, but that's a separate matter), so the file format is compatible.

File format is not the problem here but since lib<name>.a is typically associated with MinGW/mingw-w64 toolchains this might be confusing for users when mingw-w64 GCC/Clang created static library breaks their build, like infamous strawberry perl that you've mentioned.

MSVC and MinGW have also been using UCRT for quite some time now. MSYS2 has a UCRT64 variant that is the recommended variant.

Unfortunately there are still many vendors providing MSVCRT toolchain as the default one, especially when cross-compiling.

You should not mix static libraries built with different CRTs, but that is true regardless of which toolchain you are using.

OFC, we've been telling it at MSYS2 for years, it's also mentioned at MSYS2 webpage.

In summation: there is no reason to treat MinGW-built and MSVC-built static libraries as incompatible. In fact, at GStreamer we have been linking them together for 5 years with no adverse effects, since everything is using UCRT.

This is refreshing to hear things are getting better but I still worry those are either too simple libraries to exhibit incompatibility issues or was not tested deeply enough.

FWIW, as of recently, CMake also accepts libfoo.a static libraries via pkg-config when building with an MSVC toolchain.

Oh, I didn't know about it yet.


Regarding Meson's FAQ

Both Clang and GNU compilers can search for libfoo.a when specifying a library as -lfoo. This does not work for alternative naming schemes for static libraries such as libfoo.lib.

Both ld.bfd and LLD search for <name>.lib (notice missing lib) which is MSVC naming convention, but .dll.a and .a libs are higher priority.

Projects built with the MinGW compiler are fully compatible with MSVC as long as they use the same CRT (e.g. UCRT with MSYS2).

Meson is free to support it (and workaround eventual issues) but this is not officially supported by GNU nor LLVM mingw-w64 based toolchains.

@petrochenkov
Copy link
Contributor

I have a general concern about turning linker library_by_name invocations into linker /full/path/library_by_name invocations, where the library_by_name -> /full/path/library_by_name conversion is done by rustc.

In the first case, the search directories are determined by the linker and may include some system directories, specific to a distribution directory layout, or controlled by some default linker config, or something else outside of rustc's purview.
In the second case the search paths will only include directories inside rustc toolchain, or directories explicitly passed with -L options.

find_native_static_library is currently used when the library actually needs to be processed by rustc itself (not by linker), e.g. to pack it into a rlib.
In that case you don't have a choice but to use rustc's search directories without looking at the system (unless explicitly asked by user).
(Other 2 uses of find_native_static_library in linker.rs are for options that apparently don't support linker search by name at all.)

What system directories we can lose when replacing linker search with rustc search on windows-(msvc,gnu) targetes?

@petrochenkov
Copy link
Contributor

If we just fully switched to rustc-based library search everywhere, then I suspect we'd fail to find libc on like half of Unix-like systems.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 10, 2024
@nirbheek
Copy link

@mati865 Thanks for the detailed explanation of MinGW and MSVC compatibility. My point was primarily that the two are not "incompatible" as was stated, but that they are indeed compatible in many cases, and people have been using it for years.

You've given many more cases, such as C++ static libraries, where there is incompatibility even with static libraries produced by the same toolchain, which IMO supports the argument that this is not the linker's job. It's up to the user and the build system.

This is refreshing to hear things are getting better but I still worry those are either too simple libraries to exhibit incompatibility issues or was not tested deeply enough.

We build 100 projects, most of which used to be built with Autotools/MinGW and have been slowly ported over to Meson.

Regarding Meson's FAQ

Both Clang and GNU compilers can search for libfoo.a when specifying a library as -lfoo. This does not work for alternative naming schemes for static libraries such as libfoo.lib.
Both ld.bfd and LLD search for .lib (notice missing lib) which is MSVC naming convention, but .dll.a and .a libs are higher priority.

The point is that foo.lib is already an import library, so we can't use that because it causes a filename collision. One other option is libfoo.lib which is used in some places, but Clang and GNU compilers do not pick it up when specifying a library as -lfoo, so it had to be rejected.

@nirbheek
Copy link

I have a general concern about turning linker library_by_name invocations into linker /full/path/library_by_name invocations, where the library_by_name -> /full/path/library_by_name conversion is done by rustc.

It gets worse, as I understand it, Rust is also converting absolute paths into -Ldir/ -lfoo pairs first, and then applying this conversion to convert it back to an absolute path. This can be very wrong in cases where you're picking up libraries from multiple -L paths, or if there are multiple options and the user prefers one.

@bors

This comment was marked as resolved.

@amyspark amyspark force-pushed the allow-msvc-to-use-meson-and-mingw-import-libraries branch from 33da95a to df739a4 Compare April 18, 2024 00:50
@amyspark
Copy link
Contributor Author

What system directories we can lose when replacing linker search with rustc search on windows-(msvc,gnu) targetes?

@petrochenkov If I understand you correctly, by rustc search you mean resolving and baking in the libraries' path, right? I'd definitely prefer this approach, it'll make error logs noisier because of the command length, but it'll definitely tell us which files are going to be linked.

Rebase pushed to address bors's detection too.

@rust-log-analyzer

This comment has been minimized.

@amyspark amyspark force-pushed the allow-msvc-to-use-meson-and-mingw-import-libraries branch from df739a4 to 8cdf1ee Compare April 18, 2024 01:08
@rust-log-analyzer

This comment has been minimized.

@amyspark amyspark force-pushed the allow-msvc-to-use-meson-and-mingw-import-libraries branch 2 times, most recently from c44e94f to 4d3b7e8 Compare April 20, 2024 00:19
@rust-log-analyzer

This comment has been minimized.

@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Sep 15, 2024

📌 Commit 98481be has been approved by petrochenkov

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 15, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 15, 2024
…-mingw-import-libraries, r=petrochenkov

linker: Allow MSVC to use import libraries following the Meson/MinGW convention

Hi all,

This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries.

This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself.

See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370.

All feedback is appreciated!

Fixes rust-lang#122455

cc `@sdroege` `@nirbheek`
@bors
Copy link
Contributor

bors commented Sep 15, 2024

⌛ Testing commit 98481be with merge 65a1768...

@rust-log-analyzer
Copy link
Collaborator

The job dist-x86_64-msvc failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[2024-09-15T19:23:08Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:23:08Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Opt, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:23:08Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpAsYqpX#ctfe-stress-5@0.1.0" "--release" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:23:12Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:23:12Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpAsYqpX#ctfe-stress-5@0.1.0" "--release" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpAsYqpX\\incremental-state"
[2024-09-15T19:23:18Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrUnchanged), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:23:18Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpAsYqpX#ctfe-stress-5@0.1.0" "--release" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpAsYqpX\\incremental-state"
Executing benchmark diesel-1.4.8 (4/8)
Preparing diesel-1.4.8
[2024-09-15T19:23:19Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Check, scenario=None, patch=None, backend=Llvm, phase=dependencies
[2024-09-15T19:23:19Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Debug, scenario=None, patch=None, backend=Llvm, phase=dependencies
---
[2024-09-15T19:24:10Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:11Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Opt, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:11Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpdjyJsC#diesel@1.4.8" "--release" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:19Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:19Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpdjyJsC#diesel@1.4.8" "--release" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpdjyJsC\\incremental-state"
[2024-09-15T19:24:28Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrUnchanged), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:28Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpdjyJsC#diesel@1.4.8" "--release" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpdjyJsC\\incremental-state"
[2024-09-15T19:24:30Z DEBUG collector::compile::benchmark::patch] applying println to "C:\\a\\_temp\\msys64\\tmp\\.tmpdjyJsC"
[2024-09-15T19:24:30Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrPatched), patch=Some(Patch { index: 0, name: PatchName("println"), path: "0-println.patch" }), backend=Llvm, phase=benchmark
[2024-09-15T19:24:30Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrPatched), patch=Some(Patch { index: 0, name: PatchName("println"), path: "0-println.patch" }), backend=Llvm, phase=benchmark
[2024-09-15T19:24:30Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpdjyJsC#diesel@1.4.8" "--release" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpdjyJsC\\incremental-state"
Executing benchmark externs (5/8)
Preparing externs
[2024-09-15T19:24:33Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Check, scenario=None, patch=None, backend=Llvm, phase=dependencies
[2024-09-15T19:24:33Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Debug, scenario=None, patch=None, backend=Llvm, phase=dependencies
---
[2024-09-15T19:24:33Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:33Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Check, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:34Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpMgbEmw#externs@0.1.0" "--profile" "check" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:34Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Check, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:34Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpMgbEmw#externs@0.1.0" "--profile" "check" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpMgbEmw\\incremental-state"
[2024-09-15T19:24:34Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Check, scenario=Some(IncrUnchanged), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:34Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpMgbEmw#externs@0.1.0" "--profile" "check" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpMgbEmw\\incremental-state"
[2024-09-15T19:24:35Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:35Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Debug, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:35Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpYrx8cO#externs@0.1.0" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:35Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Debug, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
---
[2024-09-15T19:24:39Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:39Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Check, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:39Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpXfZMfy#match-stress@0.1.0" "--profile" "check" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:40Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Check, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:40Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpXfZMfy#match-stress@0.1.0" "--profile" "check" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpXfZMfy\\incremental-state"
[2024-09-15T19:24:42Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Check, scenario=Some(IncrUnchanged), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:42Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpXfZMfy#match-stress@0.1.0" "--profile" "check" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmpXfZMfy\\incremental-state"
[2024-09-15T19:24:42Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:42Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Debug, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:42Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpWN8TZ4#match-stress@0.1.0" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:44Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Debug, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
---
[2024-09-15T19:24:52Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:52Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Debug, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:52Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmp3JGXQK#token-stream-stress@0.0.0" "--bin" "token-stream-stress-bin" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:52Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Debug, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:52Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmp3JGXQK#token-stream-stress@0.0.0" "--bin" "token-stream-stress-bin" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmp3JGXQK\\incremental-state"
[2024-09-15T19:24:52Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Debug, scenario=Some(IncrUnchanged), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:52Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmp3JGXQK#token-stream-stress@0.0.0" "--bin" "token-stream-stress-bin" "--" "--wrap-rustc-with" "Eprintln" "-C" "incremental=C:\\a\\_temp\\msys64\\tmp\\.tmp3JGXQK\\incremental-state"
[2024-09-15T19:24:53Z DEBUG collector::compile::benchmark] Benchmark iteration 1/1
[2024-09-15T19:24:53Z INFO  collector::compile::execute] run_rustc with incremental=false, profile=Opt, scenario=Some(Full), patch=None, backend=Llvm, phase=benchmark
[2024-09-15T19:24:53Z DEBUG collector::compile::execute] "\\\\?\\C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "rustc" "--manifest-path" "Cargo.toml" "-p" "path+file:///C:/a/_temp/msys64/tmp/.tmpK7x2Nl#token-stream-stress@0.0.0" "--release" "--bin" "token-stream-stress-bin" "--" "--wrap-rustc-with" "Eprintln"
[2024-09-15T19:24:53Z INFO  collector::compile::execute] run_rustc with incremental=true, profile=Opt, scenario=Some(IncrFull), patch=None, backend=Llvm, phase=benchmark
---
   Compiling rustc_driver v0.0.0 (C:\a\rust\rust\compiler\rustc_driver)
[RUSTC-TIMING] rustc_driver test:false 4.680
error: linking with `link.exe` failed: exit code: 1104
  |
  = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\symbols.o" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\x86_64-pc-windows-msvc\\release\\deps\\rustc_main-82db4ad9c01ff9e2.rustc_main.496cc629f677ff80-cgu.0.rcgu.o" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\x86_64-pc-windows-msvc\\release\\deps\\rustc_driver-6464163a03940856.dll.lib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-da01fb5db34082e2.rlib" "psapi.lib" "shell32.lib" "ole32.lib" "uuid.lib" "advapi32.lib" "ws2_32.lib" "ntdll.lib" "kernel32.lib" "advapi32.lib" "ole32.lib" "oleaut32.lib" "advapi32.lib" "cfgmgr32.lib" "gdi32.lib" "kernel32.lib" "msimg32.lib" "opengl32.lib" "user32.lib" "winspool.lib" "bcrypt.lib" "advapi32.lib" "legacy_stdio_definitions.lib" "kernel32.lib" "kernel32.lib" "advapi32.lib" "ntdll.lib" "userenv.lib" "ws2_32.lib" "dbghelp.lib" "/defaultlib:libcmt" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\advapi32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-errorhandling-l1-1-3.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-file-fromapp-l1-1-0.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-handle-l1-1-0.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-ioring-l1-1-0.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-memory-l1-1-3.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-memory-l1-1-4.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-memory-l1-1-5.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-memory-l1-1-6.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-memory-l1-1-7.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-memory-l1-1-8.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-synch-l1-2-0.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-sysinfo-l1-2-0.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-sysinfo-l1-2-3.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-sysinfo-l1-2-4.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-sysinfo-l1-2-6.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-util-l1-1-1.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-core-wow64-l1-1-1.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\api-ms-win-security-base-l1-2-2.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\avrt.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\bcp47mrm.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\bcryptprimitives.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\clfsw32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\dbghelp.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\elscore.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\gdi32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\icu.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\imagehlp.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\kernel32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\ktmw32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\netapi32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\normaliz.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\ntdll.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\ntdllk.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\ole32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\oleacc.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\oleaut32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\psapi.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\rtworkq.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\txfw32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\user32.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\usp10.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\version.dll_imports_indirect.lib" "C:\\a\\_temp\\msys64\\tmp\\rustcij7JNn\\wofutil.dll_imports_indirect.lib" "/NXCOMPAT" "/LIBPATH:C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\atlmfc\\lib\\x64" "/LIBPATH:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\x86_64-pc-windows-msvc\\release\\build\\stacker-f3b3037c356402a6\\out" "/LIBPATH:C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\atlmfc\\lib\\x64" "/LIBPATH:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\x86_64-pc-windows-msvc\\release\\build\\psm-573b2b0ddf2f16a6\\out" "/LIBPATH:C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\atlmfc\\lib\\x64" "/LIBPATH:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\x86_64-pc-windows-msvc\\release\\build\\rustc_llvm-4c648559f228b11c\\out" "/LIBPATH:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\llvm\\lib" "/OUT:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage1-rustc\\x86_64-pc-windows-msvc\\release\\deps\\rustc_main-82db4ad9c01ff9e2.exe" "/OPT:REF,ICF" "/DEBUG" "/PDBALTPATH:%_PDB%" "/MANIFEST:EMBED" "/MANIFESTINPUT:C:\\a\\rust\\rust\\compiler\\rustc\\Windows Manifest.xml" "/WX"
  = note: LINK : fatal error LNK1104: cannot open file 'C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-rustc\x86_64-pc-windows-msvc\release\deps\rustc_main-82db4ad9c01ff9e2.exe'␍

[RUSTC-TIMING] rustc_main test:false 0.638
error: could not compile `rustc-main` (bin "rustc-main") due to 1 previous error
Build completed unsuccessfully in 0:07:27

@bors
Copy link
Contributor

bors commented Sep 15, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 15, 2024
@amyspark
Copy link
Contributor Author

Doesn't look like an error in the PR, was that a race condition?

@ChrisDenton
Copy link
Member

That looks like a problem we've been having with CI lately. GitHub are looking into it.

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 15, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 16, 2024
…-mingw-import-libraries, r=petrochenkov

linker: Allow MSVC to use import libraries following the Meson/MinGW convention

Hi all,

This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries.

This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself.

See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370.

All feedback is appreciated!

Fixes rust-lang#122455

cc `@sdroege` `@nirbheek`
@bors
Copy link
Contributor

bors commented Sep 16, 2024

⌛ Testing commit 98481be with merge 4b26c29...

@rust-log-analyzer
Copy link
Collaborator

The job i686-msvc failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
---- [ui] tests\ui\extern\issue-64655-extern-rust-must-allow-unwind.rs#fat3 stdout ----

error in revision `fat3`: test compilation failed although it shouldn't!
status: exit code: 0xc000001d
command: PATH="C:\a\rust\rust\build\i686-pc-windows-msvc\stage2\bin;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.41.34120\bin\HostX64\x86;C:\a\rust\rust\build\i686-pc-windows-msvc\stage0-bootstrap-tools\i686-pc-windows-msvc\release\deps;C:\a\rust\rust\build\i686-pc-windows-msvc\stage0\bin;C:\Program Files\PowerShell\7;C:\a\_temp\msys64\mingw32\bin;C:\a\_temp\msys64\usr\local\bin;C:\a\_temp\msys64\usr\bin;C:\a\_temp\msys64\usr\bin;C:\a\rust\rust\ninja;C:\a\rust\rust\sccache;C:\a\_temp\setup-msys2;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\Program Files (x86)\NSIS;C:\tools\zstd;C:\Program Files\Mercurial;C:\hostedtoolcache\windows\stack\3.1.1\x64;C:\cabal\bin;C:\ghcup\bin;C:\mingw64\bin;C:\Program Files\dotnet;C:\Program Files\MySQL\MySQL Server 8.0\bin;C:\Program Files\R\R-4.4.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\SeleniumWebDrivers\EdgeDriver;C:\SeleniumWebDrivers\ChromeDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.21.13\x64\bin;C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.13\x64;C:\hostedtoolcache\windows\Ruby\3.0.7\x64\bin;C:\Program Files\OpenSSL\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.422-5\x64\bin;C:\Program Files\ImageMagick-7.1.1-Q16-HDRI;C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\ProgramData\Chocolatey\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\dotnet;C:\Program Files\PowerShell\7;C:\Program Files\Microsoft\Web Platform Installer;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn;C:\Program Files\Microsoft SQL Server\150\Tools\Binn;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\WiX Toolset v3.14\bin;C:\Program Files\Microsoft SQL Server\130\DTS\Binn;C:\Program Files\Microsoft SQL Server\140\DTS\Binn;C:\Program Files\Microsoft SQL Server\150\DTS\Binn;C:\Program Files\Microsoft SQL Server\160\DTS\Binn;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.7\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI;C:\tools\php;C:\Program Files (x86)\sbt\bin;C:\Program Files\Amazon\AWSCLIV2;C:\Program Files\Amazon\SessionManagerPlugin\bin;C:\Program Files\Amazon\AWSSAMCLI\bin;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps;C:\a\_temp\msys64\usr\bin\site_perl;C:\a\_temp\msys64\usr\bin\vendor_perl;C:\a\_temp\msys64\usr\bin\core_perl" "C:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2\\bin\\rustc.exe" "C:\\a\\rust\\rust\\tests\\ui\\extern\\issue-64655-extern-rust-must-allow-unwind.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=C:\\Users\\runneradmin\\.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=C:\\a\\rust\\rust\\vendor" "--sysroot" "C:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\stage2" "--target=i686-pc-windows-msvc" "--cfg" "fat3" "--check-cfg" "cfg(FALSE,no0,no1,no2,no3,thin0,thin1,thin2,thin3,fat0,fat1,fat2,fat3)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-o" "C:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\ui\\extern\\issue-64655-extern-rust-must-allow-unwind.fat3\\a.exe" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=C:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\native\\rust-test-helpers" "-L" "C:\\a\\rust\\rust\\build\\i686-pc-windows-msvc\\test\\ui\\extern\\issue-64655-extern-rust-must-allow-unwind.fat3\\auxiliary" "-C" "opt-level=3" "-C" "lto=fat"
--- stderr -------------------------------
--- stderr -------------------------------
Assertion failed: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "Empty/Tombstone value shouldn't be inserted into map!", file C:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/DenseMap.h, line 667



failures:
failures:
    [ui] tests\ui\extern\issue-64655-extern-rust-must-allow-unwind.rs#fat3

test result: FAILED. 17261 passed; 1 failed; 354 ignored; 0 measured; 2 filtered out; finished in 521.70s

Some tests failed in compiletest suite=ui mode=ui host=i686-pc-windows-msvc target=i686-pc-windows-msvc
Build completed unsuccessfully in 0:48:09
make: *** [Makefile:106: ci-msvc-ps1] Error 1
  network time: Mon, 16 Sep 2024 07:12:55 GMT
##[error]Process completed with exit code 2.
Post job cleanup.
[command]"C:\Program Files\Git\bin\git.exe" version

@bors
Copy link
Contributor

bors commented Sep 16, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 16, 2024
@petrochenkov
Copy link
Contributor

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 16, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 16, 2024
…iaskrgr

Rollup of 4 pull requests

Successful merges:

 - rust-lang#123436 (linker: Allow MSVC to use import libraries following the Meson/MinGW convention)
 - rust-lang#130410 (Don't ICE when generating `Fn` shim for async closure with borrowck error)
 - rust-lang#130412 (Don't ICE when RPITIT captures more method args than trait definition)
 - rust-lang#130436 (Ignore reduce-fadd-unordered on SGX platform)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit eac6f07 into rust-lang:master Sep 16, 2024
6 of 7 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Sep 16, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 16, 2024
Rollup merge of rust-lang#123436 - amyspark:allow-msvc-to-use-meson-and-mingw-import-libraries, r=petrochenkov

linker: Allow MSVC to use import libraries following the Meson/MinGW convention

Hi all,

This PR implements support for `MsvcLinker` to use import libraries following Meson and the MinGW toolchain's naming convention. Meson [follows the `libfoo.dll.a` naming convention](https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa) to disambiguate between static and import libraries.

This support already existed for static libraries (see rust-lang#100101), but not for dynamic libraries. The latter case was added by duplicating the logic in `native_libs::find_native_static_library`, but a separate case was added in `link_dylib_by_name` for the Windows CRT libraries which must be handled by the linker itself.

See for prerequisites rust-lang#129366, rust-lang#126094, and rust-lang#128370.

All feedback is appreciated!

Fixes rust-lang#122455

cc `@sdroege` `@nirbheek`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rust can detect GNU/Meson style named libraries but the MSVC linker backend ignores them