Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Iklistkel]

# A musl (or any) build of Dwarf Fortress that works widely

[...] if I got this right, looks like musl builds of linux software (Nushell for example) simply work across [linux] OS versions (old an new), contrary to glibc (even if I don't have musl installed). I play the newer versions of DF using "wine" due to incompatibility of glibc libs, what is totally fine. But I think it would be better to have a "native" version that works widely.

And so I found that there exist already an old project of DF using musl on versions 34.11, 40.04 and 40.13 here. It is built with old libs (2013-2016) and yet works on my debian. I hadn't noted before, but DF was listed on this musl wiki page. Unfortunately the DF-musl project looks abandoned.

Another nice alternative would be an AppImage container with all needed libs inside it.

Some more info:
[src]: "An easier option is to build against musl, remove the DEPENDS with patchelf, and use that. There are a few incompatibilities with glibc (more on aarch64 than am64), but it's manageable (you might need to patch a few headers in musl and provide missing/incompatible functions). And you'll have a binary that works against musl and glibc both."

Footnote:

Spoiler (click to show/hide)

I would prefer this than buy a new PC that supports a new version of my current OS (or a new OS for new hardware), and do this again every 2-5 years. I did this twice before, and I'll be obligated to do it again. Just non-sense consumerism.

Anyway, this is just a sugestion. If this leads to too much work, I will be fine using "wine".

[lethosor]

I would prefer this than buy a new PC that supports a new version of my current OS (or a new OS for new hardware), and do this again every 2-5 years. I did this twice before, and I'll be obligated to do it again. Just non-sense consumerism.

How would a musl build solve this problem? Typically you can run modern glibc-based distributions even on old hardware.

if I got this right, looks like musl builds of linux software (Nushell for example) simply work across [linux] OS versions (old an new), contrary to glibc (even if I don't have musl installed).

A link to something explaining why this is the case would be helpful. If something built with musl works without a musl runtime installed, my first guess is that it is statically linking musl. Static linking is possible with glibc too, although not recommended. I'm not sure if any similar concerns would apply to musl. For one thing, this means you would not receive future security fixes without rebuilding the application.

It's also unclear to me how well SDL would work natively with musl (given 1, 2, 3, 4). It does appear to be possible, based on the last link, but there may be quirks.

Some other options you might have could include running DF in a container or other chroot-type environment with a suitable glibc. Or a virtual machine, but that is heavier.

Generally, given that Bay12/Kitfox have indicated that they don't even have resources to pursue a MacOS build at the moment (which Bay12 has provided on and off since 2008), I think a musl build is unlikely to materialize until after they do have the resources.

[Iklistkel]

How would a musl build solve this problem? Typically you can run modern glibc-based distributions even on old hardware.

The arbitrary "need" (in many cases) of updates is the tip of a massive iceberg. Everything is working perfectly right now. I have nothing to update or change, except for DF.

musl is one of various ways to make an application work widely, as an option. That, at least in this case, could solve the problem of obligatory update of the entire OS (what will turn many of my apps broken since I don't use apt only). There is already devs slowly dropping support for SSE instructions (for example).

A link to something explaining why this is the case would be helpful.

This helps? LINK: "Using musl maximizes application deployability. Its permissive MIT license is compatible with all FOSS licenses, static-linking-friendly, and makes commercial use painless too. Binaries statically linked with musl have no external dependencies, even for features like DNS lookups or character set conversions that are implemented with dynamic loading on glibc. An application can really be deployed as a single binary file and run on any machine with the appropriate instruction set architecture and Linux kernel or Linux syscall ABI emulation layer."

It does appear to be possible, based on the last link, but there may be quirks.

As I said, If this ends to too much trouble/work, I'll just play as I can (using wine), or play the older versions.

If something built with musl works without a musl runtime installed, my first guess is that it is statically linking musl. Static linking is possible with glibc too, although not recommended.

Is not recommended, yes. Yet, I want to be able to choose my own source of headache.

Some other options you might have could include running DF in a container or other chroot-type environment with a suitable glibc. Or a virtual machine, but that is heavier.

I don't mind using a container if this spare me from change my entire OS, but virtual machine is too much.

I think a musl build is unlikely to materialize until after they do have the resources.

I don't mind waiting for it.