Mingw build fix for lto #4446
Mingw build fix for lto #4446
Conversation
eustas
left a comment
There was a problem hiding this comment.
IMHO, it would be better to fail rather than disable. It is easy to miss warning message.
Let's mention in message what extra flags are required for build and make it FATAL.
|
Learning from #4445 (comment). I added a check to determine if Clang and LTO are used, then making if |
This is not acceptable, because it would break everything outside of msys2, such as llvm-mingw. The real issue here is that gcc/libstdc++ in msys2 uses emutls, while LLVM currently cannot correctly handle emutls during LTO code generation. Newer versions of gcc/libstdc++ have already implemented native tls, but msys2 has not switched to native tls yet, since that would completely change the ABI. The correct approach is to detect whether the compiler uses native tls or emutls. Of course, this may be difficult to achieve. Given the current state of the mingw ecosystem, as a fallback it would be acceptable to simply detect the C++ STL implementation, since at least for libc++ there is no problem whether emutls or native tls is used. |
|
TIL, well that's annoying, I didn't know the MinGW ecosystem was so fractured, with many small crucial details between toolchains/versions. Unfortunately, I don't have the time to invest in fixing this since college classes have started for me. 😔 Does msys2 plan to fully switch native tls anytime soon? I really like using msys2, I'm curious about its future. @eustas what would be the best way to approach this problem? |
I'm not sure. Because this would change the ABI, and they'd need to rebuild everything for that. I recommend using clang64 and clangarm64, as they already uses native tls.
see https://www.msys2.org/docs/environments I recommend to detect the STL implementation used by the compiler via |
Fixes #4445, although it doesn't really address the sjpeg issue. Also, I'm not sure if this happens outside of Windows, so the WIN32 check might be unnecessary.