Thanks David. I made some progress with this setup, although it does feel like we’re a bit off the beaten track here (again)...
To get libobjc linking with the MinGW clang toolchain using LLD I had to create an import library (.dll.a) as outlined on the MinGW website: http://www.mingw.org/wiki/CreateImportLibraries <http://www.mingw.org/wiki/CreateImportLibraries> Basically I ran "dumpbin /exports objc.dll" to get the list of symbols, used that to manually create a objc.def file, and then ran "dlltool -d objc.def -l objc.dll.a". One thing I noticed is that this doesn’t seem to include global variables (e.g. _objc_unexpected_exception), so these won’t be picked up by GNUstep configure and thus native exception support won’t work. In the end however I switched to using the llvm-mingw toolchain (https://github.com/mstorsjo/llvm-mingw <https://github.com/mstorsjo/llvm-mingw>), which defaults to LLD and directly picks up the objc.lib without the need for the import library (but also doesn’t seem allow linking global variables). I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t support the -r flag for incremental linking. With this and a couple more configure flags I got Base to start compiling, but I’m now stuck at the Additions subproject failing to link because it seems to be missing all the necessary linker flags: > clang -nostdlib -o ./obj/subproject.o > obj/Additions.obj/GSTypeEncoding.c.o ... > lld-link: error: <root>: undefined symbol: _mainCRTStartup > lld-link: error: undefined symbol: _malloc > lld-link: error: undefined symbol: __declspec(dllimport) _object_getClass > ... Does anyone with better knowledge of GNUstep make have an idea of why this might happen or how to debug this further? > There is a bug somewhere in the SEH support that I need to look for. I > suspect it is in clang - EH seems to fail with ARC and I think that it may be > to do with the ARC calls not being correctly emitted in the funclet. Dustin > is planning on looking at some of the Clang funclet issues. That’s good to know, thanks. By the way, is libcxxrt needed on Windows for ObjC++ EH on Windows? Seems like WinObjC is not using it. Thanks, Frederik > Am 25.02.2020 um 19:22 schrieb David Chisnall <gnus...@theravensnest.org>: > > Hi, > > > > On 25/02/2020 16:55, Frederik Seiffert wrote: >> Hi all, >> I’m trying to build GNUstep for Windows using Clang and the 2.0 runtime ABI >> in order to have support for ARC and blocks, but I’m having some issues and >> general questions. >> I’ve successfully built libobjc2 (as well as libdispatch) in a Visual Studio >> command prompt using CMake and clang-cl as recommended >> <https://github.com/gnustep/libobjc2/blob/master/README.windows> (i.e. not >> using MinGW). Should these DLLs link/work when building GNUstep using >> MSYS2/MinGW? > > Yes, they're native Windows DLLs, they should work with any Windows program, > irrespective of what other DLLs it links (e.g. cygwin / msys). Note that the > v2 ABI now has native support for SEH, so if you want exception interop and > you want MinGW, you will need the toolchain variant that uses SEH, not > Itanium-style DWARF unwinding. > > There is a bug somewhere in the SEH support that I need to look for. I > suspect it is in clang - EH seems to fail with ARC and I think that it may be > to do with the ARC calls not being correctly emitted in the funclet. Dustin > is planning on looking at some of the Clang funclet issues. > >> For me, building GNUstep base in MSYS2/MinGW fails during configure. Using >> LLD it doesn’t find objc.dll ("unable to find library -lobjc"). Using Gold >> gives different errors ("unrecognized emulation i386pep" and others). I’ve >> verified the library search paths. >> As I’m pretty new to MinGW on Windows any general pointers are also much >> appreciated. > > To the best of my knowledge, WinObjC works in this configuration but I do not > know of anyone who has tried GNUstep (though I have no reason to suppose it > won't work). > > Note that, on Windows, the linker does not need to find objc.dll, it needs to > find objc.lib. You don't need objc.dll until you try to run a program (by > default, Windows searches in the same folder as the .exe, so to run the tests > CMake copies objc.dll into the Tests directory). The Gold error looks as if > you may have a 32-bit version of the DLL and be using a 64-bit toolchain? > WinObjC is not 64-bit clean, but GNUstep should be. The runtime builds in > either configuration (see the CI scripts - we build and test both in CI). > > David >
