Closed levinli303 closed 1 year ago
This is probably related to this bug: https://github.com/llvm/llvm-project/issues/56952
For the time being I’d recommend sticking with Clang 13. You can use one of the official downloads from the LLVM website instead of using the Visual Studio one.
looks like it. it is possible to use a custom LLVM toolchain in Visual Studio too. might be good to mention it in the msvc-tools repo about this bug.
@levinli303 Can you run the test suite for libobjc2 and check if you see these failing:
7 - ARCTest_arc (Exit code 0xc0000409)
8 - ARCTest_arc_optimised (Exit code 0xc0000409)
41 - PropertyIntrospectionTest2_arc (SEGFAULT)
42 - PropertyIntrospectionTest2_arc_optimised (SEGFAULT)
I am looking into these failures right now. Might be good to know if this is one and the same issue.
@weliveindetail do you still need me to run these tests? I'm not sure how to do so, if you can provide some commands to allow me to run the tests I can do it in the coming few days.
Yes that might be a good test. Assuming you use CMake and Ninja to build libobjc2 and that you installed Clang from one of the releases you should be able to build a release version like this:
> git clone https://github.com/gnustep/libobjc2
> cd libobjc2
> mkdir build-release
> cd build-release
> cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER="C:/LLVM14/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/LLVM14/bin/clang-cl.exe" ..
> ninja
Then copy the objc.dll
into the Test
subdirectory and run ctest
:
> cp objc.dll Test\objc.dll
> ctest
Up until Clang 15.x the above mentioned tests should fail. I landed a fix in mainline yesterday. If you build Clang from the latest sources yourself (or wait for release 16.x) they should pass now.
might be good to mention it in the msvc-tools repo about this bug.
I’ve added a section about known compiler issues in the readme: https://github.com/gnustep/tools-windows-msvc#status-and-known-issues
@weliveindetail I'm seeing
lld-link: error: could not open 'kernel32.lib': no such file or directory
lld-link: error: could not open 'user32.lib': no such file or directory
lld-link: error: could not open 'gdi32.lib': no such file or directory
lld-link: error: could not open 'winspool.lib': no such file or directory
lld-link: error: could not open 'shell32.lib': no such file or directory
lld-link: error: could not open 'ole32.lib': no such file or directory
lld-link: error: could not open 'oleaut32.lib': no such file or directory
lld-link: error: could not open 'uuid.lib': no such file or directory
lld-link: error: could not open 'comdlg32.lib': no such file or directory
lld-link: error: could not open 'advapi32.lib': no such file or directory
lld-link: error: could not open 'msvcrtd.lib': no such file or directory
lld-link: error: could not open 'oldnames.lib': no such file or directory
ninja: build stopped: subcommand failed.
with the cmake -GNinja ...
command
@levinli303 Did you run this from your Visual Studio command line?
@weliveindetail the test suite are all passing for this clang version (I need to set CMAKE_C_COMPILER to clang instead of clang-cl, otherwise it will complain import is not a MSVC feature)
clang version 14.0.5
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\bin
Is this now fixed?
based on https://github.com/gnustep/tools-windows-msvc#status-and-known-issues, it is fixed in clang 16.
Yes this was fixed in Clang 16. You can get the RC build here if you want to give it a try to confirm: https://github.com/llvm/llvm-project/releases
In the discussions around this fix there were some open questions around whether the GNUstep runtime needs/uses markers for ObjC ARC autorelease optimization. @davidchisnall could you still chime in on that?
From https://github.com/llvm/llvm-project/issues/56952#issuecomment-1256136782:
@davidchisnall Is GNUstep checking for optimized callers like the callerAcceptsOptimizedReturn() in Apple's ObjC runtime here? https://opensource.apple.com/source/objc4/objc4-818.2/runtime/objc-object.h.auto.html
From https://reviews.llvm.org/D134441#3810388:
It's possible the GNU runtime generally uses a different approach and doesn't need these markers at all; David Chisnall might know.
After updating Visual Studio to 17.3 (which updated clang to clang 14), I'm noticing a crash in some methods when built with clang 14 in release mode on Windows. This only happens with clang 14 + Release. Does not happen with clang 13, or in debug mode. Using example project in https://github.com/gnustep/tools-windows-msvc
One example is to use this method
[NSProgress progressWithTotalUnitCount:10];
This crash does not happen if I write
[[NSProgress alloc] initWithParent:nil userInfo:nil];