Hi David, > Am 29.12.2020 um 15:57 schrieb David Chisnall <gnus...@theravensnest.org>: > > 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/ > <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
