Re: Building GNUstep for Windows using Clang

[David Chisnall]

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.

> On 22 Dec 2020, at 11:39, Frederik Seiffert <frederik@algoriddim.com> wrote:
> 
> Hi David and all,
> 
>> Am 02.12.2020 um 20:20 schrieb David Chisnall <gnustep@theravensnest.org>:
>> 
>> I am not sure if there is a good way of fixing this other than to use a MSVC 
>> target triple.  C++ EH interop almost certainly won't work if MinGW is 
>> targeting the Itanium ABI for C++ and I really don't want to support the 
>> horrible 'let's try to layer Itanium-style unwinding on top of SEH, what's 
>> the worst that can happen?' approach that MinGW uses.
> 
> I’ve been thinking about this some more, and it seems like there are two 
> (non-exclusive) ways forward with this:
> 
> 
> 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.  

>   *I think* this would mean that we have to enable building GNUstep with a 
> native Windows toolchain, i.e. without MinGW (unless there‘s a way to use 
> MSVC in a MinGW environment, but even then the dependencies would also need 
> to be built with MSVC). This poses a couple of questions / challenges:

Exactly, though that toolchain could be clang + lld, rather than any part of 
MSVC.

> 
>   - 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.

>   - 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.

>   - 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.


> 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.

> I think both options are worth exploring and I’d appreciate anyone’s thoughts 
> on the above. Ultimately it seems that even if we get option 1 to work, 
> option 2 would be much more straightforward to users given the pre-built 
> dependencies provided by MSYS2 packages.

My guess is that Option 2 is about two hours of writing the code and then a day 
or two of figuring out why it doesn’t work.  Option 1 is probably not too much 
work for the majority of the code but is likely to be a huge amount of effort 
for the build system: the GNUstep build system really doesn’t like non-GNU 
environments.

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...

David