-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Rust 1.79+ stdlib is unusable with MSVC when creating static libraries #129020
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
cc @ChrisDenton |
Using |
@ChrisDenton The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here: https://www.amyspark.me/blog/posts/2024/01/10/stripping-rust-libraries.html |
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library. |
@dpaoliello Both: I'm using the Rust-produced static library through This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here: https://github.com/GNOME/librsvg/blob/main/rsvg/meson.build#L176-L244 |
@dpaoliello In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue. |
I am still struggling to understand why So the DLL is created here:
|
@ChrisDenton On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. That's what |
Sure but the E.g. as a test I have the following static lib (using // static.rs
#![crate_type = "staticlib"]
#[no_mangle]
pub extern "C" fn hello() {
println!("Hello world!");
}
#[no_mangle]
pub extern "C" fn number() -> u32 {
42
} Which I compile into a static lib using:
And I have the following
Which for simplicity I compile via rustc but I'm using an empty
This compiles and if
No std symbols are exported. |
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault. |
If I repeat the above using
I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC. |
All duplicate symbol errors for |
Sure, and then if I compile the static library with linker errors
|
There are also some technical details in msys2/MINGW-packages#21017 that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format. |
To get back to address
|
Filter in what way? |
When linking raw dylibs into a staticlib we could exclude the objects containing |
Use `ar_archive_writer` for writing COFF import libs on all backends This is mostly the same as the llvm backend but with the cranelift version copy/pasted in place of the LLVM library. Also updates ar_archive_writer to 0.4.0 which fixes rust-lang#129020
Use `ar_archive_writer` for writing COFF import libs on all backends This is mostly the same as the llvm backend but with the cranelift version copy/pasted in place of the LLVM library. Also updates ar_archive_writer to 0.4.0 which fixes rust-lang#129020 try-job: x86_64-msvc
…, r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts.
…r=<try> Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…r=<try> Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…, r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…, r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…, r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…, r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
…, r=jieyouxu Allow rust staticlib to work with MSVC's /WHOLEARCHIVE This fixes rust-lang#129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts. try-job: dist-i686-msvc
Required to fix rust-lang/rust#129020
Required to fix rust-lang/rust#129020
Uh oh!
There was an error while loading. Please reload this page.
Code
I tried to build librsvg using a simple
meson setup build -Ddefault_library=both
thenmeson compile -C build
.I expected to see this happen: linking success.
Instead, this happened: MSVC link returns LNK2005 and fails to
/WHOLEARCHIVE
the static library.Version it worked on
It most recently worked on: 1.77.2
Version with regression
rustc --version --verbose
:This is caused by both #121337 and #124019. When creating stdlibs, each MR causes the Rust compiler to add an export of
__NULL_IMPORT_DESCRIPTOR
; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from bcryptprimitives.dll. This error will not be found until one consumes the Rust-generated library.I am filing this report to consolidate the ones in rust-lang/cc-rs#1167 (comment) and mesonbuild/meson#13236 (comment).
Backtrace
Backtrace
@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged
The text was updated successfully, but these errors were encountered: