Gorm files fail to load on Windows due to a BOOL compatibility issue

[johnathan-becker]

I’ve identified that the root cause is a difference in the definition of BOOL across platforms: on Windows), BOOL is defined as an int, while on the platform where these Gorm files were generated, BOOL is defined as an unsigned char. This discrepancy is causing incompatibility in file loading.

I’m reaching out to see if anyone has suggestions or insights on creating platform-agnostic compatibility for BOOL definitions within Gorm files to ensure consistent functionality across different environments. Any guidance or approaches to address this cross-platform compatibility would be greatly appreciated.

[rmottola]

As far as I know it has always been so. In the past I didn't have issues.

Most Gorm files do load... can you give a better example of yours?

[johnathan-becker]

As far as I know it has always been so. In the past I didn't have issues.

Most Gorm files do load... can you give a better example of yours?

I have not found a single gorm file that loads in up-to-date MSYS environments. That includes all of them in the test-examples project.

[rmottola]

I have an up-to-date mingw64 environment and I have whole applications opening. There are some glitches, but nothing as bad as you say.

[johnathan-becker]

I have an up-to-date mingw64 environment and I have whole applications opening. There are some glitches, but nothing as bad as you say.

So an example is Ink.app. If you try to launch that app it hangs. This happens because it is using a gorm file and it fails to load this. This is specific to gorm files.

[gcasa]

I have an up-to-date mingw64 environment and I have whole applications opening. There are some glitches, but nothing as bad as you say.

So an example is Ink.app. If you try to launch that app it hangs. This happens because it is using a gorm file and it fails to load this. This is specific to gorm files.

There is likely a recent change in GUI that caused this. I will try to chase down the issue.

[rmottola]

all fine, sir

[qmfrederik]

@rmottola Which compiler and Objective C runtime are you using? I see this with libobjc2 and clang:

UCRT64 ~/git/tests-examples/gui/Ink
# ./Ink.app/Ink.exe
2024-11-14 10:12:27.241 Ink[9548:9544] Exception occurred while loading model: expected int and got unsigned char
2024-11-14 10:12:27.262 Ink[9548:9544] Failed to load Gorm
2024-11-14 10:12:27.262 Ink[9548:9544] Exception occurred while loading model: expected int and got unsigned char
2024-11-14 10:12:27.262 Ink[9548:9544] Failed to load Gorm
2024-11-14 10:12:27.262 Ink[9548:9544] Cannot load the main model file 'MainMenu'
2024-11-14 10:12:27.875 Ink[9548:9544] Exception occurred while loading model: expected int and got unsigned char
2024-11-14 10:12:27.875 Ink[9548:9544] Failed to load Gorm
2024-11-14 10:12:27.875 Ink[9548:9544] NSWindowController: could not load nib named Document.nib

[qmfrederik]

... and which MSYS2 environment are you using? I'm on UCRT64.

[rmottola]

... and which MSYS2 environment are you using? I'm on UCRT64.

how do I know? I have this in env:
MSYSTEM_CHOST=x86_64-w64-mingw32

[rmottola]

@rmottola Which compiler and Objective C runtime are you using? I see this with libobjc2 and clang:

GCC with its runtime. Code updated today, so we know it can work on windows intel 64bit.

It might be runtime or compiler problem.

[qmfrederik]

In the MSYS2 terminal, type echo $MSYSTEM to find out which environment you're on. Good to have confirmation this works with GCC, this may be specific to the clang compiler.

[qmfrederik]

So in this case, it fails when decoding the _enable property of the NSMenuItem class. I wonder whether gnustep/libs-base@40f88bc is related.

Here's the full backtrace:

