Hi David and all, > Am 02.12.2020 um 20:20 schrieb David Chisnall <gnus...@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 *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: - 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. - 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. - 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. 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.) 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. Frederik
