-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
linker: Allow MSVC to use import libraries following the Meson/MinGW convention #123436
Conversation
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 (
|
Sorry for the offtpic but I'm curious whether there weren't compatibility issues regarding Meson decision. That said, making dylibs consistent with ribs and static libs sounds like a good idea. |
typo:
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:
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 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 Similar to CMake and Meson, this needs to be handled in pkg-config-rs, and I have filed an issue about it. |
@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 |
r? @wesleywiser sorry, not the best person to review this |
@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. Some of the issues on top of my head:
File format is not the problem here but since
Unfortunately there are still many vendors providing MSVCRT toolchain as the default one, especially when cross-compiling.
OFC, we've been telling it at MSYS2 for years, it's also mentioned at MSYS2 webpage.
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.
Oh, I didn't know about it yet. Regarding Meson's FAQ
Both ld.bfd and LLD search for
Meson is free to support it (and workaround eventual issues) but this is not officially supported by GNU nor LLVM mingw-w64 based toolchains. |
I have a general concern about turning 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.
What system directories we can lose when replacing linker search with rustc search on windows-(msvc,gnu) targetes? |
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. |
@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.
We build 100 projects, most of which used to be built with Autotools/MinGW and have been slowly ported over to Meson.
The point is that |
It gets worse, as I understand it, Rust is also converting absolute paths into |
This comment was marked as resolved.
This comment was marked as resolved.
33da95a
to
df739a4
Compare
@petrochenkov If I understand you correctly, by Rebase pushed to address bors's detection too. |
This comment has been minimized.
This comment has been minimized.
df739a4
to
8cdf1ee
Compare
This comment has been minimized.
This comment has been minimized.
c44e94f
to
4d3b7e8
Compare
This comment has been minimized.
This comment has been minimized.
@bors r+ |
…-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`
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Doesn't look like an error in the PR, was that a race condition? |
That looks like a problem we've been having with CI lately. GitHub are looking into it. @bors retry |
…-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`
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
…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
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`
Hi all,
This PR implements support for
MsvcLinker
to use import libraries following Meson and the MinGW toolchain's naming convention. Meson follows thelibfoo.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 inlink_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