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
Nilstrieb
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 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
This allows for implementing looking up Meson and MinGW import libraries. See rust-lang#122455
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
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: