Skip to content
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

[BUG] DMG installer on M1 macOS #4229

Open
duncdrum opened this issue Feb 8, 2022 · 16 comments
Open

[BUG] DMG installer on M1 macOS #4229

duncdrum opened this issue Feb 8, 2022 · 16 comments
Labels
installer macOS issues specific to macOS

Comments

@duncdrum
Copy link
Contributor

duncdrum commented Feb 8, 2022

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
Screenshot 2022-02-08 at 22 32 16

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)
@duncdrum duncdrum added installer macOS issues specific to macOS labels Feb 8, 2022
@adamretter
Copy link
Contributor

adamretter commented Feb 8, 2022

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
Copy link
Contributor Author

duncdrum commented Feb 8, 2022

@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
Copy link
Contributor

@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
Copy link
Contributor Author

duncdrum commented Feb 8, 2022

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
Copy link
Member

joewiz commented Feb 9, 2022

@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
Copy link
Member

joewiz commented Feb 9, 2022

@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?

@adamretter
Copy link
Contributor

adamretter commented Feb 9, 2022

@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
Copy link
Contributor Author

duncdrum commented Feb 11, 2022

@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
Copy link
Member

line-o commented Mar 23, 2022

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
Copy link
Member

line-o commented Mar 23, 2022

Reinstalling did not work.

@line-o
Copy link
Member

line-o commented Mar 23, 2022

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
Copy link
Member

line-o commented Mar 23, 2022

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

@duncdrum
Copy link
Contributor Author

@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
Copy link
Member

line-o commented Mar 23, 2022

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

@duncdrum
Copy link
Contributor Author

@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
Copy link
Member

line-o commented Mar 23, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
installer macOS issues specific to macOS
Projects
Status: Backlog
Development

No branches or pull requests

4 participants