-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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.
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
3.2.2 Linux headless version exports invalid Mac app #39931
Comments
Does the Linux headless non-mono version produce a valid Mac app? |
App is valid and running on macOS 10.15.5 (it's not signed and do trigger GateKeeper warning). |
@neikeq Good call, the headless non-mono version also produces an invalid app for me. That build is here: https://drive.google.com/file/d/16aYbNx7ovtIKkqvgd_SAZ7ya-7uo6L93/view?usp=sharing I will update the issue to remove references to Mono. @bruvzg I am also running on Mac OS 10.15.5. Here's a screenshot of what I am experiencing. This is when trying to run the build that I linked in the issue: I'm used to seeing the Gatekeeper warning for 3.2.1 and earlier, strange that now it's outright saying it can't be opened. |
@firebelley What was the last godot version for which this scenario was working? |
Please specifically test on 3.2.2 RC1 if you have a chance, so we'll know if the regression was introduced in #39700 |
@pouleyKetchoupp This was working in 3.2.1 stable, meaning that the app was recognized as a valid app. It still couldn't be executed because it was lacking the appropriate executable flags. I just tested with 3.2.2 RC1 and it produced a valid Mac app. I can run the app without issue. Let me know if you'd like me to share that build. |
Thanks @firebelley! That means this regression is due to my changes in #39700. I don't really understand why, but it seems the file type flags I've added are invalid when zipping from a linux system then. A possible hotfix might be to set zip flags differently depending on the platform we're exporting from. I'll try and reproduce it in the coming days to see if I can figure it out. @bruvzg I agree it would be worth checking with a different zip library, although at this point I have no idea if the problems we're encountering are mostly coming from the library itself or some weirdness in macOS archivers :) |
FYI: Godot 3.2.2 stable/release also outputs broken Mac
|
These are the ( When the
Interestingly, I just noticed the latter says "30 Jul 2020" but here today is actually "30 June 2020", |
Additionally, with my own project when I first tried to open the exported app via Finder I noticed the following in
Apparently permissions errors count as "weird reasons" these days: https://superuser.com/questions/478768/running-app-on-macosx-mountain-lion-job-failed-to-exec3-for-weird-reason-13 :D |
A thought that occurs to me:
So, if the Linux/Windows exports didn't work going on the same code path, where does it differ from what's run on Mac? |
Ummm, when was the last time (pre-3.2.2) someone verified Mac exports to Because I just generated 3 exports with Godot v3.2.1 on a Linux machine (which were all identical--matching size, matching md5 and appeared to match at least one Here's one of the files: Interestingly, I also generated (via wine on Mac) a |
I have rechecked this ZIP and it seems to have +x on executable when extracting with both Archive Utility and Keka, but result of Archive Utility contains only 0x00 in all files (size is valid)! |
Also checked it on the current 3.2 head, same effect, files full of 0x00 when extracted with Archive Util, normal when extracting with Keka. Reverting #39700 do fix it and extracted files have correct permissions with both Archive Util and Keka. |
I used https://ide.kaitai.io/ to view the Edit: Add some related links:
|
@pouleyKetchoupp Do you have more details on the "some software" mentioned in "causing the file to lose executable permissions when unzipped with some software" you mentioned in #39700 (comment)? |
Some extra info:
|
Given the confusion that's resulted from #527 still being open despite #33447 & #527 (comment), would it be good to:
BTW @pouleyKetchoupp during my research I discovered this project which seems to document some of the issues they encountered with Mac + Zip support:
(It was described in sindresorhus/gulp-zip#38 (comment) as "...spent about 6 hours today working with every zip library for node. [It was] The only one that has worked..." ) |
It's strange. I'm not getting the same results as you do, and my change is only setting some standard "normal file" flag on all files :/ The next thing I'll do is testing again with the official 3.2.2 release to see if my problem could be specific to my compilation of godot somehow. Here's my previous test case scenario: Zip export created on Windows 10 (godot master, compiled with vs 2019) Before #39700: After #39700: |
Actually it's just constant size issue, changed it to: zipfi.external_fa = (uint32_t)(is_executable ? 0100755 : 0100644) << 16L; (results in following output by zip-info, and is extracted correctly by all apps I have tested):
instead of zipfi.external_fa = (is_executable ? 0100755 : 0100644) << 16L; (results in following output by zip-info, and have broken files when extracted by Archive Util)
or zipfi.external_fa = (is_executable ? 0755 : 0644) << 16L; (results in following output by zip-info, and seems to be extracted correctly)
Also, I have checked info-zip source and it's setting attributes as following (result seems to be the same, not sure why it's done it this way): uint32_t _mode = (is_executable ? 0100755 : 0100644);
zipfi.external_fa = (_mode << 16L) | !(_mode & 0200);
zipfi.internal_fa = 0; |
Good catch! That makes a lot of sense. Bit-wise operators on signed integers are undefined and probably made the result compiler specific. |
Skimming this thread, am I correct to assume that we'll have to wait for 4.0 until headless export to OSX works, and will have to export using the normal editor build in the meantime? |
Bumping this as well, need to know if we'll be able to export to OSX with linux headless |
@raffomania @lelandhwu #39977 was cherry-picked to 3.2.3, so this should be fixed in Godot 3.2.3 and later. If this is not the case on Godot 3.4.3, please open a new issue with a minimal reproduction project attached (while also attaching the invalid export if possible). |
Godot version:
3.2.2 Linux Headless
OS/device including version:
Ubuntu 18.04 for building, Mac OS Catalina (10.15.5) for running the app
Issue description:
When exporting a Mac build with the Linux headless version of Godot 3.2.2 the result is an
.app
file that cannot be run.I'm using my GitHub workflow that runs the Linux headless version of Godot to export projects. After updating the workflow to use Godot 3.2.2, this workflow no longer outputs a valid Mac app. When attempting to run the app on my Mac I receive a dialog that states:
Exporting the Mac app from the Windows version of Godot 3.2.2 produces an app that can be run without issue.
Steps to reproduce:
Minimal reproduction project:
ActionsTest-master.zip Please note that the standard project is the
project
directory. You can also try with the mono project inproject-mono
to see the same result.If it helps, here is the output app for the standard build: https://drive.google.com/file/d/16aYbNx7ovtIKkqvgd_SAZ7ya-7uo6L93/view?usp=sharing
And here is the output app for the mono build: https://drive.google.com/file/d/1-HJnBxJ3-n8XokI-NBsz0QA3xBncPL7P/view?usp=sharing
This issue originally stated this was a mono-specific issue. After some more troubleshooting it was found that the issue also applies to the standard version.
The text was updated successfully, but these errors were encountered: