Thanks, I reproduced the issue here. It turns out using the Microsoft linker causes this issue, but using LLD works fine. I’m not sure why or since when this is, as using link.exe definitely worked for me at one point, but now using either VS 2019 or 2022 causes this crash as soon as objc_msgSend() is called. Maybe David has an idea what could be going on here?
Anyway, passing -fuse-ld=lld should get you going. I would also add /Z7 to produce debug symbols as well: clang-cl -I C:\GNUstep\x64\Debug\include -fobjc-runtime=gnustep-2.0 -Xclang -fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP -DGNUSTEP_WITH_DLL -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -D_NATIVE_OBJC_EXCEPTIONS -DGSWARN -DGSDIAGNOSE /MDd /Z7 /c test.m clang-cl test.obj gnustep-base.lib objc.lib dispatch.lib -fuse-ld=lld /MDd /Z7 -o test.exe /link /LIBPATH:C:\GNUstep\x64\Debug\lib I’ve updated the toolchain readme to add this flag in the example. Hope that helps. Frederik > Am 18.07.2023 um 03:00 schrieb loserist <loser...@88.com>: > > Sure! The following is it: > > * thread #1, stop reason = Exception 0xc0000005 encountered at address > 0x7ffcec4e1048: Access violation reading locatio > n 0x00000000 > * frame #0: 0x00007ffcec4e1048 objc.dll`objc_msgSend + 40 > frame #1: 0x00007ff645cc1154 abc.exe > frame #2: 0x00007ff645cc142c abc.exe > frame #3: 0x00007ffcfb967614 kernel32.dll`BaseThreadInitThunk + 20 > frame #4: 0x00007ffcfc1826b1 ntdll.dll`RtlUserThreadStart + 33 > Thanks!
