title: "LNK2005 DLLMain already defined ..." conflict in Linker using MSVC
body: <p>I have a C++ project which up to now had no problems compiling and linking but due to a recent computer crash I had to re-install everything including Visual Studio and all my VCPKG packages. (I am using VS 2022 Preview, and was before.)</p>
  <p>My project uses many STATICALLY linked libraries including Intel's TBB and Armadillo (which depends on OPENBLAS, amongst other things). However, it should be noted that OPENBLAS and TBB both still require a DLL to be linked even if the project uses static linking.</p>
  <p>Now I am compiling the same project with the same Project Properties that worked before and am constantly getting the LNK2005 error stating that:</p>
  <p>DllMain already defined in openblas.lib(memory.c.obj)..... tbb_debug.lib(tbb_main.obj)</p>
  <p>If I switch the linking order all that happens is the error changes to</p>
  <p>DllMain already defined in tbb_debug.lib(tbb_main.obj).... openblas.lib(memory.c.obj)</p>
  <p>[Note: It is the same problem linking in Release and Debug configurations.]</p>
  <p>Now what I cannot figure is why this even happens. Surely it is normal for projects to depend on more than one imported DLL. And it is quite normal for DLLs to export their DllMain entry point function.</p>
  <p>With the PC crash I have been forced to upgrade everything to the absolute latest versions and I wonder if this has introduced the problem somewhere.</p>
  <p>Is this a bug in MSVC that considers two DllMain functions from two different DLLs as conflicting?</p>
  <p>If this is a real conflict, can someone explain to me how this does not happen more often to people building large projects using third party DLLs?</p>
  <p>I have tried everything including a fresh install of VCPKG but nothing helps.</p>
  <p>The only option I have found to get this to complete the linking is to use the /FORCE:MULTIPLE option, which I really do not like as it could be creating a flawed executable.</p>
  <p>Any advice here would really be appreciated.</p>