Not able to use dtcw on arm64 / apple silicone

[SimonCW]

Describe the bug
I'm not able to run the dtcw wrapper locally on my Mac.

For running the local version when running donwloadTemplate:

FAILURE: Build failed with an exception.

* Where:
Settings file '/Users/simon.weiss/.doctoolchain/docToolchain-2.2.1/settings.gradle'

* What went wrong:
Could not compile settings file '/Users/simon.weiss/.doctoolchain/docToolchain-2.2.1/settings.gradle'.
> startup failed:
  General error during semantic analysis: Unsupported class file major version 61

  java.lang.IllegalArgumentException: Unsupported class file major version 61

For running ./dtcw local generateSite I get the error that is probably connected to orient-db jbake-org/jbake#709:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':bake'.
> A failure occurred while executing org.jbake.gradle.impl.JBakeWorkAction
   > Can't load library: /var/folders/9l/s2lzkzbn2y98d96lgr8q961r0000gn/T/jna-1355430915/jna10246597454490203081.tmp

For running via docker, e.g. ./dtcw docker generateSite it just hangs and never responds. This might be because it needs to emulate the x86_64 architecture.

To Reproduce
Steps to reproduce the behavior:

1. Download dtcw
2. Run ./dtcw downloadTemplate or ./dtcw docker generateSiteon Mac M1

I also tried it with the arch -x86_64 /bin/bash like outlined in the help message, however, this didn't help.

Expected behavior
Generating output files, downloading template, etc

Configuration

• docToolchain version 2.2.1
• OS: MacOS
• Relevant SDK Versions:

openjdk 11.0.17 2022-10-18
OpenJDK Runtime Environment Temurin-11.0.17+8 (build 11.0.17+8)
OpenJDK 64-Bit Server VM Temurin-11.0.17+8 (build 11.0.17+8, mixed mode)

Additional context
Relevant issue outlining the problem with orient-db in jbake repo: jbake-org/jbake#709.
Proposed solution is to update jbake: jbake-org/jbake#709 (comment)

Linking other, similar issues to avoid too many duplicated issues: #1015
Docker related (not providing an arm image): docToolchain/docker-image#26

[SimonCW]

Proposed solution(s):

