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!Solution:Jump to solution
Right, so the issue is that on my gentoo install,
/lib/ld-musl-x86_64.so.1 actually points to /lib/libc.so. This means that /proc/self/map_files/* will point to /lib/libc.so instead of /lib/ld-musl-x86_64.so.1 after symlink resolution. The "fix" is therefore to point ld-musl-x86_64.so at libc-musl.so, which is a copy of libc.so... This is so hideously broken, and will need to be fixed up every time I update musl-libc :/4 Replies
Looking further into sqlite-jdbc, the following file seems to be responsible for figuring out what OS / arch we are running on, and thus which natives to load: https://github.com/xerial/sqlite-jdbc/blob/master/src/main/java/org/sqlite/util/OSInfo.java . The isMusl check does not seem to work for me, and manually tweaking
/etc/os-release to replace ID=gentoo with ID=alpine did not fix the issue (the unpacked /tmp/sqlite-*-libsqlitejdbc.so still complained about the unknown symbol) ...GitHub
sqlite-jdbc/src/main/java/org/sqlite/util/OSInfo.java at master · x...
SQLite JDBC Driver. Contribute to xerial/sqlite-jdbc development by creating an account on GitHub.
Yeah, using the
-Dorg.sqlite.osinfo.architecture override to select an invalid arch (in this case, musl), to check the value of os.name shows Linux instead of Linux-Musl (although it is possible that this validity check happens before sqlite-jdbc attempts to run the isMusl or isAlpine checks): https://mclo.gs/rXMX1m2Solution
Right, so the issue is that on my gentoo install,
/lib/ld-musl-x86_64.so.1 actually points to /lib/libc.so. This means that /proc/self/map_files/* will point to /lib/libc.so instead of /lib/ld-musl-x86_64.so.1 after symlink resolution. The "fix" is therefore to point ld-musl-x86_64.so at libc-musl.so, which is a copy of libc.so... This is so hideously broken, and will need to be fixed up every time I update musl-libc :/I will mark the above as the "solution", although I would very much prefer this to be fixed either in my distro, or to allow sqlite-jdbc to override the
os.name property with a commandline argument (similar to how they currently allow you to override org.sqlite.osinfo.architecture :(