[BUG] DMG installer on M1 macOS

[duncdrum]

Describe the bug
Installation via homebrew fails on macOS with M1 chip. Works fine on Intel with an otherwise identical setup. The provided warning about missing java 8 is false, Java 8 is present and JAVA_HOME is set correctly. (see below)

Expected behavior
Installation should succeed without hiccups.

To Reproduce

1. Run brew install exist-db
2. click on exist-db icon in application folder
3. confirm opening apps installed from the web
4. Java8 popup prevents installation

Screenshots

Context (please always complete the following information):

• OS: macOS 12.2
• eXist-db: 6.0.0
• Java Version: 1.8.0_322 (zulu)

Additional context

echo $JAVA_HOME                                                                         
~/.jenv/versions/1.8

java -version                                          
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Zulu 8.60.0.21-CA-macos-aarch64) (build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Zulu 8.60.0.21-CA-macos-aarch64) (build 25.322-b06, mixed mode)

[adamretter]

Sorry Duncan but we don't officially support M1 in eXist-db yet.

This specific component uses the AppBundler project for macOS and as such has native code that would have to be compiled separately for macOS on M1 (assuming AppBundler even supports M1 yet).

[duncdrum]

@adamretter this is not about compiling a native version for M1 Macs (which would be nice) but about the fact that exist can't be installed and run via rosetta, which should be supported.

exist thinks there is no compatible java version, but there is.

[adamretter]

@duncdrum Okay understood. The problem has the same cause though, i.e. the AppBundler, and whether it support Rosetta on M1 correctly or not. You should start by investigating if such configurations are yet supported correctly by AppBundler, and if not, then please open an issue with them - https://github.com/TheInfiniteKind/appbundler.

Once this is supported correctly by AppBundler and they have a release, it is relatively trivial to update the version of AppBundler used by eXist-db.

I will leave this open, so we can be reminded that we may need to update to a newer AppBundler depending on your findings.

[duncdrum]

well let's start with this one,
see TheInfiniteKind/appbundler#75
we also might need to adjust the hombrew file. We should also note that while macOS is officially supported, that doesn't include macOS on Apple Silicon.

[joewiz]

@duncdrum That issue links to a PR from 3 days ago that was merged 2 days ago by the appbundler lead: TheInfiniteKind/appbundler#81. Description of the commit:

Add arm64 for the native component

I think your observation comes at an opportune moment ;)

[joewiz]

@adamretter I seem to recall that appbundler doesn't publish proper releases. I think you've been publishing them to maven from the evolvedbinary fork, no?

• https://github.com/evolvedbinary/appbundler
• https://github.com/evolvedbinary/appbundler-maven-plugin

• exist/exist-distribution/pom.xml

  Lines 1041 to 1042 in 69d4961

  	<groupId>com.evolvedbinary.appbundler</groupId>
  	<artifactId>appbundler-maven-plugin</artifactId>

[adamretter]

@joewiz Indeed, I have been building and publishing versions from their source.

However we would need support in AppBundler for Rosetta (which is the issue that Duncan initially asked for), although his link is for native support. So perhaps I think we have two things here to consider:

1. Rosetta on M1 - which Duncan has reported as not working, but I don't see anything in the upstream AppBundler to address this. An issue should be raised there and we would look for the problem to be fixed there first.
2. Native M1 - it looks like there is some progress via the links you and Duncan have shared. If I read the issues and PRs correctly though, it sounds like they are unfinished and not yet completely working.

[duncdrum]

@adamretter i think you might be confusing rosetta with univeral binaries. Rosetta will kick in for any dmg on M1 that doesn't have a specific arm flag.

The issue i linked clearly shows that appbundler relied on hardcoded path when looking for JVM, that was arch specific. It now can look in both locations, which means exist build with the new app bundler should run on M1 without the erroneous "can't find JRE" warning.

If it ll trigger rosetta at all remains to be seen. It's possible that some extension rely on arch specific paths, but with a M1 compatible JRE, exist runs fine on M1. Obviously having universal binary dmg is the even better solution, but for now we should update appbundler so we have dmg that work on MacOS as is on the list of what's officially supported.

Check https://hub.docker.com/r/duncdrum/existdb/tags to see exist on arm in action

[line-o]

I can confirm that both work on M1:

• exist built from source
• the official DMG installed over home-brew (!)

The latter stopped working when I uninstalled some java versions. Maybe reinstalling it now does the trick or we need to find out how jenv is interfering here.

[line-o]

Reinstalling did not work.

[line-o]

I remember we had this issue in the past when the path that java was installed to changed. The location where Java runtimes are installed to changed in macOS 12 so I am very much in favour of trying to update to a newer version of appbundler.
What needs to happen for that?

[line-o]

I have also jenv installed and my JAVA_HOME is empty, BTW.

[duncdrum]

@line-o the paths are described in the appbundler issue linked above. We need an updated maven artefact for appbundler so we can use it properly detects Java for the dmg installs

[line-o]

@duncdrum have you tried something stupid, like symlinking your current Java installation to the requested path?

[duncdrum]

@line-o no I have working docker and local builds. The bug has been addressed upstream, I want to try their fix first, before doing silly dances

[line-o]

From looking at the fix just symlinking also would not work.