Re: GNUstep on Windows using Clang + MSVC ABI

[Frederik Seiffert]

Sorry everyone, looks like my earlier draft got sent out prematurely...

Am 29.01.2021 um 17:28 schrieb David Chisnall <gnustep@theravensnest.org>:

ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at all and GNUstep was one of only two consumers so I think it's fair to say that it's pretty likely that it will continue to be intermittently broken by various linker versions.  I personally like the concept but it's probably better to not depend on it anywhere.

Yeah, hopefully this change will resolve these issues once and for all.

That being said, Richard raised one *potential* issue with this change on GitHub, which is that it increases the length of the command that the linker is being called with, as now all subproject object files are passed directly to the linker. Hopefully OS command line limits are large enough these days so that this won’t be an issue in practice, but I’d still encourage everyone to try building their projects with the "clang-msvc-support" branch of tools-make.

- Building
Building with this setup requires using a standard (non-MinGW) Clang that e.g. comes with Visual Studio or is available as pre-built binary from the LLVM website, and requires passing a host to configure like --host=x86_64-pc-windows. Invoking `clang -v` should show a target like "x86_64-pc-windows-msvc". It *might* be that using a MinGW Clang works too when invoked with --target x86_64-pc-windows-msvc, but I haven’t tried that.

The easiest way of installing clang on Windows is via Chocolatey: just run `choco install llvm` once it's installed.  Choco is also the easiest way of installing cmake and Ninja for building the runtime.

Thanks, good to know!

The build is best done in an MSYS2 shell that does not have any additional *-devel packages installed that might get picked up by configure. Alternatively --disable-xxx flags can be used to prevent these dependencies to be picked up.

Have you tried with the bash.exe in C:\Windows\System32?

I briefly tried building in WSL today, and the main difference to using an MSYS2 shell is that Autoconf will consider it cross-compiling. This means that some config checks will not be run (because Autoconf will think that it can’t run the binaries), and we would need to provide a cross.config file with pre-determined results of these config files instead (just like when cross-compiling e.g. for Android). This is obviously more fragile.

But this kind of illustrates what I consider the biggest challenge with this setup: the need to install and jump between different shells in order to build the whole system (i.e. CMD for libobjc2, libdispatch, and probably others; Bash/MSYS2 for GNUstep).

I’m not sure if there’s an elegant solution to this. My current line of thinking is to create a project like tools-android (tools-windows?) with Batch + Bash scripts to build all dependencies and GNUstep in their respective environments.

Is the -fuse-ld=lld line required?  You get LLD installed when you install clang, so it's not very important, but the runtime and its tests, at least, also work with LINK.EXE (though you may have to disable incremental linking if it's on by default).

I did:

I tried using the MS linker (link.exe), but while that seems to generally work fine linking ObjC files, it throws up at some configure tests (specifically when testing "whether objc really works"). Using LLD works though, so one must run Make configure with LDFLAGS="-fuse-ld=lld".

This is reproducible simply by compiling config/config.objc.m from libs-base:

$ clang -o conftest.exe config/config.objc.m -I/c/GNUstep/x64/include -L/c/GNUstep/x64/lib -fobjc-runtime=gnustep-2.0 -lobjc

LINK : conftest.exe not found or not built by the last incremental link; performing full link

conftest-b38f3b.o : warning LNK4078: multiple '.CRT' sections found with different attributes (40400040)

libcmt.lib(initializers.obj) : warning LNK4254: section '.CRT' (C0000040) merged into '.rdata' (40000040) with different attributes

$ ./conftest.exe

Segmentation fault

$ lldb conftest.exe

(lldb) r

Process 165928 stopped

* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x7ffce04d1048: Access violation reading location 0x00000000

    frame #0: 0x00007ffce04d1048 objc.dll`objc_msgSend + 40

