Failure on MacBook M1

Question

Failure on MacBook M1

muthenberg opened this issue 4 years ago · 27 comments

Hi,

I tried to build our software using the H3 library on a new MacBook M1. Unfortunately I do get the following error:

java.lang.UnsatisfiedLinkError: No native resource found at /darwin-arm64/libh3-java.dylib at com.uber.h3core.H3CoreLoader.copyResource(H3CoreLoader.java:68) at com.uber.h3core.H3CoreLoader.loadNatives(H3CoreLoader.java:120) at com.uber.h3core.H3CoreLoader.loadNatives(H3CoreLoader.java:89) at com.uber.h3core.H3Core.newInstance(H3Core.java:79)

I already found out that this is because there simply is no native library for the combination of operating system (darwin) and architecture (arm64). So my questions are: Is a fix already planned? Is there a workaround?

Answer 1 · 2021-03-05T13:45:39.000Z

Never mind. I guess I found my answer. I tried to build my own binary, but since gcc for the MacBook M1 is supposedly going to arrive mid 2021, this seems to be impossible at the moment. So I guess we'll have to wait a little bit, before we can use h3 on the new processor architecture.

Answer 2 · 2021-03-05T17:41:06.000Z

While we don't have support for this combination in our pre-built artifacts, it should be possible to build the artifact yourself using mvn install from this repo. (This may require some fixes to get the library to place the built shared object in the right place) I believe it should be possible to build with Clang, are you able to post the output of mvn install?

Answer 3 · 2021-03-09T12:32:28.000Z

Hm. Currently I am experiencing the following problems from your test suite, while running mvn install

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.uber.h3core.TestH3CoreSystemInstance
java.lang.instrument.IllegalClassFormatException: Error while instrumenting sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo.
	at org.jacoco.agent.rt.internal_035b120.CoverageTransformer.transform(CoverageTransformer.java:93)
	at java.instrument/java.lang.instrument.ClassFileTransformer.transform(ClassFileTransformer.java:246)
	at java.instrument/sun.instrument.TransformerManager.transform(TransformerManager.java:188)
	at java.instrument/sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:563)
	at java.base/java.lang.ClassLoader.defineClass2(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1108)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:183)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:784)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:705)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:586)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:634)
	at java.base/java.lang.Class.forName(Class.java:546)
	at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:854)
	at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1078)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1301)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1386)
	at java.base/sun.util.cldr.CLDRLocaleProviderAdapter$1.run(CLDRLocaleProviderAdapter.java:89)
	at java.base/sun.util.cldr.CLDRLocaleProviderAdapter$1.run(CLDRLocaleProviderAdapter.java:86)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:554)
	at java.base/sun.util.cldr.CLDRLocaleProviderAdapter.<init>(CLDRLocaleProviderAdapter.java:86)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
	at java.base/java.text.DecimalFormatSymbols.getInstance(DecimalFormatSymbols.java:180)
	at java.base/java.util.Formatter.getZero(Formatter.java:2437)
	at java.base/java.util.Formatter.<init>(Formatter.java:1956)
	at java.base/java.util.Formatter.<init>(Formatter.java:1978)
	at java.base/java.lang.String.format(String.java:3292)
	at org.junit.runner.Description.formatDisplayName(Description.java:114)
	at org.junit.runner.Description.createTestDescription(Description.java:86)
	at org.junit.runners.BlockJUnit4ClassRunner.describeChild(BlockJUnit4ClassRunner.java:121)
	at org.junit.runners.BlockJUnit4ClassRunner.describeChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:401)
	at org.junit.runners.model.RunnerBuilder.configureRunner(RunnerBuilder.java:81)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:72)
	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
	at org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
	at org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:250)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.io.IOException: Error while instrumenting sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo.
	at org.jacoco.agent.rt.internal_035b120.core.instr.Instrumenter.instrumentError(Instrumenter.java:158)
	at org.jacoco.agent.rt.internal_035b120.core.instr.Instrumenter.instrument(Instrumenter.java:108)
	at org.jacoco.agent.rt.internal_035b120.CoverageTransformer.transform(CoverageTransformer.java:91)
	... 55 more
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 59
	at org.jacoco.agent.rt.internal_035b120.asm.ClassReader.<init>(ClassReader.java:195)
	at org.jacoco.agent.rt.internal_035b120.asm.ClassReader.<init>(ClassReader.java:176)
	at org.jacoco.agent.rt.internal_035b120.asm.ClassReader.<init>(ClassReader.java:162)
	at org.jacoco.agent.rt.internal_035b120.core.internal.instr.InstrSupport.classReaderFor(InstrSupport.java:279)
	at org.jacoco.agent.rt.internal_035b120.core.instr.Instrumenter.instrument(Instrumenter.java:74)
	at org.jacoco.agent.rt.internal_035b120.core.instr.Instrumenter.instrument(Instrumenter.java:106)
	... 56 more
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.167 sec <<< FAILURE!
initializationError(com.uber.h3core.TestH3CoreSystemInstance)  Time elapsed: 0.021 sec  <<< ERROR!
java.util.ServiceConfigurationError: Locale provider adapter "CLDR"cannot be instantiated.
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258)
	at java.base/java.text.DecimalFormatSymbols.getInstance(DecimalFormatSymbols.java:180)
	at java.base/java.util.Formatter.getZero(Formatter.java:2437)
	at java.base/java.util.Formatter.<init>(Formatter.java:1956)
	at java.base/java.util.Formatter.<init>(Formatter.java:1978)
	at java.base/java.lang.String.format(String.java:3292)
	at org.junit.runner.Description.formatDisplayName(Description.java:114)
	at org.junit.runner.Description.createTestDescription(Description.java:86)
	at org.junit.runners.BlockJUnit4ClassRunner.describeChild(BlockJUnit4ClassRunner.java:121)
	at org.junit.runners.BlockJUnit4ClassRunner.describeChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:401)
	at org.junit.runners.model.RunnerBuilder.configureRunner(RunnerBuilder.java:81)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:72)
	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
	at org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
	at org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:250)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
	at java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188)
	... 30 more
