Intel binary in ARM library

[mipastgt]

Describe the bug
I wrote a Compose desktop app and packaged it via packageReleaseDMG on my new M2 Mac. I found that the macos-arm64 program version is significantly larger than its counterpart the macos-x64 version. The reason seems to be that the packaged file skiko-awt-runtime-macos-arm64-0.7.84-1e92ab4aabb1afd297bcab887391fff3.jar contains the full libskiko-macos-x64.dylib which has a size of 21.2 MB whereas the file skiko-awt-runtime-macos-x64-0.7.84-f8e39281aa3161a7291461b299955670.jar only contains a few bytes of metadata. Why does the ARM version of the skiko-awt-runtime contain this Intel binary? Is there any reason for that or is it just a bug?

Affected platforms
Select one of the platforms below:

• Desktop (macOS arm64 bot not x86)

Versions

• Kotlin version*: 1.9.20-Beta2
• Compose Multiplatform version*: 1.5.10-rc01
• OS version(s)* (required for Desktop and iOS issues): macOS 14 Sonoma
• OS architecture (x86 or arm64): arm64
• JDK (for desktop issues): Temurin 17

[dima-avdeev-jb]

Are you using X86_x64 JDK?
Can you please execute command /usr/libexec/java_home -V
And paste result here

[mipastgt]

mpaus@MinivonMichael ~ % /usr/libexec/java_home -V
Matching Java Virtual Machines (3):
    21 (arm64) "Eclipse Adoptium" - "OpenJDK 21" /Library/Java/JavaVirtualMachines/jdk-21+35/Contents/Home
    17.0.9 (arm64) "Eclipse Adoptium" - "OpenJDK 17.0.9" /Library/Java/JavaVirtualMachines/jdk-17.0.9+9/Contents/Home
    11.0.20.1 (arm64) "Eclipse Adoptium" - "OpenJDK 11.0.20.1" /Library/Java/JavaVirtualMachines/jdk-11.0.20.1+1/Contents/Home
/Library/Java/JavaVirtualMachines/jdk-21+35/Contents/Home
mpaus@MinivonMichael ~ % 

And this is the one that actually gets used for packaging the app

mpaus@MinivonMichael ~ % echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk-17/Contents/Home

according to

compose.desktop {
    application {
        mainClass = "MainKt"
        javaHome = System.getenv("JAVA_HOME")
        ...
    }
}
int the `build.gradle.kts` file.

[mipastgt]

I probably should add that the created binary actually works as expected and is not broken. The Intel lib is just not needed as far as I can tell. The app bundle also contains the correct version of the shared library but outside of the jar file.

The logs also seem to confirm this

2023-10-27T16:55:13.341+0200 [main] INFO ModelBridgeImpl - java.vm.name: OpenJDK 64-Bit Server VM
2023-10-27T16:55:13.342+0200 [main] INFO ModelBridgeImpl - java.runtime.version: 17.0.9+9
2023-10-27T16:55:13.342+0200 [main] INFO ModelBridgeImpl - os.arch: aarch64
2023-10-27T16:55:13.342+0200 [main] INFO ModelBridgeImpl - java.vendor: Eclipse Adoptium

although I don't know what the output would be if I'd run an Intel version via Rosetta 2 on an ARM machine.

[dima-avdeev-jb]

Are this Issue appears only at 1.5.10-rc01 ?
Are you tried to check with stable version 1.5.3 ?

[dima-avdeev-jb]

It reproduced also with command ./gradlew package
Binaries will be placed in build/compose/binaries/main/app/.../Contents/app/skiko-awt-runtime-macos-arm64-....jar
It contains libskiko-macos-x64.dylib on Compose versions 1.5.10-rc01 and stable 1.5.3 as well.

I don't know for now is it bug, or not. Maybe it needs to correct work with X64 system. We will check it.

[dima-avdeev-jb]

Added reproducer with bash script to check: https://github.com/dima-avdeev-jb/issue-3859-arm-x86-binaries

[mipastgt]

