Hi David,
Hi all,
Sorry for the delayed response, I’ve now had time to do a little bit of digging to understand what’s needed here.
Thank you very much, this is super helpful. 1. Support building GNUstep with MSVC
To clarify:This is proposing building GNUstep with the MSVC C++ ABI. This is now well supported by clang (Chrome uses it on Windows, for example). I had assumed that MinGW used it with the clang toolchains but apparently it doesn’t.
Yes exactly, thank you for the clarification.
- Dependencies: all dependencies would have to be built using MSVC as well. I did a quick search and this seems to be possible e.g. for libxml2, libxslt, libffi, and ICU, although some of the build instructions to do so seem pretty involved (esp. for ICU). In contrast to MinGW where these dependencies can simply be installed via Pacman, I don’t think there are pre-built packages of these dependencies built with MSVC, so this adds a significant hurdle to building GNUstep as a whole.
MSVC or Clang with the MSVC ABI. If they are available as NuGet packages, then this is easy (ICU is, for example: https://www.nuget.org/packages/icu4c.v140/), just install it with NuGet and point the GNUstep build system at it.
That’s great, thanks for the pointer! I looks like NuGet actually has all of the dependencies listed above. Some of them are pretty old (e.g. the newest libxml2 is from 2013), but I guess that may be ok.
- Build system / Autoconf: I don’t think we’d be able to use Autoconf and Make, so we’d have to look into supporting e.g. CMake, which is probably a significant undertaking.
I’m not 100% sure that this is the case. Clang can target the MSVC ABI when invoked with either the gcc- or cl.exe-compatible driver, so you can still use clang.exe (not clang-cl.exe) to drive the build. I have no idea how well autoconf in bash on Windows without MinGW though.
Yeah good point. I did manage to build Make for the MSVC ABI using the pre-built Clang release from the LLVM website, which defaults to the x86_64-pc-windows-msvc target. Building Base failed expectedly due to missing pthreads, but maybe this is still a good starting point for option 1. - Windows toolchain support in GNUstep sources: no idea what would be needed here, but I assume that some code relying on MinGW toolchain headers/libraries would need to be updated to use Windows APIs.
This may be non-trivial, though the Min in MinGW may help here: it largely just provides its own headers for Windows DLLs. I think we’re using Windows APIs for a bunch of things already. I believe that we use a pthreads compatibility layer on Windows, so these things would need to be modified to use the native Windows calls. If no one cares about Windows XP anymore, we could probably get some nice improvements by using SlimRW locks for NSLock.
Yeah replacing pthreads would probably be a bit of work. I just found pthreads-win32 ( http://www.sourceware.org/pthreads-win32/, also available via NuGet), which may be a good shortcut at least for a proof of concept and to see what else is missing.
2. Support MinGW-style exception handling in libobjc2
I don’t have any idea how involved this would be to support in libobjc2, but using GNUstep in a MinGW environment is how it worked in the past on Windows (with GCC), and so this would probably be what most users would expect to work with Clang as well. (As a bonus it would be nice if libobjc2 could support being built from a MinGW shell, so that everything can be built in the same environment.)
There are two bits here, supporting it in the runtime and supporting it in the compiler. I believe that both are actually fairly easy. It appears that MinGW comes with an adaptor that translates from SEH-style exceptions to MinGW-style exceptions, so we just need to build the Itanium version and a tiny wrapper function that calls _GCC_specific_handler and passes it the GNUstep runtime’s personality function.The clang changes are probably of a similar size.
Thanks, I’ll try to take a stab at the required changes you sent me, which at least on the surface seem pretty straightforward. I’ll keep you posted.
I suspect the hardest part of Option 2 will also be the build system, because the runtime will need to depend on MinGW and I’ve never built anything with MinGW before...
After installing MSYS2 and the necessary toolchain bits using Pacman (which should be mingw-w64-$(Arch)-cmake, mingw-w64-$(Arch)-clang, and mingw-w64-$(Arch)-lld), I’m hoping it will just require replacing some Win32 checks in CMakeLists with MSVC or checking explicitly for "MINGW", but we’ll see...
Thanks again, Frederik
|