Caused by: java.util.ServiceConfigurationError: sun.util.locale.provider.LocaleDataMetaInfo: Unable to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:584)
	at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:856)
	at java.base/java.util.ServiceLoader$ModuleServicesLookupIterator.hasNext(ServiceLoader.java:1078)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1301)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1386)
	at java.base/sun.util.cldr.CLDRLocaleProviderAdapter$1.run(CLDRLocaleProviderAdapter.java:89)
	at java.base/sun.util.cldr.CLDRLocaleProviderAdapter$1.run(CLDRLocaleProviderAdapter.java:86)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:554)
	at java.base/sun.util.cldr.CLDRLocaleProviderAdapter.<init>(CLDRLocaleProviderAdapter.java:86)
	... 36 more
Caused by: java.lang.LinkageError: loader 'platform' attempted duplicate class definition for sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo. (sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo is in module jdk.localedata of loader 'platform')
	at java.base/java.lang.ClassLoader.defineClass2(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1108)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:183)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:784)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:705)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:586)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:634)
	at java.base/java.lang.Class.forName(Class.java:546)
	at java.base/java.util.ServiceLoader.loadProvider(ServiceLoader.java:854)
	... 43 more

Running com.uber.h3core.TestH3Core
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.353 sec
Running com.uber.h3core.util.TestGeoCoord
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec <<< FAILURE!
testToString(com.uber.h3core.util.TestGeoCoord)  Time elapsed: 0.011 sec  <<< FAILURE!
java.lang.AssertionError
	at org.junit.Assert.fail(Assert.java:87)
	at org.junit.Assert.assertTrue(Assert.java:42)
	at org.junit.Assert.assertTrue(Assert.java:53)
	at com.uber.h3core.util.TestGeoCoord.testToString(TestGeoCoord.java:58)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

Running com.uber.h3core.util.TestCoordIJ
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running com.uber.h3core.TestIndexing
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec
Running com.uber.h3core.TestBindingCompleteness
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.096 sec
Running com.uber.h3core.TestTraversal
Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.342 sec
Running com.uber.h3core.TestInspection
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running com.uber.h3core.TestHierarchy
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec
Running com.uber.h3core.TestH3CoreLoader
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running com.uber.h3core.TestNativeMethods
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running com.uber.h3core.TestUnidirectionalEdges
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running com.uber.h3core.TestRegion
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.034 sec

Results :

Failed tests:   testToString(com.uber.h3core.util.TestGeoCoord)

Tests in error: 
  initializationError(com.uber.h3core.TestH3CoreSystemInstance): Locale provider adapter "CLDR"cannot be instantiated.

Tests run: 111, Failures: 1, Errors: 1, Skipped: 0

Answer 4 · 2021-03-09T13:38:03.000Z

Did you change anything? I was restarting it today using Rosetta and in contrast to last week it just worked. Rosetta would be sufficient for me for the moment, although having a version working natively on Apple Silicon soon, would be even better. ;)

Answer 5 · 2021-06-25T06:34:51.000Z

Can you fix this issue？ I also had this problem on MacBook M1. With the popularity of M1 chip, more and more people may encounter this problem. So please fix it as soon as possible.

Answer 6 · 2021-06-25T18:16:08.000Z

