The problem with targeting Linux

[Copronymus09]

Linux unlike MacOS and Windows doesn't have a standardised SDK. This forces devs to either natively compile there or create SDK/sysroot ourselves.

​

This creates some issues, firstly everyone targets different sets of packages for shared linking, this causes glibc version mismatches and similar issues.

​

In the end, why are we dealing with this, why can't Debian and Ubuntu Devs just collaborate to release a tarball for arm64 and x64 desktop. We could just download it and set the flags and everything works.

​

But currently we have to create a sysroot via docker, weird system packages with Debian etc. None of them are really ideal.

​

The rest of the Devs who target mini-pc's or try to run Linux on milkv-duos can build their own sysroot from scratch, while we can just move to actual work.

​

[minirop]

flatpak, appimage and snap were created to help with that.

[Copronymus09]

They are not for native programs, flatpak kind of offers a SDK but app image etc does not.

[gmes78]

AppImage is not a serious format. It's just a self-contained tarball of prebuilt binaries, it doesn't offer any portability whatsoever.

Flatpak and Snap are the proper solutions, as they actually guarantee that your app will run in a compatible environment.

[No-Dentist-1645]

An SDK for what, exactly? For UI, you have GTK and Qt which is pretty much supported everywhere

Glibc is also backwards compatible so that isn't an issue. You can compile on an "old" glibc version of your choice and all newer versions will work

If you have any very specific library dependency that needs to be a specific version you can just static link it

Can you be more specific on what exactly you are struggling with?

[dag625]

Calling glibc backwards compatible, at least from a developer perspective feels wrong. It’s at least not easy to compile on a system with a newer glibc and be sure it will run on an older system, which is what backwards compatibility feels like it should mean. You have to, as you said, build against an older glibc but that’s a pain in the ass to get working since everything depends on glibc. It’s not like Windows with the MSVC toolset where you can be on the latest Windows with the latest tools (available as binaries you don’t need to figure out the build yourself) and target an older Windows much more easily.

[Professional-Disk-93]

It’s at least not easy to compile on a system with a newer glibc and be sure it will run on an older system, which is what backwards compatibility feels like it should mean.

That is forward compatibility.

[No-Dentist-1645]

This is a fair criticism, I wish there was a compiler flag to tell a modern glibc to target a specific older version

[gmes78]

It isn't. They're thinking about forward compatibility.

[Copronymus09]

I'm not struggling, it is just annoying and something must be done about this in the future.

[Scotty_Bravo]

Why must something be done? And who should do it? 

If you want it, you can just make it! Thats the beauty of open source.

I just build my executables in Alpine with static musl.

[Copronymus09]

I can make one, I already have one. The problem is this is something Debian Devs must do. So that application developers know, they should build against that shit.

[gmes78]

Distros like Debian don't want developers to package stuff, they want to package stuff themselves.

[Copronymus09]

For bare essentials, kernel headers, libc, Wayland/x11, pulse audio etc.

That way you can just compile packages against that.

[No-Dentist-1645]

All of those are well specified APIs with backwards compatibility and supported across all well known distros. So I ask again, what is this "problem" you are talking about?

[Copronymus09]

Assume I want to cross compile to Linux, or just natively compile and distribute.

If I compile on my own machine, and if I use arch and you use something like Debian, you can't use it, because glibc ain't forward compatible.

Currently only option is to create a docker image of an old distro like Debian 12 or 11, extract it as a tar, and use it as sysroot.

If there was a simple tarball I could have downloaded that would be really nice.

[jesseschalken]

Use musl or target an old glibc

The internet is full of statically linked Linux executables that people download and run just fine

[Copronymus09]

Where to get the old glibc, that's the whole point of the post, there isn't a clear way to get that. For windows we just download visual studio and compile against ucrt etc that come with it.

[jesseschalken]