I am glad you could reproduce it. I was already affraid it could have been a mistake on my side :-)

[mipastgt]

FWIW, I just manually removed the strange Intel version of libskiko-macos-x64.dylib and the checksum file from the ARM jar file inside the app folder and the application still works without problems.

[mipastgt]

Any news on that?

I should add, in additon to my statement in the previous comment, that, although the app still works with the above mentioned removal of the lib and the checksum file, the Mac will refuse to install the resulting installer on any foreign machine. This makes this bug so annoying.

[dima-avdeev-jb]

Any news on that?

I should add, in additon to my statement in the previous comment, that, although the app still works with the above mentioned removal of the lib and the checksum file, the Mac will refuse to install the resulting installer on any foreign machine. This makes this bug so annoying.

I think it is because of signing process.
Sorry, but no news yet.

[m-sasha]

The reason seems to be this:

[m-sasha]

@olonho @AlexeyTsvetkov It was added in JetBrains/skiko#445. Do you know whether it's still needed?

[mipastgt]

The change was merged from a branch named "universal-macos". Maybe there once was the idea to be able to create universal mac apps which can run on both architectures but that would also require that all other binaries exist in a universal form which isn't the case. Also the location of the two libs seems to be inconsistent now. Even for the native Intel variant this library is not located inside the jar anymore. It would also be interesting to know what kind of "compatibility" is meant here. I am not aware of anything that would require a native Intel lib on an ARM Mac especially as it is the only one.

[m-sasha]

So the reason for this inclusion is to allow building (fake) "universal" binaries that use an x86 JVM and therefore can run on both Intel and Apple Silicon Macs. It also turns out that this is currently the only way to get your app published on the Mac App store, as it won't accept ARM-only apps.

Ideally, we should be able to build real universal apps, but we're blocked by jpackage, which currently can't do that. This is pretty bad, because it means such apps will run emulated on arm64.

Barring that, I think one way to solve this would be to publish skiko-x86, skiko-arm64 and skiko-universal. The latter can be used specifically when building for the "universal" use-case.

[mipastgt]

I do not really understand what you are saying. How are my own ARM libraries executed then? How is this "universal" use-case triggered? And if you have to use an x86 JVM anyway in that universal case why don't you just build a pure x86 app then. (My x86-only Compose desktop app works nicely via Rosetta 2 on an M2 Mac.) What are the ARM parts then good for? At least there should be a configuration option to get rid of that duplicate library. I don't understand why, on the one hand we are going through the pain of using ProGuard to shrink our packages and on the other hand just waste 21 MB here.

[m-sasha]

How is this "universal" use-case triggered?

By building an app on an ARM Mac using an x86 JVM.

And if you have to use an x86 JVM anyway in that universal case why don't you just build a pure x86 app then. (My x86-only Compose desktop app works nicely via Rosetta 2 on an M2 Mac.)

You could do that. I imagine it would run even slower on ARM Macs, however.

I don't understand why, on the one hand we are going through the pain of using ProGuard to shrink our packages and on the other hand just waste 21 MB here.

I'm with you here - I also want to get rid of the extra 21MB. I'm just describing the situation and the options we have.

[mipastgt]

But I am building an app on an ARM Mac and also use an ARM JVM and still seem to trigger that "universal" use-case.

By the way, running the app via Rosetta 2 is not much slower than the native ARM variant which is probably due to the fact that Rosetta 2 is not an emulator but rather a transpiler.

[m-sasha]

You're not triggering anything. The skiko jar for macos-arm is prebuilt and distributed with the x86 binary.

[mipastgt]

Could this #4271 be a route to fix the root problem of this issue? It seems that if you set the macOS minimum version to 12, you can upload a pure ARM version to the AppStore and thus the trick with the duplicate Intel library is not needed anymore.

[dima-avdeev-jb]

It seems that if you set the macOS minimum version to 12, you can upload a pure ARM version to the AppStore and thus the trick with the duplicate Intel library is not needed anymore.

@mipastgt Yes - looks like this

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.