LeveldbJournalNativeSpec fails on macOS ARM64 because leveldbjni-all lacks an arm64 library
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- scala
- Ambito
- build-system, testing
Direzione di ricerca
Inizia in project/Dependencies.scala ed esegui il comando persistence-tck per org.apache.pekko.persistence.journal.leveldb.LeveldbJournalNativeSpec su macOS ARM64. Esamina gli artefatti leveldbjni-all candidati e la loro compatibilità con org.iq80.leveldb e Windows-native prima di scegliere un approccio. Il lavoro è completato quando la native spec e validatePullRequest funzionano sulle piattaforme supportate senza compromettere i metadati delle dipendenze pubblicati.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Description
LeveldbJournalNativeSpec fails on Apple Silicon because Pekko currently uses org.fusesource.leveldbjni:leveldbjni-all:1.8, whose macOS native library does not contain an ARM64 slice.
Reproduction
Environment:
- macOS 26.5.1
uname -m:arm64- Java 25.0.1
Run:
sbt "persistence-tck / Test / testOnly org.apache.pekko.persistence.journal.leveldb.LeveldbJournalNativeSpec"
The same failure is reached from validatePullRequest.
Actual error:
java.lang.UnsatisfiedLinkError: Could not load library
...
fat file, but missing compatible architecture
(have x86_64,i386, need arm64e or arm64)
Root cause
project/Dependencies.scala defines:
val levelDBNative =
"org.fusesource.leveldbjni" % "leveldbjni-all" % "1.8" % "optional;provided"
The bundled macOS library reports:
META-INF/native/osx/libleveldbjni.jnilib:
Mach-O universal binary with 2 architectures: x86_64 i386
It has no arm64 slice.
Workarounds investigated
The HawtJNI property -Dlibrary.leveldbjni.path=<dir> is recognized and attempts to load a library from the supplied directory. However, the ARM library in org.openlabtesting.leveldbjni:leveldbjni-linux64-aarch64:1.8 is a Linux binary:
ELF 64-bit LSB shared object, ARM aarch64
Pointing library.leveldbjni.path at that library on macOS fails with:
slice is not valid mach-o file
The org.openlabtesting.leveldbjni group has four artifacts in Maven Central (leveldbjni-project, leveldbjni, leveldbjni-linux64-aarch64, and leveldbjni-all) and no macOS ARM64 artifact. Its leveldbjni-all:1.8 still bundles the old x86_64+i386 macOS library.
Huawei variants 1.8-hw-20191105 and 1.8-hw-aarch64 also add Linux AArch64 ELF libraries while retaining the old x86_64+i386 macOS library.
Possible direction
These Maven Central artifacts contain a real Mach-O ARM64 library and passed a local JNI open/put/get/close/destroy smoke test:
io.github.tronprotocol:leveldbjni-all:1.18.3com.halibobor:leveldbjni-all:1.23.2
A replacement needs compatibility review before adoption: these artifacts use a different org.iq80.leveldb API dependency and do not bundle the Windows native DLLs present in the current artifact. A platform-specific test dependency or another approach may be needed to avoid regressions and non-reproducible published POMs.
Expected behavior
The native LevelDB spec should either run successfully on macOS ARM64 with an Apache-compatible supported dependency, or the unsupported platform should be handled explicitly without breaking the full PR validation.
References
- https://repo1.maven.org/maven2/org/fusesource/leveldbjni/leveldbjni-all/1.8/
- https://search.maven.org/solrsearch/select?q=g:%22org.openlabtesting.leveldbjni%22&rows=200&wt=json
- https://repo1.maven.org/maven2/io/github/tronprotocol/leveldbjni-all/1.18.3/
- https://repo1.maven.org/maven2/com/halibobor/leveldbjni-all/1.23.2/
- Lingua principale
- Scala
- Stelle
- 1.7k
- Fork
- 212
- Merge medio
- 18h 20m
- PR unite (30g)
- 108
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/pekko
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
apache/pekko#1840 · 8 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Coordinator singleton lease loss permanently stops the local ShardRegion while the node is still UpForse già presa @He-Pin l’ha presa 4 giorni fa. Apertabug cluster
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement flaky make-tests-easier-to-run
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
build enhancement github_actions
Difficoltà 3/5 1-2 giorni Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di apache/pekko
Issue simili
-
GeoSeries scale and skew tests fail with pytest 9.2.0Forse già presa @jiayuasu l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Python unit CI fails on Ubuntu 26.04 runnerForse già presa @parthosa l’ha presa oggi. Aperta
Difficoltà 1/5 1-3 ore Idoneità per principianti 83/100
NVIDIA/cudf-spark-tools#2207 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
canton-network/splice#8087 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno