MSVC: cannot link multiple staticlibs from the same workspace because of IMAGE_COMDAT_SELECT_NODUPLICATES

[amyspark]

I tried: linking the GStreamer Rust plugins gstaws and gstrswebrtc, both built statically.

I expected to see this happen: linking success

Instead, this happened: some 5k lines of function clashes from shared dependencies e.g.:

libgstrswebrtc.a(gstrswebrtc.h2-9527afd107b48849.h2.4898c1e7831a741c-cgu.0.rcgu.o.rcgu.o) : error LNK2005: ya se definió _ZN102_$LT$core..iter..adapters..map..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$4fold17h30be9aebf26ab811E en libgstaws.a(gstaws.h2-9527afd107b48849.h2.4898c1e7831a741c-cgu.0.rcgu.o.rcgu.o)
libgstrswebrtc.a(gstrswebrtc.h2-9527afd107b48849.h2.4898c1e7831a741c-cgu.0.rcgu.o.rcgu.o) : error LNK2005: ya se definió _ZN111_$LT$core..iter..adapters..zip..Zip$LT$A$C$B$GT$$u20$as$u20$core..iter..adapters..zip..ZipImpl$LT$A$C$B$GT$$GT$3new17h21a4a1e578e1b030E en libgstaws.a(gstaws.h2-9527afd107b48849.h2.4898c1e7831a741c-cgu.0.rcgu.o.rcgu.o)

I believe this is caused by LLVM assuming IMAGE_COMDAT_SELECT_NODUPLICATES for all function COMDATS, which is too restrictive for MSVC: https://github.com/llvm/llvm-project/blob/llvmorg-20.1.5/llvm/lib/Transforms/Utils/Instrumentation.cpp#L102-L107.

This should perhaps be changed to IMAGE_COMDAT_SELECT_EXACT_MATCH on the Rust side; I tried it locally, but I got an impossibly long panic stacktrace which I attach below.

Meta

rustc --version --verbose:

rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-pc-windows-msvc
release: 1.87.0
LLVM version: 20.1.1

Backtrace: rustc-ice-2025-07-14T01_44_18-10920.txt

[bjorn3]

Linking two rust staticlibs together doesn't really work well because of #104707. Is it possible to build a single staticlib containing both gstreamer plugins?

[amyspark]

IIRC #104707 isn't really fixable in PE-COFF because the format doesn't know about symbol visibility; however, gstrswebrtc.h2-9527afd107b48849.h2.4898c1e7831a741c-cgu.0.rcgu.o.rcgu.o and gstaws.h2-9527afd107b48849.h2.4898c1e7831a741c-cgu.0.rcgu.o.rcgu.o are the exact same file, so MSVC should be able to dedup them.

re: building a single staticlib, it's technically possible but every downstream developer would have to implement their custom solution to unpack, dedup, and then repack the .obj into a new archive. Even then it wouldn't save you from other dependencies that also shipped Rust staticlibs e.g. librsvg.

[bjorn3]

IIRC #104707 isn't really fixable in PE-COFF because the format doesn't know about symbol visibility

Partial linking and object file editing (to make the symbol names unique) are two potential solutions that should work with any object file format. They do come at a compile time and complexity cost though.

This should perhaps be changed to IMAGE_COMDAT_SELECT_EXACT_MATCH on the Rust side; I tried it locally, but I got an impossibly long panic stacktrace which I attach below.

That doesn't work for anything other than PE/COFF. Mach-O doesn't support COMDAT at all, while ELF only supports any and nodeduplicate according to the LLVM LangRef, both of which would mask miscompilations.

[amyspark]

Partial linking and object file editing (to make the symbol names unique) are two potential solutions that should work with any object file format

Only ld.bfd supports partial linking for PE-COFF, but I'm not sure how well it works. MSVC doesn't know about it at all. See https://maskray.me/blog/2022-11-21-relocatable-linking, I also wrote about my experience ages ago: https://www.amyspark.me/blog/posts/2024/01/10/stripping-rust-libraries.html

Mach-O doesn't support COMDAT at all

That's no issue, as it can do symbol deduplication via partial linking, but on old Apple ld64 _rust_eh_personality has be preserved on every .o (source) (I admit I haven't checked lately if that's been fixed).

ELF only supports any and nodeduplicate according to the LLVM LangRef

We don't have problems here, GCC and LLVM can already handle these. IIRC we only prelink Rust libraries to slim them down before distribution.

[bjorn3]

Only ld.bfd supports partial linking for PE-COFF, but I'm not sure how well it works. MSVC doesn't know about it at all. See https://maskray.me/blog/2022-11-21-relocatable-linking, I also wrote about my experience ages ago: https://www.amyspark.me/blog/posts/2024/01/10/stripping-rust-libraries.html

Writing a linker for COFF that only does partial linking should be possible. I didn't say it would be an easy solution, but it should be possible.

That's no issue, as it can do symbol deduplication via partial linking, but on old Apple ld64 _rust_eh_personality has be preserved on every .o (source) (I admit I haven't checked lately if that's been fixed).

I'm fairly certain rust_eh_personality has never been codegened in every object file. The only thing special about it is that unlike pretty much every other symbol nowadays it doesn't get mangled differently depending on the rustc version (LLVM hard codes the name of the personality function for determining what kind of unwind tables to generate).

We don't have problems here, GCC and LLVM can already handle these. IIRC we only prelink Rust libraries to slim them down before distribution.

I have definitively seen duplicate symbol issues on ELF.