Shared libraries [LWN.net]

Shared libraries

Posted Nov 28, 2025 11:38 UTC (Fri) by khim (subscriber, #9252)
In reply to: Shared libraries by nim-nim
Parent article: APT Rust requirement raises questions

> Distro opponents have not managed to do it.

Seriously? Can you find another, more believable, delusion? The most popular OS on the planet shows us how that can be done.

You may claim that there are bazillion Linux distros and only one successful alternative, but that's not entirely true: there were others (Tizen, Maemo), they just have proven not to be very interesting… ironically enough one of the worst problems they had was precisely the fact that they have broken compatibility too much.

> And when they attempt to do it it looks like a distro reinvention

Not really. It's like saying that car and the plane are the same thing if they both use Rolls-Royce engine.

The critical difference between distro's “steaming pile of packages” and proper OS is an SDK: something that you can use to build your binary and, most importantly, target different versions of OS simultaneously. Here are downloads for Anroid. These are for Windows. MacOS are the shittiest ones, yes, they exist.

Where can I find something like that for any popular distro? If the answer is “you should just install bazillion versions on CI in docker”… then here's your answer for why things work as badly as they do with Linux on desktop.

to post comments

Shared libraries

Posted Nov 29, 2025 16:32 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

The critical difference between distro's “steaming pile of packages” and proper OS is an SDK: something that you can use to build your binary and, most importantly, target different versions of OS simultaneously.

Chances are, if you're developing software for Linux you probably want to target more than one Linux distribution, anyway. At that point, relying on an “SDK” provided by any one distribution likely wouldn't be enough – it would be weird to expect the “Debian SDK” to spit out RPM packages for RHEL or openSUSE, after all, and vice-versa –, and using CI to build more than one flavour of your code doesn't look all that unreasonable anymore. Been there, done that; it's not exactly rocket science.

Shared libraries

Posted Nov 29, 2025 16:48 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

> Chances are, if you're developing software for Linux you probably want to target more than one Linux distribution, anyway.

Why is that a problem? Go back quarter century… Windows 9x and Windows NT were significantly more different than different Linux distros… yet creating one binary that worked on both was the norm. Supporting Windows 3.x (with Win32s) was harder, but still possible.

These days that support is often done with help of Docker and, now, Flatpacks. Not sure how well it works with Flatpacks, but Docker for server packages works reasonably well.

> it would be weird to expect the “Debian SDK” to spit out RPM packages for RHEL or openSUSE, after all, and vice-versa

Yes, that's why people invented something that works for both. Many things, in fact. If GNU/Linux couldn't give them usable SDK then they would pick someone who would… Valve, e.g.

But then distros spent decades punishing them for that.

The only thing that achieved is the development of open source ecosystems that consider distros their enemy, or, at best, “the necessary evil”.

Rust just have turned into reveal show because distros have come to the Rust developers with demands then need to fulfill… and got back the question they haven't expected at all: “why should we care?”.

They have gotten certain answers, ultimately, via the Rust-in-Linux route: certain developers want to use distro-provided version of Rust and that means certain features needs to be included in Rust at certain time… that got acknowledgement, even if not full acceptance. Everything else? Distros have created the problem for themselves by introducing some strange arbitrary rules, distros may decide how to resolve them… developers of most Rust packages are just too busy doing useful work with people who don't invent random crazy hoops, they don't have time for the distro-invented circus.

Shared libraries

Posted Nov 29, 2025 17:39 UTC (Sat) by pizza (subscriber, #46) [Link]

> The only thing that achieved is the development of open source ecosystems that consider distros their enemy, or, at best, “the necessary evil”.

Those ecosystems decided that support for non-Linux environments was required, so they had to take a different approach.

If you have to reinvent the wheel completely anyway, why not just use that new wheel for Linux systems?

The smarter ones incorporated the lessons learned from Distros, but the not so smart ones (Python comes to mind) are still paying the price.

But as the saying goes, with sufficient thrust even a pig will fly. And thanks to the AI craze Python has a *lot* of well-funded thrust.

Shared libraries

Posted Dec 1, 2025 18:54 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Eh, we make tarballs that extract to a standard installation prefix. The binaries are relocatable, so we just need to make sure we build on a suitably old distro (currently CentOS8) and document libraries we assume exist (X11, some libxcb libraries, etc.). Works well enough. But yes, if you don't want to ship everything above the "bare bones", you'll need a per-distro package.

Shared libraries

Posted Dec 1, 2025 8:58 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

The other solutions work when you have a rich monopolistic sugar daddy to pay for the base OS. Because the other solutions are totally ineffective to build this base OS and require the injection of loads of capital and management directives to achieve the same result.
A lot of us are not interested in hanging FLOSS decorations on a monopolistic closed system.

Shared libraries

Posted Dec 5, 2025 3:42 UTC (Fri) by dvdeug (subscriber, #10998) [Link] (1 responses)

> The critical difference between distro's “steaming pile of packages” and proper OS is an SDK: something that you can use to build your binary and, most importantly, target different versions of OS simultaneously.

It's relatively easy to do that on Windows, as Microsoft controls all the systems. It's not so easy to do that with Linux or *BSD, as there's multiple different forks you have to deal with. Flatpaks ultimately do what Windows does; ship all dynamic libraries with the program. I don't see any reason you don't accept that you can do that with a flatpak.

(Note that most people don't distribute native binaries for Android; the system compiles the APK into a native format. There are a bunch of "binary" formats that may or may not take an installation step, that you can run on different versions of Linux, ranging from well-designed compiled code to any number of interpreters to APKs and JARs. RenPY programmers distribute one binary package for Windows and Linux all the time.)

None of those are proper OSes; a proper OS has no users so there are no problems. Real systems have problems and make compromises. Distributing the same binary to versions of Linux from many times, from many vendors was not one of the driving goals behind Linux, so the compromises it demands weren't made. Note that Windows binaries, include ones built from post-2010 .NET, don't generally run across architectures; ARM Windows will emulate x86 binaries, but the x86-64 emulator is a lot more fragile and experimental, and x86-64 Windows won't run ARM Windows binaries.

So, yes, Linux can do it, using flatpaks or other options, no, Windows can't do it if you want to use a modern Windows SDK and target both ARM Windows and x86 Windows at the same time.

Shared libraries

Posted Dec 5, 2025 9:28 UTC (Fri) by taladar (subscriber, #68407) [Link]

If you really want to you can emulate Linux binaries from other architectures relatively transparently using qemu-user and binfmt_misc. Of course you still need a full set of libraries for them just as you would if you ran the code on that platform. Mostly it is useful for things like chroots with mounted SD-Cards for low power embedded devices where the emulation on your PC is still much faster and has more RAM available to compile stuff.