Errors when linking x64 OBJ files into ARM64EC programs

[StephanTLavavej]

When linking x64 OBJ files into ARM64EC programs, users are encountering errors like:

error LNK2001: unresolved external symbol __std_reverse_trivially_swappable_8 (EC Symbol)

Related to #2635 and #2740.

It appears that for this scenario, we need to provide separately compiled functions in the import lib (the ARM64 import lib?) that x64 object files could be expecting. These functions can perform plain vanilla swaps/reverses/etc., they don't need to be fancy initially. I am not exactly sure what their mangled names should look like, or what the entire fix will look like as a whole. We should be sure to actually validate the fix end-to-end manually (we now have the ability to create ARM64 VMs for internal testing).

Originally reported as DevCom-10219146 and Microsoft-internal VSO-1707080 / AB#1707080 .

[CaseyCarter]

We've had yet another customer step on this rake. <mutex>/xonce2.cpp manifest a similar issue:

Rebuild started...
1>------ Rebuild All started: Project: vmwaretestclient, Configuration: Release ARM64EC ------
1>add_person.cc
1>libprotobuf.lib(any.cc.obj) : error LNK2001: unresolved external symbol __imp___std_init_once_begin_initialize (EC Symbol)
1>libprotobuf.lib(map_field.cc.obj) : error LNK2001: unresolved external symbol __imp___std_init_once_begin_initialize (EC Symbol)

the ARM64EC import library needs to provide these symbols.

In the long term, I think we need to do a full audit of the STL to ensure that ARM64EC is everywhere ABI-compatible with the X64 library instead of the ARM64 library.

[driver1998]

I hit something similar when I try to link x64 static boost into an ARM64EC project, see rime/weasel#836. (Or I can somehow build boost as ARM64EC?)

Right now I use an ARM64X redirection DLL and points to separate x64 and ARM64 DLLs.