Wishlist: Provide basic Linux binaries with releases

[vv221]

Please consider providing "classic" Linux binaries with releases, in addition to the AppImage. This would help a lot in including Julius in other projects.

---

I am currently planning to add support for Julius into ./play.it, a free/libre installer for DRM-free commercial games on Linux, that makes games installation easier by automating the build of native packages from a collection of games installers.

We currently support the Cæsar Ⅲ installers sold on gog.com, building packages that rely on WINE to run on Linux.

I first learnt about Julius a couple hours ago thanks to a post on French news website LinuxFr.org, and tried it on a Debian Sid. The experience has been very good, so I would like to provide it as an alternative to WINE for people wanting to play Cæsar Ⅲ thanks to ./play.it.

With open source engines like DevilutionX for Diablo this inclusion is made quasi-trivial thanks to having access to binaries ready to include in our packages for any release. It would be very nice to have something similar with Julius.

[vv221]

Sorry for the "bug" label, this is of course not a bug ;)

[bvschaik]

The last time I checked (but that was years ago), there is no concept of "universal" Linux binaries: binaries are not compatible across CPU architecture, or even Linux distributions because of differences in libc versions. Please correct me if I'm wrong though.

Julius is already included in some distributions.

[vv221]

The last time I checked (but that was years ago), there is no concept of "universal" Linux binaries

This is still the case, most projects provide only x86_64 and x86_32 binaries (or only x86_64 more recently) as that seems to be enough to cover most use cases.

About the differences in libc versions, I actually don’t know how most project maintainers handle this. It might be as simple as building against a libc old enough that it would run on current LTS distributions.

Julius is already included in some distributions.

I actually did not notice that, maybe including a repology badge in the readme might help make it more visible.

[bvschaik]

I just tested it: x86_64 binary compiled with SDL 2.0.12, running it on Debian 8 Jessie, quite an old version with SDL 2.0.2. It crashes when executing code which is meant for newer SDL versions (2.0.7+).

The problem with these binaries is that SDL is not statically linked, it has to be provided by the system since static linking of SDL is actively discouraged, and that will cause crashes for distributions with old versions of SDL. Of course we can compile and link against an old version of SDL for the Linux binaries, but then we have the problem that distributions with newer systems will miss out on the new features that require higher SDL versions, such as improved touch support.

@vv221 Do you have any advice on this? How do other apps handle this?

[crudelios]

@bvschaik I think SDL's version can be checked not only at compile time, but also during run time.

So we could effectively do something like this:

#if SDL_VERSION_ATLEAST(2,0,7)
if (SDL_VERSION_ATLEAST(2,0,7)) {
    // Execute code for recent SDL versions
} else {
#endif
    // Execute code for older SDL versions
#if SDL_VERSION_ATLEAST(2,0,7)
}
#endif

[bvschaik]

@crudelios It looks like we can only use SDL_GetVersion at runtime, but that should be sufficient. We use only a couple places where the SDL version really matters, so we can add extra checks there.

[crudelios]

On it!

[devnoname120]

@vv221 What's the problem with just using the AppImage? It's a normal and self-contained Linux executable.

I don't know how your installer works but I don't think it's a good idea at all to use a dynamically-linked executable.

There is a reason why on Linux we only have 3 things:

• distribution-specific packages
• universal executables
• statically-linked executables (for people who want to suffer through the musl nightmare, I gave up)

[vv221]

@devnoname120

What's the problem with just using the AppImage? It's a normal and self-contained Linux executable.

I do not deny it, it is probably the best format for standard usage.

I don't know how your installer works but I don't think it's a good idea at all to use a dynamically-linked executable.

Well, that’s the thing: you should have asked how it works first ;) ./play.it is indeed building distribution-specific packages, not universal ones. Using the system-provided libraries is one of its strengths compared to other installation methods.

Including an AppImage in a .deb package would be an increase in complexity, and a good source of confusion.

---

Of course I would not have insisted if this was deemed impractical, too much work, or even simply if no contributor wanted to work on it.

I could easily have distributed the dynamically linked executables from ./play.it website, as we do for some other resources. But one of the reasons I want to add support for Julius is to increase the awareness about what is in my eyes a great project, so redirecting people here for the download of Julius binaries seems like a good solution for that goal.

[bvschaik]

@vv221 Let's just try it for x86_64 and see how this goes. Please keep me up to date if there are any issues with the binaries. They are built on a Ubuntu system so should be compatible with Debian-based systems at least.

[vv221]

Thanks!

I should be able to get feedback from users of Arch Linux, Debian and maybe Gentoo quite quickly, and from a wider range of systems once Julius support reach a stable version of ./play.it.

[vv221]

@bvschaik, thanks to the binaries you now provide, we have a ./play.it update under testing adding Julius as a proposed engine to play Cæsar Ⅲ: Game update: Cæsar Ⅲ — Add support for native Julius engine

It seems to work quite well, so should be included in a public release soon.