[Top][All Lists]

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

Re: Building GNUstep for Windows using Clang

From: Gregory Casamento
Subject: Re: Building GNUstep for Windows using Clang
Date: Fri, 6 Mar 2020 13:44:03 -0500


Since we are talking about building on Windows 10 using clang and msys2 I would like someone to write up a comprehensive guide on how.   From A to Z, please.   I realize I'm likely to be roasted for this request by multiple people, but at this point it needs to be done and I am quite used to being roasted. :/

Yours, GC

On Fri, Mar 6, 2020 at 11:51 AM David Chisnall <address@hidden> wrote:
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.


Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant -

reply via email to

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