Now try building a "portable" binary that runs on a version of Linux older than yours.
Does having a sysroot with an older glibc count?
Cross-compiling binaries for Windows is easier than building natively
341–349 of 349 posts
Re: Cross-compiling binaries for Windows is easier than building natively
#342Now try building a "portable" binary that runs on a version of Linux older than yours.
If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as: docker run -v "$PWD:/src" olddistro:version /src/build.sh $dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way. Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. Libraries have different versions, different paths (eg /usr/lib vs…
> Compiling on one distro and then expecting it to work on another distro is a foolhardy errand.
Only if you link random libs you find in on the system. The base system libs making up a Linux desktop (glibc, xlib, libasound, libpulse*, libGL, etc.) all are pretty good about maintaining backwards compatibility so you only need to build against the oldest version you want to support and it will run on all. Other libraries you should distribute yourself or even statically link with their symbols hidden. This approach works for many projects.
Re: Cross-compiling binaries for Windows is easier than building natively
#343Earlier quoted context omitted.
"Statically link or bundle everything" is how most Windows apps deal with this tho. So if we're comparing Windows and Linux, and saying that Linux packaging is worse, this method can't just be dismissed on security grounds.
Windows developers tend to stuff directories full of DLLs if they need to ship dependencies, they're not statically linked per se. Regardless, it's incredibly complicated to compare linking behaviour between Windows and Linux. Windows has tons of components built into the API (and which is maintained by Microsoft) which you'd need an external dependency for in Linux. Microsoft provides interfaces for things like XML…
> Windows developers tend to stuff directories full of DLLs if they need to ship dependencies, they're not statically linked per se.
I assure you, there is plenty static going on in Windows land.
Re: Cross-compiling binaries for Windows is easier than building natively
#344Earlier quoted context omitted.
Statically link everything ? Including glibc?
Trick question: glibc doesn't support that. Trying to statically link with glibc is a fool's errand.
glibc doesn't support static linking, but you can fully static link with another libc if that is what you wanted to do.
Not that it is needed for forward-compatible Linux binaries since newer glibc versions are backwards compatible so dynamically linking the oldest one you want to support works fine. Would be nice if glibc/gcc supported targetting older versions directly without having to have an older copy installed but that is a convenience issue.
Re: Cross-compiling binaries for Windows is easier than building natively
#345Earlier quoted context omitted.
AppImage is sufficient.
nope, it still requires at least the glibc version that the appimage was compiled against. snaps, flatpaks nor appimage solve the long-standing glibc versioning issue that plagues portable Linux binaries. the closest I've seen to fixing this issue is https://github.com/wheybags/glibc_version_header
> the closest I've seen to fixing this issue is https://github.com/wheybags/glibc_version_header
Or just compile against an older glibc version. Plenty of tools to setup sysroots for that, e.g. https://wiki.gentoo.org/wiki/Crossdev
Re: Cross-compiling binaries for Windows is easier than building natively
#346Earlier quoted context omitted.
Steam distributes an entire runtime environment because it's a platform that's being targeted by 3rd party developers, who often make mistakes that Steam Runtime tries quite hard to reconcile. When all you care about it's your own app, you're in power to compile things however you want and bundle whatever you want with it, at which point it's honestly not that hard. Building in a container is a breeze, tooling is top…
It's easy to compile an entirely new binary for every platform/distro, and it's easy to bundle an entire execution environment along with a single binary using docker, what's hard is compiling a single binary and have it run across all distros and execution environments.
It really isn't that hard to get a single binary that works across glibc-based distros. Just compile against the oldest version of glibc/Xlib/etc. you want to support and bundle all non-system libraries, statically linking them with symbols hidden if possible.
We are not talking out of our ass here - I myself do this for all the software I maintain and just works. Tons of programs are released this way.
Re: Cross-compiling binaries for Windows is easier than building natively
#347Earlier quoted context omitted.
Like it’s absolutely a nightmare but you can eliminate a lot of problems by building on an ancient version of RHEL.
It says a lot about Linux development that for cases like these "just install the Linux equivalent of Windows XP in a container and run the tools inside that" is an accepted solution. It's a solution that works well and is used by loads of developers, but it's still comically silly.
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.
Re: Cross-compiling binaries for Windows is easier than building natively
#348Earlier quoted context omitted.
I agree with everything but the "controlling open source" bit. I think what they are actually doing is trying to create new platforms they can control, because that's a great business model. Open source, via Github is just a small piece of the pie they want. Think MS teams/Office365, Linkedin, Gaming, Github, etc. These are platforms they are interested in controlling and deriving revenue from.
I don't think what you and I are saying conflict from a business point-of-view, but I think also it would be naive to "wave away" the incentive for MS to continue EEEing.
Fair enough.
Re: Cross-compiling binaries for Windows is easier than building natively
#349Earlier quoted context omitted.
they knew they would and they advertised that fact, and made blog and content owners migrate their stuff if they wanted it kept. many chose not to. those are the people you should be angry with.
Or they could've just migrated it for them, and kept everything running.
I'm told that MSDN blog posts were owned by the authors, not Microsoft.
it wasn't Microsoft's content to move.
movement to docs.microsoft.com meant giving copyright to Microsoft, and not everyone chose to do that.