sbt-sassify broken on Apple Silicon M1 + Big Sur

[bpossolo]

I'm seeing a JNA library loading issue on my MacBookAir with Apple Silicon (M1) + Big Sur.

Here is my full setup:

• Big Sur 11.2.1
• sbt 1.4.7
• scala 2.13.5
• PlayFramework 2.8.7
• OpenJDK 11.0.9+11 (/opt/homebrew/Cellar/openjdk@11/11.0.9/libexec/openjdk.jdk/Contents/Home)
• sbt-sassify 1.5.1

Here's the full stack trace when running last sassify

[info] Sass compiling on 24 source(s)
[error] java.lang.UnsatisfiedLinkError: /Users/benjamin/Library/Caches/JNA/temp/jna17537362502519181591.tmp: dlopen(/Users/benjamin/Library/Caches/JNA/temp/jna17537362502519181591.tmp, 1): no suitable image found.  Did find:
[error] 	/Users/benjamin/Library/Caches/JNA/temp/jna17537362502519181591.tmp: no matching architecture in universal wrapper
[error] 	/Users/benjamin/Library/Caches/JNA/temp/jna17537362502519181591.tmp: no matching architecture in universal wrapper
[error] 	at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
[error] 	at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
[error] 	at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
[error] 	at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
[error] 	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
[error] 	at java.base/java.lang.Runtime.load0(Runtime.java:768)
[error] 	at java.base/java.lang.System.load(System.java:1837)
[error] 	at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
[error] 	at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
[error] 	at com.sun.jna.Native.<clinit>(Native.java:195)
[error] 	at org.irundaia.sass.SassCompiler$.<init>(SassCompiler.scala:28)
[error] 	at org.irundaia.sass.SassCompiler$.<clinit>(SassCompiler.scala)
[error] 	at org.irundaia.sbt.sass.SbtSassify$.$anonfun$baseSbtSassifySettings$10(SbtSassify.scala:100)
[error] 	at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:285)
[error] 	at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62)
[error] 	at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55)
[error] 	at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49)
[error] 	at scala.collection.TraversableLike.map(TraversableLike.scala:285)
[error] 	at scala.collection.TraversableLike.map$(TraversableLike.scala:278)
[error] 	at scala.collection.AbstractTraversable.map(Traversable.scala:108)
[error] 	at org.irundaia.sbt.sass.SbtSassify$.$anonfun$baseSbtSassifySettings$8(SbtSassify.scala:100)
[error] 	at com.typesafe.sbt.web.incremental.package$.syncIncremental(package.scala:228)
[error] 	at org.irundaia.sbt.sass.SbtSassify$.$anonfun$baseSbtSassifySettings$6(SbtSassify.scala:140)
[error] 	at scala.Function1.$anonfun$compose$1(Function1.scala:49)
[error] 	at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:62)
[error] 	at sbt.std.Transform$$anon$4.work(Transform.scala:68)
[error] 	at sbt.Execute.$anonfun$submit$2(Execute.scala:282)
[error] 	at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:23)
[error] 	at sbt.Execute.work(Execute.scala:291)
[error] 	at sbt.Execute.$anonfun$submit$1(Execute.scala:282)
[error] 	at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:265)
[error] 	at sbt.CompletionService$$anon$2.call(CompletionService.scala:64)
[error] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error] 	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[error] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[error] 	at java.base/java.lang.Thread.run(Thread.java:834)

Note: I'm seeing a similar issue with the directory-watcher used by play-file-watcher.

Other related issues:

• directory-watcher unable to load Carbon library via JNA
• Big Sur changes to how JNA loads dylibs
• PlayFramework runner failing due to directory-watcher/Carbon/JNA issue
• Discussion on HackerNews about Mac OS 11 loading dynamic libraries

[bpossolo]

for what it's worth, I uninstalled openjdk@11 and installed openjdk instead (to pull in the latest version)

openjdk version "16" 2021-03-16
OpenJDK Runtime Environment (build 16+14)
OpenJDK 64-Bit Server VM (build 16+14, mixed mode)

also tried zulu

15.0.2 (arm64) "Azul Systems, Inc." - "Zulu 15.29.15" /Library/Java/JavaVirtualMachines/zulu-15.jdk/Contents/Home

openjdk version "15.0.2" 2021-01-19
OpenJDK Runtime Environment Zulu15.29+15-CA (build 15.0.2+7)
OpenJDK 64-Bit Server VM Zulu15.29+15-CA (build 15.0.2+7, mixed mode)

but still have the same issue

[bpossolo]

apparently Apple Silicon support was added in JNA 5.7.0
see here for the reply from Greg Methvin (@gmethvin)
https://discuss.lightbend.com/t/apple-silicon-m1-playframework-broken-on-apple-silicon/7924/10?u=bpossolo

[mariussoutier]

JNA 5.7.0 doesn't seem to fix the problem...

[bpossolo]

@mariussoutier the native library being invoked probably only supports intel architecture. I suspect when JNA loads the library, it doesn't pass through a rosetta layer

[mariussoutier]

With Azul JDK 11.0.10 I no longer have any JNA problems.

[macgrewal]

With Azul JDK 11.0.10 I no longer have any JNA problems.

Unfortunately with Azul JDK 8.52.0.23, this is still a problem 😢

[irundaia]

Unfortunately, I do not have an M1 mac to test this with. I'll see what I can do to use the javascript version of dart-sass (which should be the reference implementation anyways) this weekend.

[vbabenkoru]

I traced this back to JNA 5.5.0 being packaged with the sbt launcher, and overriding the JNA version in the build.sbt for the app doesn't help. The JNA 5.5.0 dependency comes from sbt.io package. I've submitted a PR, but it may take some time to propagate.
sbt/io#320