Re: tools-windows-msvc runtime error

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=E2=80=99s on by default?) then it inserts =
random padding into the Objective-C runtime=E2=80=99s metadata sections, =
which corrupt various things.

David

> On 18 Jul 2023, at 08:34, Frederik Seiffert <[email protected]> =
wrote:
>=20
> Thanks, I reproduced the issue here. It turns out using the Microsoft =
linker causes this issue, but using LLD works fine. I=E2=80=99m 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?
>=20
> Anyway, passing -fuse-ld=3Dlld should get you going. I would also add =
/Z7 to produce debug symbols as well:
>=20
> clang-cl -I C:\GNUstep\x64\Debug\include -fobjc-runtime=3Dgnustep-2.0 =
-Xclang -fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP =
-DGNUSTEP_WITH_DLL -DGNUSTEP_RUNTIME=3D1 -D_NONFRAGILE_ABI=3D1 =
-D_NATIVE_OBJC_EXCEPTIONS -DGSWARN -DGSDIAGNOSE /MDd /Z7 /c test.m
>=20
> clang-cl test.obj gnustep-base.lib objc.lib dispatch.lib -fuse-ld=3Dlld =
/MDd /Z7 -o test.exe /link /LIBPATH:C:\GNUstep\x64\Debug\lib
>=20
> I=E2=80=99ve updated the toolchain readme to add this flag in the =
example.
>=20
> Hope that helps.
> Frederik
>=20
>=20
>> Am 18.07.2023 um 03:00 schrieb loserist <[email protected]>:
>>=20
>> Sure! The following is it:
>>=20
>> * thread #1, stop reason =3D 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!
>=20
>=20