Should raw-dylibs defined in windows-targets use import_name_type = "undecorated"?

[glandium]

Summary

In a complex multi-language project, one may end up using both windows-target and the system libraries directly (that's the case of Firefox). When enabling windows-targets's support for raw-dylib, linking fails when using LLVM's lld-link (I haven't tried link.exe, it might actually work, but the result is probably suboptimal too). The cause for the link failure is possibly a bug in lld-link, but it is a manifestation of the fact that the fake import lib that rust creates with raw-dylib does not agree with the real system import lib, wrt symbol names: on 32-bits windows, the system import lib use the __imp__sym@n form, while the raw-dylib uses the __imp_sym form because of import_name_type = "undecorated".

See llvm/llvm-project#107371 (comment) for more details.

Removing import_name_type = "undecorated" solves the problem.

Crate manifest

No response

Crate code

No response

[glandium]

I guess the discussion on the LLVM side points to the problem being on the rust side of raw-dylib.

[ChrisDenton]

Hm, do you know if older versions of Rust worked? I suspect this might be a rustc issue.

Looking at a Windows import library (Synchronization.lib because it's small), I see WakeByAddressSingle import defined as:

  Version      : 0
  Machine      : 14C (x86)
  TimeDateStamp: FFFFFFFF
  SizeOfData   : 00000038
  DLL name     : api-ms-win-core-synch-l1-2-0.dll
  Symbol name  : _WakeByAddressSingle@4
  Type         : code
  Name type    : undecorate
  Hint         : 59
  Name         : WakeByAddressSingle

And the linker members include:

6.api-ms-win-core-synch-l1-2-0.dll    _WakeByAddressSingle@4
6.api-ms-win-core-synch-l1-2-0.dll    __imp__WakeByAddressSingle@4

So the name type should be undecorate but the symbol it self should still be decorated. Not sure what's going wrong there.

I'm a bit puzzled why removing import_name_type = "undecorated" works because I'd naively expect that to try importing the decorated name from a DLL, which shouldn't be found. Unless it happens that the native lib takes precedence.

[kennykerr]

@dpaoliello thoughts?

[kennykerr]

Anyone know how we might add this...

windows-rs/.github/workflows/raw_dylib.yml

Lines 12 to 13 in ff6f56d

	env:
	RUSTFLAGS: --cfg windows_raw_dylib

...to a yml strategy/matrix so I can more easily run raw-dylib tests across the board? Happy to expand test coverage if there's a gap here.

[ChrisDenton]

I did check with 1.71 and it has the same behaviour.

[kennykerr]

#3287 passed meaning we have the same testing for raw-dylib as non raw-dylib.

[kennykerr]

Happy to test rust-lld / lld-link if someone can point me to how that is done.

I see its enabled by default on Linux but not Windows. Anyone know why?

https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html

[ChrisDenton]

There have been compatibility issues in the past. I'm not exactly sure where we are at now but it seems rust-lang/rust#111480 is still open (though might just be that nobody has tested it recently).

[ChrisDenton]

Happy to test rust-lld / lld-link if someone can point me to how that is done.

You can put this in config.toml:

[target.x86_64-pc-windows-msvc]
linker = "rust-lld"

Or maybe use RUSTFLAGS with -C linker=rust-lld

[kennykerr]

Thanks, I've tested this and it seems to work fine.

[dpaoliello]

Seems like it's the same issue as rust-lang/rust#124958

Essentially, we should be setting symbol_name to the decorated name when creating the COFFShortExport, that way the import has both the decorated and undecorated name and should match the real import library.