[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building GNUstep for Windows using Clang

From: David Chisnall
Subject: Re: Building GNUstep for Windows using Clang
Date: Fri, 6 Mar 2020 08:51:30 -0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 05/03/2020 00:43, Frederik Seiffert wrote:
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 (, 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.

Hmm, that probably means that -base Additions won't build.

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?

If you're not using -r, then I don't know what this .o will be. The subproject thing is a source of constant pain because almost nothing other than GNUstep uses -r, so it tends to be horribly buggy. It's supposed to take a load of .o files and generate a .o file that can be linked as if it were the original list of .o files. Modern build systems just pass the list of .o files around.

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.

No, libcxxrt implements the Itanium C++ ABI. On Windows, libobjc2 supports the Visual Studio C++ ABI, so exceptions should interop with C++ libraries compiled with clang or MSVC.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]