mach VS glibc_version_header

Compare mach vs glibc_version_header and see what are their differences.

Nutrient – The #1 PDF SDK Library, trusted by 10K+ developers
Other PDF SDKs promise a lot - then break. Laggy scrolling, poor mobile UX, tons of bugs, and lack of support cost you endless frustrations. Nutrient’s SDK handles billion-page workloads - so you don’t have to debug PDFs. Used by ~1 billion end users in more than 150 different countries.
www.nutrient.io
featured
CodeRabbit: AI Code Reviews for Developers
Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
coderabbit.ai
featured
mach glibc_version_header
38 8
3,707 832
6.6% 1.2%
9.7 0.0
10 days ago 9 months ago
Zig C++
GNU General Public License v3.0 or later MIT License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

mach

Posts with mentions or reviews of mach. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-11-05.
  • Show HN: Lyceum – An MMO game built with Zig and Erlang
    5 projects | news.ycombinator.com | 5 Nov 2024
    Did you happen to tinker with https://machengine.org/ it's a Zig game engine & graphics toolkit?
  • Leveraging Zig's Allocators
    2 projects | news.ycombinator.com | 15 Jun 2024
    We're working on a game engine in Zig[0]

    If you're looking for interesting Zig codebases to read, you might be interested in our low-level audio input/output library[1] or our module system[2] codebase - the latter includes an entity component system and uses Zig's comptime to a great degree to enable some interesting flexibility (dependency injection, global view of the world, etc.) while maintaining a great amount of type safety in an otherwise dynamic system.

    [0] https://machengine.org/

    [1] https://github.com/hexops/mach/tree/main/src/sysaudio

    [2] https://github.com/hexops/mach/tree/main/src/module

  • Zig Software Foundation 2024 Financial Report and Fundraiser
    4 projects | news.ycombinator.com | 18 Jan 2024
    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

  • DevDocs
    19 projects | news.ycombinator.com | 12 Jan 2024
    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/

  • Not only Unity...
    53 projects | /r/opensourcegames | 11 Nov 2023
  • Mach - Zig game engine & graphics toolkit
    1 project | /r/Zig | 12 Sep 2023
  • New Béziers from Math
    5 projects | news.ycombinator.com | 10 Sep 2023
  • 0.11.0 Release Notes
    12 projects | news.ycombinator.com | 3 Aug 2023
    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.
  • Significant examples of Zig software (June 2023)?
    7 projects | /r/Zig | 6 Jun 2023
    https://github.com/hexops/mach (shameless plug)
  • Learn WebGPU
    9 projects | news.ycombinator.com | 27 Apr 2023
    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

glibc_version_header

Posts with mentions or reviews of glibc_version_header. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-08-21.
  • Flatpak Is Not the Future
    6 projects | news.ycombinator.com | 21 Aug 2023
    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
  • Win32 Is the Only Stable ABI on Linux
    13 projects | news.ycombinator.com | 15 Aug 2022
    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.

  • Because cross-compiling binaries for Windows is easier than building natively
    15 projects | news.ycombinator.com | 18 Jun 2022
    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.

  • Glibc Version Header Generator
    1 project | news.ycombinator.com | 15 May 2022
  • Thank You, Valve
    9 projects | news.ycombinator.com | 7 Feb 2022
    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?

  • “LLVM-Libc” C Standard Library
    10 projects | news.ycombinator.com | 7 Dec 2021
    > 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)

What are some alternatives?

When comparing mach and glibc_version_header you can also consider the following projects:

quickjs-emscripten - Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions

holy-build-box - System for building cross-distribution Linux binaries

SDL.zig - A shallow wrapper around SDL that provides object API and error handling

overwatch-aimbot - 🔫🎮 An OpenCV based Overwatch Aimbot for Windows

arocc - A modern fully featured C compiler.

mxe - MXE (M cross environment)

zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

osxcross - Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux)

ComLightInterop - Cross-platform COM interop library for .NET Core 2.1 or newer

musl-cross-make - Simple makefile-based build for musl cross compiler

mach-glfw-vulkan-example - mach-glfw Vulkan example

omnios-build - Build system for OmniOS

Nutrient – The #1 PDF SDK Library, trusted by 10K+ developers
Other PDF SDKs promise a lot - then break. Laggy scrolling, poor mobile UX, tons of bugs, and lack of support cost you endless frustrations. Nutrient’s SDK handles billion-page workloads - so you don’t have to debug PDFs. Used by ~1 billion end users in more than 150 different countries.
www.nutrient.io
featured
CodeRabbit: AI Code Reviews for Developers
Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
coderabbit.ai
featured

Did you know that Zig is
the 22nd most popular programming language
based on number of references?