Replacing checked-in OBJ files with `/ALTERNATENAME` broke linker compatibility

[StephanTLavavej]

For supply chain security, #2381 replaced checked-in OBJ files (generated by an internal tool aliasobj) with the linker's /ALTERNATENAME option (which is strictly more reproducible, although not officially documented).

We had never done this before, and although I ensured that the mangled names were identical, I didn't consider all possible scenarios. In certain situations, using a third-party library compiled with an older MSVC toolset, and performing the final link with a newer MSVC toolset, can emit "unresolved external symbol" linker errors that look like:

[x86]
error LNK2001: unresolved external symbol __imp____std_init_once_begin_initialize@16
error LNK2001: unresolved external symbol __imp____std_init_once_complete@12

[x64, ARM, ARM64]
error LNK2019: unresolved external symbol __imp___std_init_once_begin_initialize
error LNK2019: unresolved external symbol __imp___std_init_once_complete

I apologize for breaking linker compatibility here. Due to the supply chain security impact (and the fact that the aliasobj tool is still not yet publicly available), we can't undo this change. There are a couple of options to resolve these errors:

1. Permanent fix: Rebuild the third-party library with VS 2022 17.2 or newer.
2. Build system workaround: Add the following linker options, depending on the target architecture:
   • For x86: /ALTERNATENAME:__imp____std_init_once_begin_initialize@16=__imp__InitOnceBeginInitialize@16 /ALTERNATENAME:__imp____std_init_once_complete@12=__imp__InitOnceComplete@12
   • For x64, ARM, and ARM64: /ALTERNATENAME:__imp___std_init_once_begin_initialize=__imp_InitOnceBeginInitialize /ALTERNATENAME:__imp___std_init_once_complete=__imp_InitOnceComplete

I've filed this issue so that the error messages are searchable. I can also answer further questions if you've encountered these errors (I may not see GitHub notifications, so you may need to get my attention in the STL's Discord server.)

Also tracked by DevCom-1684365 / internal VSO-1495049 / AB#1495049 .

[akoeplinger]

@StephanTLavavej we hit this and tried the #include <mutex> workaround but it did NOT work.

Adding the linker options worked fine though 😄 In our case we used the pragmas like you do here:

STL/stl/src/xonce2.cpp

Lines 33 to 43 in dd5be88

	#if defined(_M_ARM64EC) || defined(_M_HYBRID)
	// <mutex> uses the forwarder fallbacks for ARM64EC and CHPE.
	#elif defined(_M_IX86)
	#pragma comment(linker, "/ALTERNATENAME:__imp____std_init_once_begin_initialize@16=__imp__InitOnceBeginInitialize@16")
	#pragma comment(linker, "/ALTERNATENAME:__imp____std_init_once_complete@12=__imp__InitOnceComplete@12")
	#elif defined(_M_X64) || defined(_M_ARM) || defined(_M_ARM64)
	#pragma comment(linker, "/ALTERNATENAME:__imp___std_init_once_begin_initialize=__imp_InitOnceBeginInitialize")
	#pragma comment(linker, "/ALTERNATENAME:__imp___std_init_once_complete=__imp_InitOnceComplete")
	#else // ^^^ known architecture / unknown architecture vvv
	#error Unknown architecture
	#endif // ^^^ unknown architecture ^^^

[akoeplinger]

ah and one difference I just noticed: we're building for x64 but still got the error LNK2001: unresolved external symbol __imp___std_init_once_begin_initialize, not the LNK2019 error code

[StephanTLavavej]

Thanks, I've updated the workaround list. I'm not sure what the difference is between the LNK2001 and LNK2019 numbers - thanks again for reporting what you observed.

[walbourn]

We have reports of this with our static library C++ built with VS 2019 being used with VS 2022 17.2 per forward compatibility, but none of our samples, regression validations, or tests broke.

Turns out the samples all built utility code that itself used <future> which in turn pulls in init once. Since the utility code was built with the current toolset, it pulls in __std_init_once_link_alternate_names_and_abort and then the otherwise breaking static C++ library finds it's symbols there without having to use the explicit /linker workaround above.

Therefore, another workaround is: "Use more of the C++ features in your code." :)

[StephanTLavavej]

We'll look into ways to fully fix this, as many customers are encountering this break.