Miko
DHDistant Horizons
•Created by Miko on 3/15/2025 in #help-me
Building and running distant-horizons on 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 :(7 replies
DHDistant Horizons
•Created by Miko on 3/15/2025 in #help-me
Building and running distant-horizons on musl-libc
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 :/7 replies
DHDistant Horizons
•Created by Miko on 3/15/2025 in #help-me
Building and running distant-horizons on musl-libc
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/rXMX1m27 replies
DHDistant Horizons
•Created by Miko on 3/15/2025 in #help-me
Building and running distant-horizons on musl-libc
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) ...7 replies