objc.dll`objc_msgSend:

->  0x7ffce04d1048 <+40>: movl   (%r10), %r11d

    0x7ffce04d104b <+43>: cmpl   $0x8, %r11d

    0x7ffce04d104f <+47>: je     0x7ffce04d1063            ; <+67>

    0x7ffce04d1051 <+49>: cmpl   $0x0, %r11d

Let me know if I should open an issue for this somewhere, or if there’s something in config.objc.m that we should change to fix this.

For pthreads I have built http://www.sourceware.org/pthreads-win32/ from source by invoking "nmake clean VC" in a VS native tools command prompt, and manually copied the headers (pthread.h, sched.h, semaphore.h), pthreadVC2.lib (renamed to pthread.lib), and phtreadVC2.dll.

At some point it would be nice to lose this dependency.  I don't know how much the attitude to C++ in GNUstep has changed recently, but C++11 now has a nice set of threading abstractions that provide everything that NSThread, NSLock and friends need.  If we use those instead of pthreads then we'd have something that worked on any platform with a C++11 implementation (Linux, Windows, Fuschia, Haiku, and so on).

That’d be nice! I would personally be completely open to using C++ in GNUstep, and that sounds to me like a much better solution than implementing NSThread and NSLock with native Windows APIs, although that’s of course also an option.

I’d appreciate any thoughts on this from others what they think about C++ in GNUstep to replace specific APIs like pthreads? I guess this could be guarded with a config check so that a pure-C version would still be available using pthreads.

- NSFileManager support
NSFileManager is currently non-functional with this setup due to dirent.h missing (MinGW has it, but Windows doesn’t).
I found this MIT-licensed header-only implementation – would that be ok to add to the project?
https://github.com/win32ports/dirent_h/blob/master/dirent.h

I think that looks easier than using Win32 ABIs directly.

Agreed. I’ll give it a go.

- Autoconf GNUC / GCC / Clang detection
When targeting the MSVC ABI, Clang does not define `__GNUC__`, which causes Autoconf to not define $GCC (i.e. "checking whether we are using the GNU C compiler" will be NO). I thus removed $GCC as a pre-requisite in GS_CHECK_CC_IS_CLANG(), so that Clang is still correctly detected in this setup.

I *believe* this is controlled by either a gnu dialect (e.g. -std=gnu11 for C) or -fgnu-extensions.  That said, I'm not sure if you can #include Windows headers with gnu extensions enabled.

Yeah I tried with -fgnuc-version=xxx, but then Windows headers didn’t work.

- Debug/Release CRT
Just a heads up that on Windows the C runtime libraries (CRT) come in two versions for debug and release builds (e.g. msvcrt and msvcrtd). The libraries that are used seem to have to match between all DLLs – e.g. building libobjc2 for debug will cause all sorts of crashes when Base is build for release, e.g. when freeing memory allocated by libobjc2 in Base.

Fun.

Indeed. My plan is to link against debug libraries when building with "make debug=yes".

lld-link: error: relocation against symbol in discarded section: __start_.objcrt$SEL
>>> referenced by C:\msys64\tmp\conftest-78a937.o:(.objc_init)
This is reproducible when building a file that calls ObjC runtime functions but doesn’t actually contain any ObjC code. Not sure if that’s expected behavior or bug.

I think this is a bug, probably a clang bug (and probably my fault)

Should I open an LLVM issue for this?

Awesome work, and it makes me much happier than trying to support MinGW.

Thank you, glad you like it! This is also exciting to us because it should e.g. allow us to use recent Windows technologies like the C++/WinRT language projection from ObjC++ which are not compatible with MinGW.

That being said, I would still very much like to get libobjc2 working with MinGW as well, as it would allow people currently using GNUstep with GCC in a MinGW environment to switch to Clang/libobjc2, should result in a more streamlined setup experience with all dependencies being available via MinGW packages and everything being built in one shell, and allow for existing MinGW-based software to be used.

I’ll try to get you those instructions for building LLVM with the MinGW patches in the next couple weeks.

We have given up supporting MinGW for snmalloc and I am considering optionally supporting snmalloc for Objective-C object allocations since it is much faster than the system malloc on most platforms and is particularly good for fixed-size allocations as are common in Objective-C.  It would be a shame for this to be an everywhere-except-Windows thing.

That looks really great! Would be interesting to see some performance stats of this for ObjC specifically if you have that.

Frederik