I am aware that there are issues with static linking and multiple initializations, but sometimes it is necessary to use static linking and produce standalone executable -- there are completely legit scenarios where static linking does not cause any problems.
I am hereby voicing my strongest possible dislike for this decision, and I sincerely hope responsible persons for that decision will reconsider and reverse the decision -- even shipping the library as a separate download is better than not having an option to produce fully standalone executable anymore.
In the 12.x Release notes, it's noted that the Openmp static lib might be removed in the future releases. it is why that it is removed in this 13.0 release.
It does cause a lot of issues when the app uses MKL libs and also contains code with OpenMP. If the MKL lib is older or the compiler is older, there is imcompatible issue.
The decision on removing it is a cautious one.
Well, we may ask to add the file back, but I'm not sure if it will be. Let's see.
The dynamic Intel OpenMP library may also call upon additional dynamic libraries, to what extent do you want the static libraries (and from whom)?
There was a post on stackoverflow where a person got around this by making self extracting archive (inclusive of the DLLs) and ran the archive as opposed to the included application. That is somewhat of a kludge, but it may work for you.
An alternative might be to package the DLL as a resource, then at program start, copy the resource to a temporary file then use LoadLibrary or LoadLibraryEx to load it. Alternatively there is MemoryModule (https://github.com/fancycode/MemoryModule) that can be used to directly load the DLL from memory.