Quote:
Originally Posted by jpsdr
Stupid question i have to ask : When building, you have added the following option :
/Zc:threadSafeInit-
(In C/C++ -> "Command line").
This is necessary to have a Windows XP working build, selecting the toolset is not enough.
|
I did
not explicitly add that option. Nonetheless, in my test, the resulting binaries
do work on my Windows XP VM now.
Problem was definitely caused by the Manifest, but I still have
no idea what exactly in the Manifest generated by the Intel C++ compiler caused Windows XP to reject the binary.
[EDIT]
Quote:
Thread-safe static local variables use thread-local storage (TLS) internally to provide efficient execution when the static has already been initialized. The implementation of this feature relies on Windows operating system support functions in Windows Vista and later operating systems. Windows XP, Windows Server 2003, and older operating systems do not have this support, so they do not get the efficiency advantage. These operating systems also have a lower limit on the number of TLS sections that can be loaded. Exceeding the TLS section limit can cause a crash. If this is a problem in your code, especially in code that must run on older operating systems, use /Zc:threadSafeInit- to disable the thread-safe initialization code. – https://docs.microsoft.com/de-de/cpp...?view=msvc-160
|
If I understand this correctly, then "Thread-safe Local Static Initialization" is
less efficient on Windows versions prior to Vista (i.e. Windows XP), but still supported.
Also, Windows XP apparently has a lower limit on the number of TLS sections. And, because "Thread-safe Local Static Initialization" makes uses of TLS internally (i.e. it draws from the TLS sections limit), there is a higher risk of exceeding the TLS section limit on Windows XP - when "Thread-safe Local Static Initialization" is enabled. That is why "/Zc:threadSafeInit-"
may be needed for some applications to avoid that problem on Windows XP.
But is it always good to
disable "Thread-safe Local Static Initialization"? It may break applications that expect correct C++11 behavior, I think