-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rust 1.79+ stdlib is unusable with MSVC when creating static libraries #129020
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
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: