|Subject:||Re: Building GNUstep for Windows using Clang|
|Date:||Fri, 6 Mar 2020 13:44:03 -0500|
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
> (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.
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
> 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.
|[Prev in Thread]||Current Thread||[Next in Thread]|