Unfortunately I don't have an M1 machine available to produce binaries with, and I don't have a cross compilation setup available. We use dockcross for non-Mac builds, but dockcross doesn't support targeting Mac. If Github Actions adds support for M1 that would be the best solution (actions/runner-images#2187) since then we could grab the built artifact from there. Alternately I'll have to look into getting access to an M1 based box. Please let me know if you know of a cross compilation approach that we could integrate.

In the mean time, H3-Java should be usable through Rosetta (per above). It should also be possible to compile from source yourself for M1, although I gather you may need to skip tests with mvn install -DskipTests. I'm not sure why skipping that is necessary, it looks like a JVM/instrumentation issue that doesn't reproduce on other architectures.

Answer 7 · 2021-08-30T13:41:02.000Z

BTW.: If I try to build the newest version (commit #661bea1) with mvn clean install I get:

[INFO] ...
[INFO]
[INFO] -- Configuring done
[INFO] -- Generating done
[INFO] -- Build files have been written to: /work/target/h3-java-build-linux-arm64
[INFO] + make h3-java
[INFO] [ 50%] Building C object CMakeFiles/h3-java.dir/src/jniapi.c.o
[INFO] In file included from /work/src/main/c/h3-java/src/jniapi.c:19:
[INFO] /work/src/main/c/h3-java/src/com_uber_h3core_NativeMethods.h:2:10: fatal error: jni.h: No such file or directory
[INFO]     2 | #include <jni.h>
[INFO]       |          ^~~~~~~
[INFO] compilation terminated.
[INFO] make[3]: *** [CMakeFiles/h3-java.dir/build.make:76: CMakeFiles/h3-java.dir/src/jniapi.c.o] Error 1
[INFO] make[2]: *** [CMakeFiles/Makefile2:83: CMakeFiles/h3-java.dir/all] Error 2
[INFO] make[1]: *** [CMakeFiles/Makefile2:90: CMakeFiles/h3-java.dir/rule] Error 2
[INFO] make: *** [Makefile:124: h3-java] Error 2
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:08 min
[INFO] Finished at: 2021-08-30T15:38:00+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1.1:exec (build-h3-c) on project h3: Result of /bin/sh -c cd /Users/muthmann/Development/h3-java && /Users/muthmann/Development/h3-java/src/main/c/h3-java/build-h3.sh https://github.com/uber/h3.git v3.7.2 true false execution is: '2'. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

It seems that the system tries to build H3 for Linux ARM64, which will obviously not work. Unfortunately my Make knowledge is not great enough to fix that issue.

Answer 8 · 2021-08-31T07:55:35.000Z

Maybe as an addendum. I am not verify proficient with MacOS, since I have worked for years on an Ubuntu Machine and was forced to switch to do iOS Development. However I noticed that you need to be careful on how the JDK is installed for H3 to use Rosetta. Simply starting a Terminal with Rosetta 2 does not necessarily guarantee that Java is also executed with Rosetta 2. It tried two ways of installing Java. The first was using Homebrew and the other was using an installer to install the Azul OpenJDK. Using Azul I was not able to work with H3 anymore since it always seems to run without Rosetta. Funny enough after installing Azul Gradle and the Terminal used it but Maven was still on the Homebrew JDK. So everything worked under Maven but not with Gradle or directly from the terminal.

I got it to work again by removing the Azul JDK (just sudo rm -rf inside of /Library/Java/JavaVirtualMachines/) and reinstalling the homebrew JDK with brew install. I think that my Java now always runs using Rosetta 2. This is not ideal but a fix or workaround will have to wait for another day.

Answer 9 · 2021-08-31T15:01:50.000Z

@muthenberg Would you be able to upload a complete build log to Gist?

I think the issue you are running into may be due to the Docker cross compiling failing (it needs to use a JNI header from the host platform.) Please try instead mvn clean install -Dh3.use.docker=false

Could you also post the output of uname -sm? The file build-h3.sh may need to be updated to put the library in the right place. Probably something like adding:

   "Darwin arm64") LIBRARY_DIR=darwin-arm64 ;;

(There's also the possibility that H3CoreLoader.java will need a small update to detect the right library to load. If that's the case you should be able to use H3Core.newInstance(H3CoreLoader.OperatingSystem.DARWIN, "arm64") as a workaround.)

Answer 10 · 2021-09-07T13:29:36.000Z

Hi,

Sorry. It took a while for me to come around to this again. Here is the build.log.

The output of uname -sm is: Darwin arm64

If I build using mvn clean install -Dh3.use.docker=false tests are failing. I tried by adding -DskipTests which provides a successful build. However I am sceptical, when I can not run the tests.

Answer 11 · 2021-10-29T01:17:35.000Z

@isaacbrodsky local build is working fine now but I’m not sure how I can help you do cross architecture build with Darwin x86, M1, and the rest and then release to public artifact?

This should help developers to install uber-h3 easily.

Answer 12 · 2021-11-02T19:31:53.000Z