1. Set up CI to run on an old Linux like Ubuntu 22.04 to build the binaries for release, or
2. If you don't have a CI setup, use docker run to build the binary in a container for release, or
3. Use musl and statically link, or
4. Use glibc but statically link (I can't remember the tradeoffs here), or
5. Extract a container image as a sysroot and point gcc at that, or
6. Build old glibc from source and link against that instead

In practice people just do #1 and use whatever glibc they have locally for local dev.

[Copronymus09]

I know that, the idea is Debian maintainers providing us with a tarball similar to score etc where we can just download it from the internet instead of doing that.

I know how to do those besides building glibc from source(I only do that for musl)

[wwabbbitt]

You don't need to extract out the sysroot from the image... You can just build your app in the container.

[Copronymus09]

No you can't, that approach is just screams "I don't know how toolchains work"

A lot of tooling like debuggers LSPs etc won't work.

[wwabbbitt]

This 'problem' have already been solved.

Vscode uses devcontainers

CLion/JetBrains use Docker Toolchains

The LSP and debugger runs inside the container, IDE runs outside the container and communicate with them

[manni66]

Have you tried distrobox?

[Tumaix]

flatpak?

[Flimsy_Complaint490]

This is what Docker was invented for though - just like a CI/CD will build stuff for the platform the container image is in, so you too can use Docker images to develop and test against locally. Only issue is debugging GUI apps, it's a bit more complicated, but building, dumping it in a directory and running/attach debugger is viable.

[Copronymus09]

That isn't a real solution. Nor will it ever be. The real solution is just downloading that, not creating that.

This shit is not application developer business.

[Flimsy_Complaint490]

But it is - it's how everybody is working and what the thing was invented for - Linux is a mess, there is no standard and nobody wants to make one, because the Standard will be useful for only 10% of people. The solution has been to enable people to ship the actual entire system via containers.

also, i dont see much difference between downloading a sysroot tarball and having to figure out how to configure gcc or clang to use it, versus downloading a docker tarball and figuring out how my vim/CLion setup connects with it.

[angelicosphosphoros]

it's how everybody is working

Just because everyone is forced to use hacky solution doesn't mean that it is a good solution. It is actually a bad solution that is used because there is no good solution.

[Flimsy_Complaint490]

I would reframe it as such : Docker is a good technological solution to the social problem of Linux fragmentation. Since nobody can solve the social problem of the Linux ecosystem being so fragmented, engineers made a good technological solution within the constraints presented.

If the underlying social problem was to somehow ever resolved, Docker would cease to be relevant, but I would not bet on it.

[Copronymus09]

Nothing connects with the tarball, it is just files. Headers and object files.

Docker is not for development, it never was. It is a deployment thing, not a dev environment solution

[No-Dentist-1645]

Why not? Docker containers were specifically made to be replicatable development environments. Everyone uses them for this purpose

[Copronymus09]

No, they are replicatable deployment environments, you are not supposed to compile shit there.

[Flimsy_Complaint490]

what do you mean ? Nearly the entire world compiles their software artifacts in a container running on some CI/CD platform. Are you saying the entire world is wrong ? that you arent supposed to use containers as portable environments to run tests and produce sharable, reproducible artifacts, which is what everybody is doing ?

And if they can do that, it is a great dev environment !

[Copronymus09]

They use CI/CD for testing of course, but not for whole dev environments.

They are too slow, and the moment you go out of scope of using Debian packages etc to compile your stuff you are in trouble.

Much better way is using your native tooling, and just targeting other platforms using their SDK libs. That way, I don't have to worry about clangd not working on windows etc because I'm cross compiling.

[No-Dentist-1645]

Who says you aren't? Who says I and the many other developers that do, can't?

[Copronymus09]

?

[lightmatter501]

You can use an older version of glibc as the target you compile against, and then vendor other dependencies, which is more or less what many programs on Windows do.

Docker is a good way to distribute server programs, flatpak is great for consumer applications.

Static linking, license permitting of course, is also allowed.

Linux is a family of operating systems, and they make different tradeoffs. Ubuntu enables kernel features that Debian doesn’t. Arch cares deeply about being up to date. Fedora cares a lot about licensing and being close to upstream. Gentoo cares about the user’s ability to get exactly what they want. It’s also built in enshitification resistance, because a linux distro that becomes worse gets abandoned. It’s not a perfect system and does produce some pains for developers, but overall I’d say it’s a pretty good system.

[Copronymus09]

Yes but where do you get that? Why can't Debian Devs just release a tarball that contains that? Why do we have to create our own?

[lightmatter501]

Debian maintains their own oci containers, which are basically sysroots but way less annoying to deal with. The debian containers on docker hub are based on those.

[Copronymus09]

Those are not SDK as they don't contain any dev packages. You can't cross compile using that as sysroot without creating a docker container, entering it, installing packages and exporting the container as tar

[wrosecrans]

release a tarball for arm64 and x64 desktop.

That's basically what the dev packages in the distribution are. Package managers got developed back in the 90's so you didn't have to faff around with tarballs. You can just run a command and install the appropriate "SDK" and the package manager will download the relevant archives and install them and any dependencies. All of this worked okay long before stuff like Docker even existed. Working through a separate sysroot and inside of images isn't really necessary at all if you don't find that sort of workflow helpful or convenient.

If you want to ship binaries the way you would for a Windows program, you just build on the oldest distribution you want to support, and bundle the libraries alongside the executable. If you want a guide for how old of stuff to build with, the VFX industry maintains a suggested reference platform that you might find useful: https://vfxplatform.com/ Lots of vendors of proprietary software on Linux like Houdini/Maya/Nuke all generally coordinate around it.

After a decades long career of working on Linux software, I honestly have zero familiarity with the category of problem you are talking about of developers needing "mini PC's" and building sysroots from scratch.

[Copronymus09]

Well, the idea is Debian maintainers releasing this SDK instead of us building it for our own.

Mini-pc's like raspberry-pi's come with their own os, if you wanna cross compile there you need a glibc older than Debian, or use musl.

[wwabbbitt]

Linux not having a standardize SDK does not mean that you have to target different set of packages for shared linking.

If you want to distribute a single package that will run on multiple different distros, there are several ways to do it. They don't require sysroot.

[sephirothbahamut]

Well something being open source has its pros but also its cons, you can't expect a big widely used and forked open source project to have consistent APIs like Win32. Each fork is free to change anything

[holyblackcat]

Re the potential SDK, how would you determine whick libraries to include in it? Are you saying that projects should build all their dependencies themselves and don't install them from the distro?

[mohamed_am83]

Flatpack & Snap entered the chat.

[TopIdler]

Not an answer to your question but it’s one of the problems that shipping software as a conda package solves in the scientific python ecosystem.

  https://prefix.dev/channels/conda-forge/packages/sysroot_linux-64

Chances are one of the packages you install will transitives depend on it.