• Update jbake (JBake fails to run or build on Apple Silicon jbake-org/jbake#709 (comment))
• To fix docker, I propose to switch to a base image that supports arm after the above is fixed, e.g., eclipse-temurin:11-jdk-jammy, see https://hub.docker.com/_/eclipse-temurin/tags?page=1&name=11-jdk.

I'd create a PR, but I have no idea about Java 😃

[rdmueller]

we are already working on a multi-platform docker image, but it will still take some time.

regarding jBake, I haven't identified it as a problem yet. Your error messages look more like wrong java version / wrong java binaries.

Please try the following:

• start a shell within the emulator: arch -x86_64 /bin/bash
• install the correct jdk: ./dtcw getJava
• retry to use docToolchain

currently, dtcw doesn't check the architecture of the installed jdk. It will be installed to your home folder, in a subdirectory called .doctoolchain. So if you install it within the emulator, you will get a different jdk than outside. And if you will try to use it outside, you will run into problems because of the wrong binaries.

PS: do you know the difference between eclipse-temurin:11-jdk and eclipse-temurin:11-jdk-jammy?

[SimonCW]

I am relatively convinced that the > Can't load library: /var/folders/9l/s2lzkzbn2y98d96lgr8q961r0000gn/T/jna-1355430915/jna10246597454490203081.tmp error (that I get for generateSite) is related to jbake and the outdated orient-db version that does not support arm64. See this discussion: jbake-org/jbake#709 (comment).

Do you anticipate high efforts for updating jbake? To my naive mind it seems like an easy fix/experiment. If not, I'm happy to test a branch on my machine.

I have already tried with arch -x86_64 /bin/bash and getJava with no success. But I'll retry and report the exact error here.

Concerning Docker:
Oh, I just pushed a WIP Pull Request for a docker image: docToolchain/docker-image#42. The image builds, but I haven't tested it yet.

Jammy is the newest LTS Ubuntu version (22.04)(see https://wiki.ubuntu.com/Releases). But that is also what eclipse-temurin:11-jdk uses. I would have to check the Dockerfiles for these images.
In the PR above, I use focal (has full support until April 2025) because jammy is so new that a few packages are missing.

[mh182]

#1073 should catch errors reported like this one.

[rdmueller]

Thanx for the PR! I will check it asap.

Regarding the jbake upgrade: yes, let's test the new version

[SimonCW]

Update on running through Rosetta with arch -x86_6h:
It fails with the same error (likely related to jbake and orient-db) upon running generateSite:
Note, I'm running the command through arch directly because spawning bash was even wors b/c not all child-processes honor the arch.

I also noticed that running getJava through Rosetta will still download the arm64 / aarch64 version:

[SimonCW]

This whole thing is quite unfortunate, and it seems to me that the root of the problem is jbake relying on orient-db.

From the release notes it seems the latest jbake uses the newer orient-db release but doesn't work with macos and jdk-11. It might work with jdk-8, but that is not tested for jbake so I'm not hopeful: https://github.com/jbake-org/jbake/blob/master/.travis.yml

[rdmueller]

I just executed the following commands on my M2 with success:

arch
arch -x86_64 /bin/zsh
arch
./dtcw getJava
./dtcw local generateSite

it could be that the local option is the important point here. Can you please try to execute exactly these statements?

[rdmueller]

hm. interesting to read that there are problems with jdk11...

[SimonCW]

Executing the exact same statements did not work:

Weirdly, arch outputs i386 (32bit) but I have found reports from other Mac users that say the same. I also noticed in the output above that it would still detect as aarch64 and also print the "it seems you try to run [...] on M1" Statement.

In the dtcw wrapper arch is assigned based on uname -m which still shows "arm64" for me, even if arch shows "i386".

docToolchain/dtcw

Line 57 in c34f2da

arch=$(uname -m)

This little "hack" in dtcw solved it for me 😮‍💨:

if [ "$(arch)" == "i386" ]; then
  arch="x86_64"
else 
  arch=$(uname -m)
fi

Now, with the modified dtcw script, I can generate the site with:

arch -x86_64 /bin/zsh
./dtcw getJava
./dtcw local generateSite

I'm happy that I can iterate on my documentation for now. Thank you for sticking with me and taking the time @rdmueller! I think there should be a less brittle solution for doctoolchain though 😃. I could still submit a PR with the "hack" if you like @rdmueller?

[SimonCW]

I encountered another Problem that might be related to this one:
./dtcw local generateSite works with the local Java version from getJava, however, when running ./dtcw autobuildSite, it complains repeatedly about the wrong Java version.

[rdmueller]

great that you found the problem. I wonder why uname behaves like this. In my case, I get

arch -x86_64 /bin/zsh
uname -m
x86_64

I would be happy if you could submit this as PR, but please mark it as DRAFT. I will then check the behaviour of the arch command on my windows machine to verify that it does not break something.

[mh182]

I encountered another Problem that might be related to this one: ./dtcw local generateSite works with the local Java version from getJava, however, when running ./dtcw autobuildSite, it complains repeatedly about the wrong Java version.

What happens if you use ./dtcw local autobuildSite? Does it work?

It sounds similar to the problem reported with #1031. dtcw picks the wrong Java version depending on your system setup. I'm currently working on this.

[SimonCW]

@mh182 , yes, sorry, I was using ./dtcw local autobuildSite just forgot the local.

[rdmueller]

hm. the original idea was that you don't need to add local when you once installed docToolchain locally. But it seems there is some bug.

[mh182]

hm. the original idea was that you don't need to add local when you once installed docToolchain locally. But it seems there is some bug.

The program flow of the existing dtcw using 6 different boolean flags is hard to understand and error-prone. Yes, it is meant to use local by default if it is installed.

That was the main reason to refactor dtcw with #1031.

[SimonCW]

I assume the idea of a bash script was to make dtcw easy to get started without having to install dependencies first. However, I think it has grown a little complex and it is missing the usual amenities of CLIs (--help, tab completion, etc). Why not rewrite it in groovy? (Note, I have no idea about the JVM ecosystem, I'd personally do it in Python but it is probably a bad idea to additionally depend on Python).

[mh182]

The wrapper script provides easy means to bootstrap docToolchain from a project repository.

If you have docToolchain already installed and working, it doesn't provide much benefit. You probably are better of to use whatever "build tool" to call docToolchain directly.

But we already have a discussion about this in #1076.

[mh182]

From #1084 (comment)

So, regarding the answer of chatgpt, uname -m is the wrong thing to do and it should always reflect the hardware architecture not the one of the emulator?

I think is more complicate than asking ChatGPT. The main problem is we have a multitude of OS and configuration settings. As far as I understood, the root cause of the bug was that uname -m (in the Rosetta simulator) mapped, for whatever reason (probably due an Homebrew installation of a 32 bit bash), to i386 instead to x86_64.

If we just map i386 to x86_64 without taking into account the operating system (darwin) we may break the setup in in other environments (Linux systems with 32 bit libraries?).

I would rather like to know what caused uname -m to i386 and fix that than making a strange hack just for a single person. In case more people have the same problem, we still could figure out how to integrate "this fix" to provide a good user experience.