Rust can detect GNU/Meson style named libraries but the MSVC linker backend ignores them #122455
Labels
A-linkage
Area: linking into static, shared libraries and binaries
C-bug
Category: This is a bug.
O-windows
Operating system: Windows
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
amyspark
changed the title
Noratrieb
added
A-linkage
|
Any update on this issue? |
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 3, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 3, 2024
This allows for implementing looking up Meson and MinGW import libraries. See rust-lang#122455
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 3, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 18, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 18, 2024
This allows for implementing looking up Meson and MinGW import libraries. See rust-lang#122455
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 18, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 18, 2024
This allows for implementing looking up Meson and MinGW import libraries. See rust-lang#122455
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 18, 2024
gnomesysadmins
pushed a commit
to GNOME/librsvg
that referenced
this issue
Apr 18, 2024
Back when I implemented the mesonification of librsvg, I forced the installable target of rsvg-2 to be a shared library. This was because Meson and Rust, at link time, differ on the naming convention expected of static libraries: rust-lang/rust#122455 https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa I did not realise at the time that the fix merged in !938 (commit 73d7167) was not aware of this issue, and so it broke the Cerbero builds targeting Microsoft compilers. This commit works around the Rust bug by following the Linux convention for static libraries, and then using a custom target to rename the Rust-generated library if under MSVC. All targets that depend on librsvg_lib do so now unconditionally, given they must link at a time where the file outputs are settled. Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/957>
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 20, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 20, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 20, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Apr 20, 2024
|
@amyspark, I see you have done quite a bit of work here, thank you! Is there anything I can do to help move this forward? I can try to build this custom branch and test if it works? |
|
Apologies, I now see the relevant issue is already being worked on! |
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Sep 5, 2024
amyspark
added a commit
to amyspark/rust
that referenced
this issue
Sep 6, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
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
added a commit
to rust-lang-ci/rust
that referenced
this issue
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`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Sep 16, 2024
…nd-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`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
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
Hi all,
I'm coming from https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1495#note_2324261 to report an inconsistency in how Rust passes library names to Visual Studio's
LINK.EXE. In thegst-plugins-rsproject, which is driven through Meson, I expected all libraries to be found correctly. Instead, I get an error of library not found at linking time.This is caused by the following snippet of code.
rust/compiler/rustc_codegen_ssa/src/back/linker.rs
Lines 828 to 837 in 3cbb932
The above snippet hardcodes the
xxx.libconvention when passing import or static libraries' names. However, this is not consistent with Meson's import library naming policy, which is already handled correctly in a separate portion of the Rust compiler:rust/compiler/rustc_metadata/src/native_libs.rs
Lines 31 to 40 in 3cbb932
The result of the above is that Rust, under MSVC, will happily put together
staticlibsandrlibs, but will fail utterly when adylibis demanded under the present set of circumstances.This is the other half required to completely address the issue in gdesmott/system-deps#77 -- I tried working around this by inserting
static:+verbatimplus setting the correct file name, as shown in amyspark/system-deps@10b342e, but it returns an error:This is already known and was never addressed: #95575 (comment)
Meta
rustc --version --verbose:Backtrace of the big linker error
The text was updated successfully, but these errors were encountered: