Miko
DHDistant Horizons
•Created by Miko on 3/15/2025 in #help-me
Building and running distant-horizons on musl-libc
Thank you in advance for your time. I am trying to use distant-horizons 2.3.0b by itself on a fabric 1.21.3 install. I am using musl-libc, and have a symlink linking
/lib/ld-linux-x86-64.so.2 -> ld-musl-x86_64.so.1
for very basic "glibc compatibility". This results in the following crashlog whenever I attempt to create a world, or join a server: https://mclo.gs/htnM8jR (specifically, this was me attempting to create a default survival world immediately after starting minecraft)
To the best of my understanding, this is an issue with the extracted libsqlitejdbc.so being built and linked for glibc, as evidenced by running ldd /tmp/sqlite-*-libsqlitejdbc.so
:
To remedy this, I attempted to build from source following the readme in the gitlab repo, and the gradle build clearly claimed to have downloaded a linux-musl binary. However, when running the locally built jar, the exact same error presented itself. I am wondering if the compatibility symlink is confusing the jni loader, and whether there is a way to force distant-horizons / JNI to load the musl native library instead? Or is there a way to build distant-horizons such that it only contains the linux-musl native libraries in the first place (so that those are the only ones it could ever load). From a glance at the gradle build scripts (I am unfortunately not terribly familiar with gradle), I didnt see a switch for this, nor did I see a property for this under gradle.properties
. But perhaps I have missed something obvious?
Any help would be appreciated!7 replies