I am also on M1 mac with Monterey macOs. I have a gradle project, that uses the com.uber:h3:3.4.1 lib. I've managed to build the libs locally via mvn clean install -Dh3.use.docker=false and I see that the new libs (3.7.2) were copied into my .m2 repository. I am not that proficient with dependencies, so would you be able to explain, where should I put these jars so my gradle project in Intellij could use them? @isaacbrodsky thanks

upd: I managed to make gradle (with this recommendation) to use the lib from my .m2 and my build ran successfully. Thanks a lot @muthenberg for raising the issue and @isaacbrodsky for fixing it :)

I hope the lib for arm will be soon published to the maven repository.

Answer 13 · 2021-12-01T19:42:58.000Z

So the fix for M1 seems to have been commited since late October, is there any idea when a new release will be published? would be helpful to stop having to use a snapshot version from my own local repo.

Answer 14 · 2021-12-01T19:48:09.000Z

So the fix for M1 seems to have been commited since late October, is there any idea when a new release will be published? would be helpful to stop having to use a snapshot version from my own local repo.

Unfortunately I don't have a way to generate M1 artifacts for the release - in part due to not having an M1 laptop myself - so still looking for some kind of cross compiling approach. If you have any suggestions for that please let me know.

Answer 15 · 2021-12-01T19:53:57.000Z

I'm on an M1, let me know if I can help.

Answer 16 · 2021-12-02T17:35:31.000Z

We can try some cross compiling instructions: actions/runner-images#2187 (comment)
And it looks like AWS is starting to offer M1 support: https://aws.amazon.com/blogs/aws/use-amazon-ec2-m1-mac-instances-to-build-test-macos-ios-ipados-tvos-and-watchos-apps/

Answer 17 · 2022-02-07T22:02:16.000Z

v3.7.2 should now be released to Maven Central which should include the darwin-arm64 binary!

Answer 18 · 2022-02-08T03:37:30.000Z

v3.7.2 should now be released to Maven Central which should include the darwin-arm64 binary!

Great news and thanks for the help! Much appreciate!

Answer 19 · 2022-02-09T07:21:08.000Z

Hey, I've tried the v3.7.2 and it seems to me it works fine on M1. However, I can not get my tests green on CI, here is what I am getting:

12:43:11 ScalaTest can't report this exception because another preceded it, so printing its stack trace:
12:43:11 java.lang.UnsatisfiedLinkError: /tmp/libh3-java5628092703928514548.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/libh3-java5628092703928514548.so)
12:43:11 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
12:43:11 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
12:43:11 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
12:43:11 	at java.lang.Runtime.load0(Runtime.java:810)
12:43:11 	at java.lang.System.load(System.java:1086)
12:43:11 	at com.uber.h3core.H3CoreLoader.loadNatives(H3CoreLoader.java:129)
12:43:11 	at com.uber.h3core.H3CoreLoader.loadNatives(H3CoreLoader.java:96)
12:43:11 	at com.uber.h3core.H3Core.newInstance(H3Core.java:79)

Although the test itself passes on Macbook on Intel chip. Any ideas what's going on? @isaacbrodsky

upd: v3.7.0 works just fine on CI, so there is something wrong with v3.7.2 or with my CI configuration
v.3.7.1 also has the error above.

My CI runs on Ubuntu 16.04. I did a little googling and found this:

ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11.3) 2.23

Does this mean I can not run v3.7.2 on Ubuntu 16.04?

Answer 20 · 2022-02-09T09:14:31.000Z

I have the same issue on our CI with 3.7.2, works fine running but fails compilation on Jenkins.

Answer 21 · 2022-02-09T10:49:21.000Z

v3.7.2 should now be released to Maven Central which should include the darwin-arm64 binary!

Great news! Thanks a lot

Answer 22 · 2022-02-09T16:01:49.000Z

@g-derzhavets didn't Ubuntu 16.04 enter EOL last year?

If you build h3-java from source on that machine and use that version it will probably work, but that is a pretty old glibc version.

Answer 23 · 2022-02-09T16:04:16.000Z

@g-derzhavets didn't Ubuntu 16.04 enter EOL last year?

Yes, it did :) But, as I understand, even the 18.04 will not work, as the GLIBC there is 2.27 :( Ok, I guess, we should update our stack, thanks

Answer 24 · 2022-02-09T16:06:07.000Z

@g-derzhavets

Does this mean I can not run v3.7.2 on Ubuntu 16.04?

I believe this is the same issue as #85 and #88. While I can take a look at pinning dockcross to a far back enough version, Ubuntu 16.04 is out of standard support so I would suggest upgrading to the latest LTS if possible.

Answer 25 · 2022-02-09T16:11:23.000Z

Ok, will try, thank you guys for the quick reaction!