frame #3: 0x00007ff8d0f198f6 gnustep-gui-0.dll`-[NSMenuItem initWithCoder:](self=0x0000026c73a819c8, _cmd="\xa1", aDecoder=0x0000026c7344e128) at NSMenuItem.m:752:7
frame #4: 0x00007ff8bf004f8c gnustep-base-1_30.dll`-[NSUnarchiver decodeValueOfObjCType:at:](self=0x0000026c7344e128, _cmd="\x8f", type="@", address=0x0000026c73a0ca20) at NSUnarchiver.m:928:11
frame #5: 0x00007ff8bf00407e gnustep-base-1_30.dll`-[NSUnarchiver decodeArrayOfObjCType:count:at:](self=0x0000026c7344e128, _cmd="\x92", type="@", expected=9, buf=0x0000026c73a0ca20) at NSUnarchiver.m:628:4
frame #6: 0x00007ff8bee44c36 gnustep-base-1_30.dll`-[GSMutableArray initWithCoder:](self=0x0000026c73a0c9c8, _cmd="\xa1", aCoder=0x0000026c7344e128) at GSArray.m:543:6
frame #7: 0x00007ff8bf004f8c gnustep-base-1_30.dll`-[NSUnarchiver decodeValueOfObjCType:at:](self=0x0000026c7344e128, _cmd="\x90", type="@", address=0x000000ee08efed80) at NSUnarchiver.m:928:11
frame #8: 0x00007ff8beed2fd6 gnustep-base-1_30.dll`-[NSCoder decodeObject](self=0x0000026c7344e128, _cmd="\xe0") at NSCoder.m:248:3
frame #9: 0x00007ff8d0f0b7a8 gnustep-gui-0.dll`-[NSMenu initWithCoder:](self=0x0000026c739f3f28, _cmd="\xa1", aDecoder=0x0000026c7344e128) at NSMenu.m:1558:16
frame #10: 0x00007ff8bf004f8c gnustep-base-1_30.dll`-[NSUnarchiver decodeValueOfObjCType:at:](self=0x0000026c7344e128, _cmd="\x8f", type="@", address=0x000000ee08eff0e8) at NSUnarchiver.m:928:11
frame #11: 0x00007ff8bee66b1e gnustep-base-1_30.dll`-[GSSet initWithCoder:](self=0x0000026c739e9848, _cmd="\xa1", aCoder=0x0000026c7344e128) at GSSet.m:248:4
frame #12: 0x00007ff8bf004f8c gnustep-base-1_30.dll`-[NSUnarchiver decodeValueOfObjCType:at:](self=0x0000026c7344e128, _cmd="\x90", type="@", address=0x0000026c739e8e90) at NSUnarchiver.m:928:11
frame #13: 0x00007ff8d105dc74 gnustep-gui-0.dll`-[GSNibContainer initWithCoder:](self=0x0000026c739e8e68, _cmd="\xa1", aCoder=0x0000026c7344e128) at GSGormLoading.m:393:7
frame #14: 0x00007ff8bf004f8c gnustep-base-1_30.dll`-[NSUnarchiver decodeValueOfObjCType:at:](self=0x0000026c7344e128, _cmd="\x90", type="@", address=0x000000ee08eff6e0) at NSUnarchiver.m:928:11
frame #15: 0x00007ff8beed2fd6 gnustep-base-1_30.dll`-[NSCoder decodeObject](self=0x0000026c7344e128, _cmd="\xe0") at NSCoder.m:248:3
frame #16: 0x00007ff8d10a4818 gnustep-gui-0.dll`-[GSGormLoader loadModelData:externalNameTable:withZone:](self=0x0000026c7345e5e8, _cmd="\x8f9\U00000001", data=0x0000026c73358d48, context=0x0000026c7347c588, zone=0x00007ff8bf321248) at GSGormLoader.m:134:14
frame #17: 0x00007ff8d0f1f07f gnustep-gui-0.dll`-[NSNib instantiateNibWithExternalNameTable:withZone:](self=0x0000026c73376a48, _cmd="\x80(\U00000001", externalNameTable=0x0000026c7347c588, zone=0x00007ff8bf321248) at NSNib.m:181:10
frame #18: 0x00007ff8d0e3e5d1 gnustep-gui-0.dll`+[NSBundle(self=0x00007ff8bf2d6e58, _cmd="\x82(\U00000001", fileName=0x0000026c734505a8, context=0x0000026c7347c588, zone=0x00007ff8bf321248) loadNibFile:externalNameTable:withZone:] at NSBundleAdditions.m:54:17
frame #19: 0x00007ff8d0e3e984 gnustep-gui-0.dll`-[NSBundle(self=0x0000026c73347de8, _cmd="\x82(\U00000001", fileName=0x0000026c73299b68, context=0x0000026c7347c588, zone=0x00007ff8bf321248) loadNibFile:externalNameTable:withZone:] at NSBundleAdditions.m:150:14
frame #20: 0x00007ff8d0e3e6cd gnustep-gui-0.dll`+[NSBundle(self=0x00007ff8bf2d6e58, _cmd="y \U00000001", aNibName=0x0000026c73299b68, owner=0x0000026c73366a08) loadNibNamed:owner:] at NSBundleAdditions.m:86:24
frame #21: 0x00007ff8d0de1499 gnustep-gui-0.dll`NSApplicationMain(argc=1, argv=0x0000026c713a3c80) at Functions.m:92:11
frame #22: 0x00007ff6b0ec12e9 Ink.exe`__tmainCRTStartup
frame #23: 0x00007ff6b0ec13d6 Ink.exe`WinMainCRTStartup
frame #24: 0x00007ff915497374 kernel32.dll`BaseThreadInitThunk + 20
frame #25: 0x00007ff915d1cc91 ntdll.dll`RtlUserThreadStart + 33

[qmfrederik]

To add a bit more color to what @johnathan-becker said:

• GCC's libobjc runtime always defines BOOL as an unsigned char: https://github.com/gcc-mirror/gcc/blob/master/libobjc/objc/objc.h#L55
• GNUstep's libobjc2 runtime defines BOOL as int on Windows, except when compiling with STRICT_APPLE_COMPATIBILITY.

So, in that case, I think an option is to relax the rules in NSUnarchiver and allow a mapping of an (un)signed char to an int.

[rmottola]

You might want to try STRICT_APPLE_COMPATIBILITY.
I wonder why libobjc2 tries to differ there.