Unable to open M1 distribution

[kennycason]

Currently having an issue opening the Mac M1 release.

Version: gdx-liftoff-1.12.1.13-macM1

Command to open: open gdx-liftoff.app

The error:

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600003aa92c0 {Error Domain=NSPOSIXErrorDomain Code=111 "Unknown error: 111" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

[tommyettinger]

Dang. @fourlastor , might need some help here... I have no idea what that error is and I have no way of testing on any kind of Mac, M1 or not. It looks related to Construo, since that's what built the .app ...

[fourlastor]

I wonder if this is a signing issue? I assume liftoff isn't signed, so the first thing I'd try is xattr -cr gdx-liftoff.app (which clears the attributes on the folder, included the quarantine attribute).

In that case, to avoid the quarantine, people could download liftoff with curl -L https://github.com/libgdx/gdx-liftoff/releases/download/v1.12.1.14/gdx-liftoff-macM1.zip (or whichever url the latest release points at), as curl doesn't add the quarantine to files it downloads

[fourlastor]

Ah wait, I just tried to download both the linux and the mac version, and their executables don't have the executable permission 😬

➜  MacOS ll
total 23M
-rw-r--r-- 1 daniele daniele  149 Aug 16 21:33 config.json
-rw-r--r-- 1 daniele daniele 626K Aug 16 21:33 gdx-liftoff
-rw-r--r-- 1 daniele daniele  23M Aug 16 21:33 gdx-liftoff-1.12.1.14.jar
drwxr-xr-x 5 daniele daniele 4.0K Aug 16 21:33 jdk
➜  gdx-liftoff-1.12.1.14-linuxX64 ll
total 23M
-rw-r--r-- 1 daniele daniele  149 Aug 16 21:34 config.json
-rw-r--r-- 1 daniele daniele 711K Aug 16 21:34 gdx-liftoff
-rw-r--r-- 1 daniele daniele  23M Aug 16 21:34 gdx-liftoff-1.12.1.14.jar
drwxr-xr-x 5 daniele daniele 4.0K Aug 16 21:34 jdk

This can be verified by running chmod +x gdx-liftoff.app/Contents/MacOS/gdx-liftoff

Did you package these on windows? That might be an issue with gradle running on Windows and not managing to change the executable permission

[tommyettinger]

Indeed, I did package them on Windows, since cross-compilation is supposed to be something Construo can do... heh. I think .zip format may not always preserve chmod flags...

[JojoIce]

This can be verified by running chmod +x gdx-liftoff.app/Contents/MacOS/gdx-liftoff

I still get a popup: "“gdx-liftoff.app” is damaged and can’t be opened. You should move it to the Bin." when attempting to open the app.

However starting from command-line with java -jar gdx-liftoff-1.12.1.14.jar from within the app folder works for me. Not familiar with Construo so can't really debug, but still looks like something is off with the packaging.

I think .zip format may not always preserve chmod flags...

The app seems to be ok as in it is executable, but the files within the app (app for mac is a slightly special folder) seems to have the wrong rights, but for me not the (only?) problem.

[JojoIce]

Well, this peaked my interest, and I saw that the project that i managed to create using the command-line (1.12.1.14) had the task to create a construo packaged Mac distro. Happy to report that it works just fine on the Mac M1 that I tested it on! A proper mac app right away, very nice!

One small issue is that the folder inside of the zip that is created by construo was named projectname-$projectVersion-macM1, where "projectname" is just whatever project name you give it and the rest literally what I wrote, $ and all. The version for that app is 1.0 no matter what you set the gradle.properties projectVersion to. The zip-file does not have a version number in the name, just the project name and platform. The app had the projectname.app just as expected. The gradle task was executed on the same Mac M1 as the app was tested on.

Under lwjgl3/build/distributions/ built old-fashioned way the file will be called "lwjgl3-$projectVersion.zip"

Under lwjgl3/build/libs/ it will look as expected with proj name and version .jar

[JojoIce]

Oh, I have been doing other things and looking into this in short bursts. I tried what fourlastor mentioned. First one and then the other, but not on the same download. Doing both allows me to execute the app, so:
xattr -cr gdx-liftoff.app
chmod +x gdx-liftoff.app/Contents/MacOS/gdx-liftoff
Fixed it for me.

[tommyettinger]

I think I can look into the dollar-sign problem from here on Windows; it's challenging to get that right because there are multiple levels of escaping for all Kotlin string interpolation in Liftoff. There's the template itself, which is typically a triple-quoted Kotlin string. Interpolations in that look things up in Liftoff. Or, you can insert a dollar sign in the template, which is cumbersome, and have that resolve to an interpolation when the user opens their project. You might also need to enter an escaped dollar sign in the template so the user gets an escaped dollar sign and not an interpolation. Blurgh.

[tommyettinger]

It turned out to be a much simpler quoting issue -- I (or fourlastor, maybe?) had used single quotes when the version was hard-coded initially, and then I changed that to use projectVersion, but forgot to make it use double quotes. Single-quoted strings in Groovy don't perform string interpolation, but double-quoted ones do.

[badlogic]

@tommyettinger the issue here is that ZIP files do not retain file permissions. You need to distribute binaries for Linux and macOS using e.g. tar.gz which will work on Linux and macOS.

[fourlastor]

Yup! I'm planning on copying packr approach fourlastor-alexandria/construo#64

.zip in my experience retains permissions but not when you unzip it on windows

[badlogic]

Ah, yes, you are right. Silly old Mario brain.

…

On Fri, Aug 30, 2024 at 1:20 PM Daniele Conti ***@***.***> wrote: Yup! I'm planning on copying packr approach fourlastor-alexandria/construo#64 <fourlastor-alexandria/construo#64> .zip in my experience retains permissions but not when you unzip it on windows — Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5QBFKYF2JQ2ECQP2DWFLZUBIO5AVCNFSM6AAAAABMUIWY52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRQHEYDEMRRGE> . You are receiving this because you commented.Message ID: ***@***.***>

[PromanSEW]

Also can't open app on MacBook Pro M2, Mac OS Sonoma 14.6.1
Just "Unable to open program 'gdx-liftoff'"
I successfully started application by double-click standalone JAR file anyway

[tommyettinger]

Yep, we know now that the MacOS native package won't run out of the box, but the .jar will. Thank you. I'm pretty sure fourlastor is working on a new version of Construo, which Liftoff will use and projects it generates will use, that produces runnable .app files on MacOS.

[SonicGDX]

I know you said in the latest release notes that getting the .app to work was a serious hassle, but I tried building the liftoff M1 app myself just now and running it seems to work right out of the gate without needing to do anything on the command line (although, I did build it on the Mac itself). So maybe the issues have been fixed in the newer version of Construo?

Only issue I had while building is that if you build with JDK 21 (like the default Android Studio JDK), it seems you get a jlink error when attempting to build the package (looks like this is an issue for the Construo setup in general, as it was the same when I tried to package MacX64). You have to use JDK 17.

jlink version 21.0 does not match target java.base version 17.0

[fourlastor]

Building on your own mac will work (it always did), I did solve the issue with the executable flag not being set on windows, so it will also work building from windows. The main issue is that unless the app is signed, running it on another computer will require it to be either manually unquarantined, or to be downloaded with something that doesn't set the quarantine flag (for example, curl).

Re the jdk version: indeed you need to package it with the same jdk version as the one you're bundling

[SonicGDX]

Building on your own mac will work (it always did), I did solve the issue with the executable flag not being set on windows, so it will also work building from windows. The main issue is that unless the app is signed, running it on another computer will require it to be either manually unquarantined, or to be downloaded with something that doesn't set the quarantine flag (for example, curl).

Re the jdk version: indeed you need to package it with the same jdk version as the one you're bundling

Would it be possible to self-sign the app? That way it would still show a prompt when opening, but it could be resolved using the settings app without the need to use the terminal.

https://support.apple.com/en-us/102445

[fourlastor]

I think that's definitely something worth trying, but as of now, it will require a mac to sign the app, as construo itself isn't able to sign the app yet (it's an open issue, but not having an Apple computer myself to test it, it's going to take a while if I need to implement it myself).

On the other hand, given the scope of liftoff (open liftoff, generate project, close liftoff), it might not be worth the time spent trying to make it work.

[SonicGDX]

I think that's definitely something worth trying, but as of now, it will require a mac to sign the app, as construo itself isn't able to sign the app yet (it's an open issue, but not having an Apple computer myself to test it, it's going to take a while if I need to implement it myself).

Fair enough. Although, perhaps using a MacOS VM could work for testing? On Linux for example, there's https://github.com/kholia/OSX-KVM and https://github.com/quickemu-project/quickemu as options. To be fair though, they do look complicated to set up and may technically be against Apple TOS