OpenMathLib
Static linking and "DllMain"
Back in 2016, when I tried to fix the static linking issue of OpenBLAS (#813), I did not make any changes to the DllMain function, because as a newcomer, I was not sure how DllMain was being used in the project.
Recently, when I tried to use OpenBLAS together with the VC-LTL library to make my program run on Win7/XP, I encountered this:
error LNK2005: DllMain already defined in openblas.lib(memory.obj)
I've noticed that similar issues have appeared many times both on the web and in this repo. As I read this part of the code again, an idea I had back then came to me once more: when building as static library, should we give DllMain another name, such as StaticLibMain (as we all know, it is not preferred to have a DllMain symbol in a static library)? In this way, it wouldn't affect the TLS callback logic at all, and the linking problem can be avoided.
I am not familiar with the intricacies of the DllMain issue, but I would like to note that the shared library is generated from the static one, which might complicate your plan. Also, the DllMain function is used as well in the older, non-TLS implementation in the second half of memory.c - again I am not familiar enough with Windows to be sure that the semantics would be the same.
Looking at the gperftools source (now at https://github.com/gperftools/gperftools/blob/master/src/windows/port.cc ) that is quoted as the "inspiration" for the current code in memory.c, it looks to me as if the "DllMain" function is mainly/only a kludge for (older ?) MinGW compilers, and section pragmas would be the preferred alternative for MSVC. The source of a patch for the MinGW winpthreads implementation I found at https://sourceforge.net/p/mingw-w64/mailman/message/57625307/ finally seems to suggest that an equivalent functionality to the MSVC pragmas can be achieved by declarations like WINPTHREADS_ATTRIBUTE(WINPTHREADS_SECTION(".CRT$XLF") (but I have not checked how much of that is strictly internal to the MinGW source)
I have just noticed the non-TLS branch, and agrees that the current shared/static building procedure is somewhat unusual.
I also find some code that cannot be compiled with the latest MSVC (function param definition is redundant):
static const PIMAGE_TLS_CALLBACK dll_callback(HINSTANCE h, DWORD ul_reason_for_call, PVOID pv) = DllMain;
Those surely require further investigation and refactoring, which takes time.
For a quick fix, naively changing DllMain to StaticLibMain indeed solved my problem. I prefer doing this in vcpkg with vcpkg install openblas:x64-windows-static --editable, vcpkg's way seems to be better than the original CMake scripts.