Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
johnathan-becker opened this issue Nov 12, 2024 · 15 comments
Open

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

johnathan-becker opened this issue Nov 12, 2024 · 15 comments
Assignees
@gcasa

Comments

@johnathan-becker
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

gcasa commented Nov 13, 2024

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.

@gcasa gcasa self-assigned this Nov 13, 2024
@rmottola
Copy link
Member

image

all fine, sir

@qmfrederik
Copy link
Contributor

@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
Copy link
Contributor

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

@rmottola
Copy link
Member

... 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
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Contributor

qmfrederik commented Nov 14, 2024 •
edited
Loading

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
Copy link
Contributor

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

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
Copy link
Member

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

@qmfrederik
Copy link
Contributor

I wonder why libobjc2 tries to differ there.

Because it supports building natively on Windows, and BOOL is defined in the Windows SDK as an int. But on MSYS, STRICT_APPLE_COMPATIBILITY should work. See gnustep/libobjc2#309

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gcasa gcasa

Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@gcasa @qmfrederik @rmottola @johnathan-becker