Support building on Windows with Clang MSVC target

[triplef]

These changes enable building on Windows with Clang, libobjc2, and the MSVC ABI (i.e. not using MinGW).

Requires using a standard Windows Clang build that e.g. comes with Visual Studio or is available as pre-built binary from the LLVM website. Invoking clang -v should show a target like x86_64-pc-windows-msvc.

Configure must be invoked with a host like x86_64-pc-windows or i386-pc-windows, e.g.:

export CC=/C/LLVM/bin/clang
export CXX=/C/LLVM/bin/clang++
export OBJCXX=/C/LLVM/bin/clang++

./configure --host=x86_64-pc-windows --with-library-combo=ng-gnu-gnu --with-runtime-abi=gnustep-2.0 --prefix=/c/GNUstep/x64 LDFLAGS="-fuse-ld=lld"

As the Windows linker does not support incremental linking using ld -r, this also contains a change to link subproject object files directly (434f957): Instead of merging all subproject object files into subproject.o, we now create a subproject.txt containing a list of all object files, and use these directly in SUBPROJECT_OBJ_FILES. This affects all platforms and seems to work fine in CI for all existing targets, but please let me know if there are any concerns with this change.

Accompanying pull request for Base forthcoming.

[rfm]

That looks really good. I haven't tried it on windows, but I tried it with a few Linux systems without problems.
The only worry I have is about the subproject change: the new mechanism, listing all the obj files, could result in pretty huge command lines. However, the O/S limit on the length of a command line is pretty long nowadays, so I'm not overly concerned by that possibility. I would say that, if it does turn out to be a problem on some systems, we might have to support both mechanisms, but until/unless that turns out to be an issue we shoudl keep it simple and just use your change.

[triplef]

Thanks @rfm, sounds good!

I was also wondering if we should wait with merging this until the upcoming releases are done (not sure what the status on these are)?

[rfm]

On 30 Jan 2021, at 15:31, Frederik Seiffert ***@***.***> wrote: Thanks @rfm, sounds good! I was also wondering if we should wait with merging this until the upcoming releases are done (not sure what the status on these are)?

Sorry for taking so long to come back on this (I was indecisive, and hoping someone else might comment). While I agree that it seems like a bit of a risk to apply before a release, I think the benefit might outweigh the risk, and I also think that you ought to get your work applied publicly in a timely manner: I kind of feel that a free software project should give satisfaction to the people who contribute. For me that is reason enough to tip the balance and say that the merge should go ahead before the release. Thanks.

[triplef]

Thanks, then I’ll go ahead and merge this.

For future reference, here’s some feedback from David from the mailing list on the possible command line length issue you mentioned. This supports that this is unlikely to be an issue.

• FreeBSD limits it to 256 KiB on processes with limited kernel virtual address space, 512 KiB elsewhere.
• Linux limits it to 128KiB statically but can return a larger number via sysconf depending on the system. For me, that is around 2MiB.
• Windows limits it to 32 KiB, though cmd.exe only handles 8 KiB.

Even with the 8KiB limit, you'd need a few hundred files on the linker invocation for this to be a problem unless you're giving long absolute paths for everything.