Add support for MinGW #190
Conversation
triplef
force-pushed
the
mingw
branch
8 times, most recently
from
c75e6df to
a41b3f0
Compare
|
Thanks, I hope to get to this at the weekend. |
|
Please can you add some instructions for how to build with MinGW? I have installed msys2 from choco and started the msys2 shell. I have run: These seem to have worked (running them again tells me that these things are already installed) but cmake is not in my path and neither is ninja. I can't test or work on this if I can't build it. So far my experience with MinGW makes me absolutely loath it. It's painfully slow, it doesn't let me use a modern terminal, and it is incredibly badly documented. |
|
Yeah the documentation is definitely lacking. The thing to know is that there are three subsystems with mostly separate binaries and installation paths: MSYS, mingw32, and mingw64. Since you installed the 64-bit packages they will only be available in the mingw64 environment. This page has a bit more info about this: You'll want to launch a mingw64 shell by running e.g.: If you use the MSYS2 installer you'll get Start menu launchers for the different shells. You can also add the different shells to Windows Terminal: (In the CI script, to avoid further branching I'm running CMake directly in the native CMD shell, but it picks up the right clang binary because I added the mingw64 bin directory to the path. ninja needs the bash shell tho to run some of the scripts, so it's easiest to just run everything from the MinGW shell.) Hope that helps! Thanks for giving it a try and please let me know if you need more info. |
|
At the moment, I have a small time window each weekend when I can spare the time to work on this. I still can't build it. Please can you provide me with step-by-step instructions for building with a freshly built LLVM? I now have the MinGW shell working and CMake runs. I need to invoke it with: I now get a load of link failures for things like A bit more poking and it turns out that CMake isn't passing a MinGW triple. I (try to) fix that by adding this to my CMake invocation: Now it fails to compile because it can't find I am trying to minimise my stress levels this year, after a particularly stressful 2020. I have now reached my limit in frustration with this for today and am going to step away from my computer. I'll have another try next weekend. If you can provide me with instructions that I can use for building and testing it with an LLVM that I have built from source, using the normal LLVM build process for Windows, then I will be able to make the required clang changes. |
|
Thank you very much for looking into this further, I am sorry this is not so straightforward. I’ll try to get you step-by-step instructions for building Clang main with the MinGW Clang patches by next weekend. I had previously built the MinGW Clang package directly (using makepkg), which applies these patches automatically, but for the purposes of working on Clang sources I can see you’ll want to use the normal LLVM build process instead. |
|
The libobjc2 library needs to be buildable under MSYS2. I would very much like to get clang working WITHOUT, I REPEAT WITHOUT using Visual Studio or any MS tools in any way, shape, or form. |
I really hate to keep emphasizing this! |
Then please don't. You are contributing nothing to the discussion other than demands for unpaid volunteers to do work that you think is important. |
David, My sincere apologies if you thought I was asking for that. I had simply thought that it was something that would be easy for you to do. I will create a branch and work on some changes which will make it possible to build on the MSYS2 command line. I may have questions for you along these lines. While working purely in Visual Studio is a nice idea I would still like for it to be possible to build from the MSYS2 command line. I will let you know when the changes are ready for review. Yours... GC |
|
Greg, thanks for your offer to help with this. I just want to make sure we’re all on the same page here: were you taking about a libobjc2 or LLVM branch you want to work on? This libobjc2 branch The outstanding issue is the ObjC runtime support in Clang needing changes to work with MinGW. In order for David to be able to look into this, we need to figure out how to build LLVM with the MinGW patches in such a way that he can work on it. Last time I tried this I got an error "number of sections exceeded object file", but I’m planning to look into this further. |
|
So instead of trying to compile LLVM with the MinGW patches, I’ve tried to get the standard Clang to use the MinGW ABI and made a bit of progress here. First, one needs to make sure to use the "normal" Windows Ninja, not the one from MinGW as it will choke on Windows paths. If you installed LLVM and Ninja via Chocolatey just add their directories to your path in the MinGW shell: Then we tell CMake to use the The remaining problem I have is that the try_compile for typeinfo_test.cc is failing, so no C++ runtime is detected: I’m guessing we need to pass some additional options to try_compile() in the test_cxx function. I’m already passing the target and sysroot for the above test, but that doesn’t seem to be enough. Any idea? |
|
I got it working thanks to the help of the MinGW folks! @davidchisnall the following steps should allow you to build libobjc2 for MinGW using the standard Windows (non-MinGW) Clang, and thereby also enable you to use the normal LLVM/Clang build process for Windows in order to debug this further. I tested this with a clean MSYS2 installation.
This should result in the exact same build errors as we’re seeing here on the CI, and which I presume will require changes in Clang, i.e.: |
There was a problem hiding this comment.
I've pushed some changes that allow me to compile and link everything (with a one-line patch to clang):
--- a/clang/lib/CodeGen/CGException.cpp
+++ b/clang/lib/CodeGen/CGException.cpp
@@ -144,7 +144,8 @@ static const EHPersonality &getObjCPersonality(const TargetInfo &Target,
case ObjCRuntime::WatchOS:
return EHPersonality::NeXT_ObjC;
case ObjCRuntime::GNUstep:
- if (L.ObjCRuntime.getVersion() >= VersionTuple(1, 7))
+ if (!L.hasSEHExceptions() &&
+ (L.ObjCRuntime.getVersion() >= VersionTuple(1, 7)))
return EHPersonality::GNUstep_ObjC;
LLVM_FALLTHROUGH;
case ObjCRuntime::GCC:The exception tests are all failing; however. What do you use to debug things with MinGW? WinDBG doesn't seem to like MinGW .exes.
| @@ -7,6 +7,14 @@ | |||
| #include "class.h" | |||
| #include "objcxx_eh.h" | |||
|
|
|||
| #if defined(__SEH__) && !defined(__USING_SJLJ_EXCEPTIONS__) | |||
There was a problem hiding this comment.
The second of these is never defined.
| #if defined(__SEH__) && !defined(__USING_SJLJ_EXCEPTIONS__) | |
| #ifdef __SEH__ |
There was a problem hiding this comment.
I think I copied those lines from libcxxabi, but I’d be fine with removing that second check if we can’t come up with a reason for having it.
| @@ -584,6 +596,16 @@ BEGIN_PERSONALITY_FUNCTION(__gnustep_objcxx_personality_v0) | |||
| return CALL_PERSONALITY_FUNCTION(__gxx_personality_v0); | |||
| } | |||
|
|
|||
| #if defined(__SEH__) && !defined(__USING_SJLJ_EXCEPTIONS__) | |||
There was a problem hiding this comment.
| #if defined(__SEH__) && !defined(__USING_SJLJ_EXCEPTIONS__) | |
| #ifdef __SEH__ |
Nice!
Good question. Maybe @mstorsjo would know? |
|
I'm guessing GDB or lldb from MSYS2 should work. pacman -S gdb |
|
I've tried installing gdb in mingw, but it doesn't seem to be able to set breakpoints (even one on main). |
|
There's something odd with MinGW's bridging of the SEH and DWARF EH models that is breaking the code that tries to figure out the layout of the C++ exception structure. I've pushed changes that let me pass all of the tests except those related to C++ exception interop. It looks as if the |
|
Thinking a bit more about it, the right strategy for MinGW may be to simply punt all exception handling to the C++ runtime, as Apple does. |
|
I just saw that MSYS2 added a new "CLANG64" environment that is using an LLVM toolchain and libc++: Maybe that's more compatible with libobj2's EH integration. I'll give it a try. |
Enables building *NIX exception model with MinGW.
MinGW does not like the leading underscores.
All EH-related tests still fail.
The test personality function that attempts to understand the structure of the C++ exception is now correctly set up, though it is not yet called.
MinGW provides something that is almost the same as the Itanium ABI, but with subtle differences. Fix the structure layouts to account for this. Disable the C++ exception structure layout check with MinGW - it is currently broken and causes *all* exceptions to break. Disabling it just causes C++ exceptions to crash the program, rather than all exceptions.
triplef
force-pushed
the
mingw
branch
4 times, most recently
from
e5023e0 to
63c81f5
Compare
|
I tried using the MSYS2 CLANG64 environment, which uses clang and libc++ by default, but it’s failing with the following linker errors. Any ideas? |
|
Closing this as basic MinGW support was added in #254. |
These are some first steps to add support for MinGW, which was outlined by David as follows:
These patches do 1–3 above, including adding MinGW to CI using MSYS2 and the latest official Clang 11 from MSYS2 packages. This allows building the DLL in an MinGW environment, although building the tests currently expectantly fails on CI with the following errors (other tests involving exceptions fail with the same linker errors minus the vtable one):
I’m unsure about the vtable issue, but I think fixing the other missing symbols requires patching Clang. I’m basically just running blind here as I have no knowledge of Clang internals, but I tried the following patch based on David’s patches sent on the mailing list, replacing
EHPersonality::MSVC_CxxFrameHandler3withEHPersonality::GNU_ObjC_SEH.This fixes the
objc_begin_catch/objc_end_catcherrors, but notobjc_exception_throwand adds some new errors involving the standard library:Note that the above is using libstdc++. I’m not sure if that’s what we want to use here – I also tried using libc++, which required some patching for the typeinfo test to work, but this resulted in the following errors linking the DLL:
I’d very much appreciate your further input @davidchisnall.