[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tools-windows-msvc runtime error
From: |
Frederik Seiffert |
Subject: |
Re: tools-windows-msvc runtime error |
Date: |
Tue, 18 Jul 2023 12:47:31 +0200 |
I tried adding /INCREMENTAL:NO, but the issue persists.
Also the documentation says that incremental linking is disabled when the
output file doesn’t exist, which is confirmed by this log after deleting the
.exe:
> LINK : test.exe not found or not built by the last incremental link;
> performing full link
Frederik
> Am 18.07.2023 um 11:07 schrieb David Chisnall <gnustep@theravensnest.org>:
>
> Did you remember to disable incremental linking?
>
> Last time I tested it, LINK.EXE did work, but if you had incremental linking
> enabled (I think it’s on by default?) then it inserts random padding into the
> Objective-C runtime’s metadata sections, which corrupt various things.
>
> David
>
>> On 18 Jul 2023, at 08:34, Frederik Seiffert <frederik@algoriddim.com> wrote:
>>
>> 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 <loserist@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!
>>
>>
>
- tools-windows-msvc runtime error, (continued)
- Fw: Re: Re: tools-windows-msvc runtime error, loserist, 2023/07/16
- Re: tools-windows-msvc runtime error, Frederik Seiffert, 2023/07/17
- Re: tools-windows-msvc runtime error, Frederik Seiffert, 2023/07/18
- Re: tools-windows-msvc runtime error, David Chisnall, 2023/07/18
- Re: Re: tools-windows-msvc runtime error, loserist, 2023/07/18
- Re: Re: tools-windows-msvc runtime error, loserist, 2023/07/18
- Re: tools-windows-msvc runtime error,
Frederik Seiffert <=