Well, whilst I am sad that it crashed
Well, whilst I am sad that it crashed for you, I am relieved that you found a solution that seems to work (though it does seem to be something of a Heisenbug https://en.wikipedia.org/wiki/Heisenbug).
Just as well that you got around it because at the moment our MacOS build system seems to be creating Mudlet versions that appear to start but then crash and burn because a library (
zstd) that the libzip library dynamically loads/depends on now (since version 1.8) that parts of Mudlet uses is no longer included in the application bundle for MacOS (it is okay for the Mudlet 4.17.2 release build but I suspect that all the current PTBs and testing/PR builds are borked like this.
I'm investigating but I am severely hindered because I am not a Mac owner/user and it is a rather alien landscape for me to debug remotely on our GitHub actions based build system...8 Replies
We do have access to an m1 mac at macstadium for testing and debugging purposes.
How does that work - do I log into it with SSH? The bottom line I think is that we need to fix our build system (maybe with some scripting "duct-tape") to get the
libzstd.1.dylib back into our Mudlet....app bundle:
I believe the instructions are in our keybase share, and it's VNC or NoMachine
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
🤦♂️
Unknown User•15mo ago
Message Not Public
Sign In & Join Server To View
I think I have been looking at the rong thing - I am beginning to suspect it is not something in the mudlet repository but in the mudlet-installer one - I can see that there is some bodging of
libzip.5.dylib in THAT repository:
The trouble is that I do not actually know if people are having problems with the most recent MacOS PTB or test builds with them crashing on start-up because
libzstd.1.dylib is not available...