From my perspective, I saw WINE crashing with a CALL into seemingly nowhere. Then I realized the CALL on disk pointed directly to the IAT (which obviously makes no sense.) Finally I realized that the library probably shouldn't be linking to VirtualProtect, traced it to the entrypoint, and found an error message that made me aware of the existence of pseudo relocs.
There was a 0% chance the person who created this bug was ever going to figure it out, and I'm not even sure I could've figured out the build issue if I had access to the project files. There's plenty of minutiae when it comes to MinGW and MSys and a lot of people are not adequately prepared for what they are getting themselves into. I think (hope) the mess with exception handling is cleared up and everyone just uses SEH on Windows, but I bet there's still issues with licensing and winpthreads, and MSys and PTYs.
I'd be more than happy to try to submit PRs to help with this particular problem, though I'm not going to lie, I find the pseudo-reloc thing horrifying and would be afraid of somehow breaking some ridiculous edge case.
Actually, (upstream) Clang defaults to native TLS instead of emulated TLS. In MSYS2, Clang is overridden to use emulated TLS by deafult to interoperate better with GCC built code and libstdc++ though.
The toolchain I maintain, https://github.com/mstorsjo/llvm-mingw, defaults to native TLS throughout.
When linking to a function "func" in another DLL, the import library normally provides two symbols, "func" which is a thunk which allows it to be called from anywhere, and "__imp_func" which is the IAT entry (containing a full 64 bit address). If the caller called it via a dllimport marked declaration, it's using "__imp_func", otherwise it uses "func" and ends up jumping via a thunk.
In some cases, when mingw-w64 wants to override importing certain functions (by providing a statically linked version of it instead), the functions are marked "DATA" in the def file (which is used for generating the import libraries). Then the thunk is left out and only the "__imp_func" symbol is left. If you hit a situation where you didn't end up linking the intended replacement function, then it's possible to hit this situation where you autoimport something that only works if it's loaded close enough. (In hindsight, it might have been even better to comment out those functions entirely from the import libraries.)
If you do hit this issue again (or if you remember exactly how to reproduce it), then plese do file a bug somewhere so we can look into it.
But in general, mingw-w64 linked binaries, even including ones using the autoimport facility and runtime pseudo relocations, should work even if they are loaded far apart from each other.