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:
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), 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
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
|