glibc_version_header
osxcross
glibc_version_header | osxcross | |
---|---|---|
8 | 23 | |
767 | 2,731 | |
- | - | |
0.0 | 5.5 | |
3 months ago | about 1 month ago | |
C++ | C++ | |
MIT License | GNU General Public License v3.0 only |
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.
glibc_version_header
-
Flatpak Is Not the Future
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
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
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
-
Thank You, Valve
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
> 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)
osxcross
- Darling: Run macOS Software on Linux
-
How to cross Compile on Debian for: Mac / FreeBSD / OpenBSD / Android ... ?
If you actually have MacOS device and can install Xcode and so on then you can proceed here and read the instructions.
-
I find it's not possible to do serious C/C++ coding on latest macOS
Have you considered using a dockerized osxcross cross compiler toolchain in your CI? Granted it is a bit clunky to setup...
-
Apple just lost its lawsuit trying to ban iOS virtual machines
Technically it's possible, but possibly not legal:
https://github.com/tpoechtrager/osxcross
> Please ensure you have read and understood the Xcode license terms before continuing.
According to the EULA you may only use the SDK on Apple-branded computers. But you can use Linux to cross compile to Apple.
- Go port of SQLite without CGo
-
Cross compile for ppc macs (10.4)
is there a way to cross compile without vms? something similar to https://github.com/tpoechtrager/osxcross?
-
Am looking for an API guru to assess how to make a project multiplatform
If you figure out how to get SDL working, one possibility is to develop on Linux, then use mingw-w64 to cross compile from Linux to windows, then use osxcross to cross-compile from Windows to OSX.
- How To Fix Your Computer
-
Rust & Cross-compiling from Linux to Mac on GitHub Actions
Thank you osxcross for creating the path forward
-
A Completely Open-Source Implementation of Apple Code Signing and Notarization
This is actually a solved problem, using osxcross[0]. The experience is honestly very smooth, and we don't require any apple proprietary binaries. The only thing apple-proprietary is their SDK (containing the header files for compiling, and tbd files for linking), which can be downloaded from apple's website (at least if you have a developer account), or from various GitHub projects archiving them.
[0]: https://github.com/tpoechtrager/osxcross
What are some alternatives?
holy-build-box - System for building cross-distribution Linux binaries
mold - Mold: A Modern Linker 🦠
overwatch-aimbot - 🔫🎮 An OpenCV based Overwatch Aimbot for Windows
eShopOnContainers - Cross-platform .NET sample microservices and container based application that runs on Linux Windows and macOS. Powered by .NET 7, Docker Containers and Azure Kubernetes Services. Supports Visual Studio, VS for Mac and CLI based environments with Docker CLI, dotnet CLI, VS Code or any other code editor. Moved to https://github.com/dotnet/eShop.
manylinux - Python wheels that work on any linux (almost)
fltk-rs - Rust bindings for the FLTK GUI library.
mach - zig game engine & graphics toolkit
xcgo - Golang cross-platform builder docker image with CGo and other tooling
musl-cross-make - Simple makefile-based build for musl cross compiler
docker-go-mingw - Docker image for building Go binaries with MinGW toolchain
WSL - Issues found on WSL
MacOSX-SDKs - A collection of those pesky SDK folders: MacOSX10.1.5.sdk thru MacOSX11.3.sdk