mach VS glibc_version_header

Myself and many others are betting on Zig in major ways, I truly think it has a bright future ahead.

In spare time, myself and a few others are working on a game engine in Zig[0], and the Zig core team has been very receptive to addressing issues our project faces and supporting us.

Others are working on pixel art editors[1], open source 2D RPG games[2], there's a group of independent folks working on a 3D massive immersive sim game[3], a group working on making Zig an amazing language for micro-controllers[4], etc.

Please consider donating $5-10 a month to the ZSF! They are a great group of people, and it has so many knock-on effects for others in the FOSS community. :)

[0] https://machengine.org/

[1] https://github.com/foxnne/pixi

[2] https://github.com/foxnne/aftersun

[3] https://github.com/Srekel/tides-of-revival

[4] https://github.com/ZigEmbeddedGroup

I don't know if there's anything better than a zip. For our website[0] which includes a bunch of docs for our game engine, Zig packages, etc. we just offer a link "offline version of this site" in the footer which is an ~80MB zip file.

I think the challenge with zip files is.. do you want all the images? do you want all versions of the docs, or just a specific version of the docs? It's hard to tailor the zip to the user's desire. But zip still seems to be the best.

[0] https://machengine.org/

Cool to see others working on this problem. I hope more people do.

Funnily I've seen a lot of programmers and math folks who express how truly, genuinely beautiful Beziers and the math behind them are. But I've never met an artist or graphic designer who didn't express some deep frustration at Bezier controls and how hard they are to work with.

There are even games[0] which make a mockery out of how hard Bezier controls are to use, where the game is purely using the controls.

Controls are just one side of the problem, in my view; the other side is that cubics are terrible for GPUs, they don't understand them - and I believe many of the best 2D graphics libraries today are not even fully GPU accelerated, e.g. Skia. There are folks working on compute shader-based approaches, where we try to shoe-horn this CPU-focused algorithm into GPUs and pray - but it still isn't really suitable.

The controls suck for artists, and the math sucks for GPUs. This is only true of cubics, if you restrict yourself to quadratics (although that brings other challenges), both the control issue goes away (you can just click+drag the curve!) and the performance issue goes away (quadratics are triangles, GPUs love them)

That's the summary of the talk[1] I gave at SYCL'22. In that talk, I didn't have time to present the downsides of quadratics (which are real) - so if you watch it please keep that in mind - but my overall point I think is a solid one: the controls suck, and GPUs can't handle them.

The only reason we stick with cubics in its current form is because of SVG, compatibility with existing tooling, etc. But isn't it crazy? We have new bitmap image formats all the time, and so few vector graphics formats.

In Mach engine[2] we're continuing to explore this space, end-to-end, from author tooling -> format -> rendering. I'm not claiming we have a perfect solution, we don't, but we're at least thinking about this problem. Kudos to the authors of this article for thinking about this space as well.

[0] https://bezier.method.ac/

[1] https://www.youtube.com/watch?v=QTybQ-5MlrE

[2] https://machengine.org

A game engine https://machengine.org is being written in zig, there's also https://microzig.tech as zig is well suited to embedded development.

https://github.com/hexops/mach (shameless plug)

Zig fits pretty naturally here too. We've got ~19 WebGPU examples[1] which use Dawn natively (no browser support yet), and we build it using Zig's build system so it 'just works' out of the box with zero fuss as long as you grab a recent Zig version[2]. No messing with cmake/ninja/depot_tools/etc.

WASM support in Zig, Rust, and C++ is also not equal. C++ prefers Emscripten which reimplements parts of popular libraries like SDL, for me personally that feels a bit weird as I don't want my compiler implementing my libraries / changing how they behave. Rust I believe generally avoids emscripten(?), but Zig for sure lets me target WASM natively and compile C/C++ code to it using the LLVM backend and soon the custom Zig compiler backend.

[1] https://github.com/hexops/mach-examples

[2] https://github.com/hexops/mach#supported-zig-version

We're building Mach which aims to be competitive with Unity/Unreal/Godot in spriti, but super modular / let you pick and choose which parts to use or build yourself.

git clone --recursive https://github.com/hexops/mach-examples cd mach-examples/ zig build run-sprite2d

One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc: https://github.com/wheybags/glibc_version_header

If what you're doing works for you, great, but in case it stops working at some point (or if for some reason you need to build on a current-gen distro version), you could also consider using this:

https://github.com/wheybags/glibc_version_header

It's a set of autogenerated headers that use symbol aliasing to allow you to build against your current version of glibc, but link to the proper older versioned symbols such that it will run on whatever oldest version of glibc you select.

There are other approaches like https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against.

Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.

A few links gathered from a quick google search as a primer:

http://stevehanov.ca/blog/?id=97

https://www.evanjones.ca/portable-linux-binaries.html

https://insanecoding.blogspot.com/2012/07/creating-portable-...

https://rpg.hamsterrepublic.com/ohrrpgce/Portable_GNU-Linux_...

https://github.com/wheybags/glibc_version_header

In other words: there are a lot of steps and a lot of gotchyas to doing this that you're glossing over. Linux userland libraries are generally designed with the intention that an army of third-party maintainers will integrate all of this desperately developed software together and place it in a repo. Naturally every distribution wants to do things a little differently too, and they have a habit of changing it up every couple years. When you try to step out of that mold things unsurprisingly become more difficult. Whereas Windows, Mac, Android, etc. have been designed since the beginning not to require that sort of thing and it is consequently a much, much more straightforward process.

I'm curious why, since you seem to believe the process is so straight-forward, you think it is that so few people distribute a simple binary? Why were Flatpak and AppImage invented?

> Binaries compiled against today's glibc can fail to run on a machine that hasn't been updated since last week because they rely on a new / different symbol.

Note, however, that it is a Glibc bug (modulo Drepper’s temper) if the reverse happens: Glibc symbol versioning ensures that binaries depending on an old Glibc (only) will run on a new one. So the proper way to build a maximally-compatible Linux executable would be to build a cross toolchain targeting an old Glibc and compile your code with it. Unfortunately, the build system is hell and old Glibcs doesn’t compile without backported patches, so while I did try to follow in the footsteps of a couple of people[1–4], I did not succeed.

Mass-rebuilds still happen with other ecosystems, though. GHC-compiled Haskell libraries are fine-grained and not ABI-stable across compiler versions, so my Arch box regularly gets hit with a deluge of teensy library updates, and Arch is currently undergoing a massive Python rebuild (blocking all other Python package updates) behind the scenes as well.

[1]: https://github.com/wheybags/glibc_version_header (hack but easy and will probably work most of the time)