Visual C++, especially in its later versions, suffers from all sorts of little pitfalls related to setup and deployment
("manifest" files, WinSxS, uninstalled C runtime versions, etcetera).
Those 'little pitfalls', as you call them, are there to ensure version consistency when using dynamically linked libraries, to ensure end-users don't have to install multiple copies of the same library version and to ensure that compatible security updates can be patched into a library later. (It's the same deployment strategy used by Windows update and several Microsoft-authored libraries such as the VC++ runtimes, iirc.)
All of those are actually good things.
Ofcourse for all the versioning goodness to work correctly, you are required to follow Microsoft's deployment guidelines and create an installer that correctly deploys your dynamically linked libraries in the centralized side-by-side WinSxS repository with the correct manifests describing their contents. Blame C++ for not having a standardized ABI that contains this kind of data necessary for serious integrated installation / deployment strategies. Not Microsoft.
Yes, I am aware that I'm not doing things the Microsoft way. Thanks for your post clarifying that; but the "MinGW" part should be a dead giveaway on that point anyway.
I'm not touching WinSxS. It disgusts me. WinSxS is an exercise in remorse-driven development that happened twenty years too late for any good to result. COM objects were an answer to "DLL Hell." So were .NET DLLs. I don't need a third answer, especially one that hacks around the problem with spoofing and action-at-a-distance.
Besides that, I prefer having two systems of libraries with versioning and one without to having three systems of libraries with versioning. Static DLLs have their place. I don't necessarily care about "multiple copies of the same library version." Sometimes I care more about being certain which DLL actually get used. I'm thinking of situations where I might use static linking in a pure C++ project, but where I want to use a .NET caller, for example.
Yeah, I could wade into a minefield of manifests and such, and do things the Microsoft way, but sometimes shit just has to get done. And I do "blame Microsoft" for some of this. Sure, there's no C++ ABI; I would suggest C++ is a tool that can be used to build ABIs. It's a systems programming language. But Microsoft had every opportunity to give us a "standardized ABI," and instead they gave us three. Maybe that's just progress. But then, Microsoft had second thoughts about one of their ABIs, and quietly finagled it into working like the other two ABIs.
Perhaps the most amazing thing about WinSxS is how quietly this monumental change was foisted upon us. I look back with amazement at some of the people to whom I've had to explain WinSxS. You don't have to evangelize about WinSxS to me. I'm at least one step ahead of you.
People tell me I'm the worst developer on this board. Please spare me; apparently I'm doing so much of the real work out there that I was among the first victims of WinSxS out there. And the colleagues whom I rescued from days of pointless manifest-diddling with my stealthy use of MinGW thought I was pretty brilliant.