On 01/02/2021 18:24, Frederik Seiffert wrote:
Sorry everyone, looks like my earlier draft got sent out prematurely...
Am 29.01.2021 um 17:28 schrieb David Chisnall
mailto:gnus...@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.
I'm curious about this. GNUstep projects have fairly short linker lines
in comparison with a bunch of C++ projects. I had a quick look at the
systems I have runningL
- 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.
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.
Oh, sorry, wrong bash. The one I was thinking of is actually installed
for me as c:\Program Files\Git\git-bash.exe. It's installed by the git
package and gives you a Windows-native bash environment. If the
configure scripts just depend on bash, that ought to be sufficient.
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'
(C040) merged into '.rdata' (4040) with different attributes >
$ ./conftest.exe
Segmentation fault
This file appears to depend on objc-common.g, which looks like a
generated file. It probably only needs it for the root-class attribute
(which only raises a warning if it's omitted, so isn't the end of the
world). Aside from that, the file looks like a bunch of the tests that
we have in the libobjc2 repo, which pass in CI, so I'm not sure what's
going on there. Can you add -### to the clang command line and see how
it compares to the same thing for the libobjc2 tests?
$ lldb conftest.exe
(lldb) r
Process 165928 stopped
* thread #1, stop reason = Exception 0xc005 encountered at address
0x7ffce04d1048: Access violation reading location 0x
frame #0: 0x7ffce04d1048 objc.dll`objc_msgSend + 40
objc.dll`objc_msgSend:
-> 0x7ffce04d1048 <+40>: movl (%r10), %r11d
0x7ffce04d1
