9 ms·

Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolv

by tgtweak 8mo ago

Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager. Remember patching openSSL when heartbleed came around (libssHELL). Visual studio is a dog but at least it's one dog - the real hell on windows is .net framework. The sheer incongruency of what version of windows has which version of .net framework installed and which version of .net your app will run in when launched... the actual solution at scale for universal windows compatibility on your .net app is to build a c++ shim that checks for .net beforehand and executes it with the correct version in the event of multiple version conflict - you can literally have 5 fully unique runtimes sharing the same .net target.

giancarlostoro 8mo ago
I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.
- moogly 8mo ago
  Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun. Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.
pjmlp 8mo ago
Which has been fixed on .NET 5 and later. .NET Framework should only be used for legacy applications. Unfortunately there are still many around that depend on .NET Framework.
- foepys 8mo ago
  Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework. Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years. One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few interfaces and get most of it working (although not optimized by the CLR, e.g. Span). For an example see this project: https://www.nuget.org/packages/PolySharp/ https://www.nuget.org/packages/PolySharp/ It's also easy to target multiple framework with the same code, so you can write libraries that work in .NET programs and .NET Framework programs.
  - pjmlp 8mo ago
    Most likely never will, because WinRT is the future and WinRT has replaced type libraries with .NET metadata. At least from MS point of view. The current solution is to use the CLI tools just like C++. However have you looked into ComWrappers introduced in .NET 8, with later improvements? I still see VB 6 and Delphi as the best development experience for COM, in .NET it wasn't never that great, there are full books about doing COM in .NET.
- croes 8mo ago
  .Net Framework 4.8 has a longer life cycle as the current .NET version
  - pjmlp 8mo ago
    It does, but current versions can be shipped with the application. Thus this should be less of a problem.
  - 8cvor6j844qw_d6 8mo ago
    When I first worked with dot NET I was confused with the naming and version numbers.
    - 8mo ago
nanoxide 8mo ago
When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.
- croes 8mo ago
  .NET versions are faster outdated then .Net Framework 4.8
  - stackskipton 8mo ago
    Point? I’m SRE on .Net project, we have been through 6-8-10 and its cost us about 2ish hours of work each time. As long as you don’t get crazy, .Net upgrades is just matter of new SDK and runtime and away you go.
    - tgtweak 8mo ago
      You're talking about .net for server applications right? The discussion above is for client apps being distributed for windows endusers.
      - stackskipton 8mo ago
        We have a small MAUI part of the application, it's not massive but it's working fine with .Net Upgrades.
      - rblatz 8mo ago
        Just ship a self contained build?
        tgtweak 8mo ago
        This was a sidecar application distributed by literally millions of installs per day - so having a 25MB "self contained" build was out of the question - we were targeting KB-sized distributables not 10's of MB.
the__alchemist 8mo ago
This is one of the things that tilts me about C and C++ that has nothing to do with mem safety: The compile/build UX is high friction. It's a mess for embedded (No GPOS) too in comparison to rust + probe-rs.
- Pay08 8mo ago
  That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.
  - deleted 8mo ago
    [deleted]
  - the__alchemist 8mo ago
    Ah sorry. I should clarify. Not referring to specifically cross compiling; just general compiling. In rust weather PC or embedded, I run Cargo run. For C or C++, it's who knows. A provincial set of steps for each project, error messages, makes me get frustrated. I keep a set of notes for each one I touch to supplement the project's own docs. I am maybe too dumb or inexperienced in some cases, but I am having a hard time understanding why someone would design that as the UX. I want to focus on the project itself; not jump through hoops in the build process. It feels hostile. For cross compiling to ARM from a PC in rust in particular, you do one CLI cmd to add the target. Then cargo run, and it compiles, flashes, with debug output. These are from anecdotes. I am probably doing something wrong, but it is my experience so far.
    - Pay08 8mo ago
      That sounds like you don't have a build system for C/C++.
    - ryandrake 8mo ago
      I’m the opposite: I want my development tools to use my operating system’s package manager. Nothing enrages me quite like how, when I want to pull in a Python dependency, I have to reach for Python’s parallel package manager. Now I have to keep track of what apt installed and what pip installed. Then I move to do a rust project and there’s now another parallel package manager I need to use to install those dependencies! Yuck! apt install build-essential or whatever the rpm equivalent is, gets you most of the way to building a C or C++ project.
IshKebab 8mo ago
> python in another realm here as well uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly). At this point they should just deprecate Pip.
- LtWorf 8mo ago
  Ah yes let's all depend on some startup that will surely change the license at some point.
  - IshKebab 8mo ago
    Very clearly a better option than continuing to use Pip. Even if they do change the license in a few years I will definitely take several years of not being shat on by Pip over the comparatively minor inconvenience of having to switch to an open fork of uv when they rug-pull. If they ever do. Continuing to use Pip because Astral might stop maintaining uv in future is stupidly masochistic.
  - kingstnap 8mo ago
    pip is really bad though so UV has a long ways to fall before you aren't still net better off :^)
- rbanffy 8mo ago
  I have never experienced issues with pip, and I’m not sure it’s whether I’m doing something that pip directly supports and avoiding things it doesn’t help with. I’d really love to understand why people get so mad about pip they end up writing a new tool to do more or less the same thing.
  - IshKebab 8mo ago
    The problems with pip that uv fixes: 1. It's easy to install. 2. It's not dog slow. 3. It automatically sets up venvs. 4. It automatically activates the venv before running commands. 5. It supports a lock file out of the box. 6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore. 7. It installs your code in the venv in editable more by default. 8. It lets you install Python tools outside the venv (`uv tool install`). 9. It works reliably. There's probably more that I've forgotten. If pip had all of that nobody would have felt the need for a rewrite. And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.
calvinmorrison 8mo ago
> Toolchains on linux are not clear from dependency hell either - ever install an npm package. That's where I stopped. Toolchains on linux distributions with adults running packaging are just fine. Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine. I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.
- crote 8mo ago
  The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit. And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it. Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?
  - fao_ 8mo ago
    > The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit. This is only the case for debian and derivatives, lol. Rolling-release distributions do not have this problem. This is why most of the new distributions coming out are arch linux based.
    - Pay08 8mo ago
      I'm going to need a source for both of those claims.
TZubiri 8mo ago
>Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? That seems more a property of npm dependency management than linux dependency management. To play devil's advocate, the reason npm dependency management is so much worse than kernel/os management, is because their scope is much bigger, 100x more package, each package smaller, super deep dependency chains. OS package managers like apt/yum prioritize stability more and have a different process.
tomkarho 8mo ago
.NET does have flags to include the necessary dependencies with the executable these days so you can just run the .exe and don't need to install .net on the host machine. Granted that does increase the size of the app (not to mention adding shitton of dll's if you don't build as single executable) but this at least is a solved problem.
- tgtweak 8mo ago
  They do now, after .net core and several other iterations. You'll also be shipping a huge executable compared to a clr linked .net app (which can be surprisingly small).
  - cmoski 8mo ago
    Mine is 33mb. Could be smaller, but it does the trick.
arendtio 8mo ago
Well, traditionally, there was no Python/pip, JS/npm in Linux development, and for C/C++ development, the package manager approach worked surprisingly well for a long time. However, there were version problems: some Linux distributions had only stable packages and therefore lacked the latest updates, and some had problems with multiple versions of the same library. This gave rise to the language-specific package managers. It solved one problem but created a ton of new ones. Sometimes I wish we could just go back to system package managers, because at times, language-specific package managers do not even solve the version problem, which is their raison d'être.
- majoe 8mo ago
  Nix devShells works quite well for Python development (don't know about JS) Nixpkgs is also quite up to date. I haven't looked back, since adopting Nix for my dev environments.
vips7L 8mo ago
.net has been able to ship the runtime with your app for years.
eqvinox 8mo ago
> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.net/Articles/605607/ https://lwn.net/Articles/605607/ Now, if you're saying it's a dependency issue resulting from people specifying wrong glibc version constraints in their build… yeah, sure. I'm gonna say that happens because people are getting used to pinning dependency versions, which is so much the wrong thing to do with glibc it's not even funny anymore. Just remove the glibc pins if there are any. As far as the toolchain as a whole is concerned… GCC broke compatibility a few times, mostily in C++ due to having to rework things to support newer C++ standards, but I vaguely remember there was a C ABI break somewhere on some architecture too.
- HexDecOctBin 8mo ago
  > The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653 https://sourceware.org/bugzilla/show_bug.cgi?id=32653 Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first laptop)? __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");
  - eqvinox 8mo ago
    > https://sourceware.org/bugzilla/show_bug.cgi?id=32653 https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I would call something that affects primarily closed source binaries (and mono on i386) a "huge" issue either. The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything. > __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5"); A 12 year old forward compatibility issue that is fixed by upgrading glibc, okay. (Note this is the same timeframe as the s390 thing I linked.) I guess people shipping binaries need to be aware of it if they want to support glibc pre-2.2.14. That said, the general rule of shipping binaries is that you need to assume whatever you build against becomes the minimum required version, anything else is a gift. I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?

by tgtweak 8mo ago

giancarlostoro 8mo ago

I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.

moogly 8mo ago
Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun. Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.

pjmlp 8mo ago

Which has been fixed on .NET 5 and later. .NET Framework should only be used for legacy applications. Unfortunately there are still many around that depend on .NET Framework.

foepys 8mo ago
Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework. Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years. One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few interfaces and get most of it working (although not optimized by the CLR, e.g. Span). For an example see this project: https://www.nuget.org/packages/PolySharp/ https://www.nuget.org/packages/PolySharp/ It's also easy to target multiple framework with the same code, so you can write libraries that work in .NET programs and .NET Framework programs.
- pjmlp 8mo ago
  Most likely never will, because WinRT is the future and WinRT has replaced type libraries with .NET metadata. At least from MS point of view. The current solution is to use the CLI tools just like C++. However have you looked into ComWrappers introduced in .NET 8, with later improvements? I still see VB 6 and Delphi as the best development experience for COM, in .NET it wasn't never that great, there are full books about doing COM in .NET.
croes 8mo ago
.Net Framework 4.8 has a longer life cycle as the current .NET version
- pjmlp 8mo ago
  It does, but current versions can be shipped with the application. Thus this should be less of a problem.
- 8cvor6j844qw_d6 8mo ago
  When I first worked with dot NET I was confused with the naming and version numbers.
  - 8mo ago

nanoxide 8mo ago

When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.

croes 8mo ago
.NET versions are faster outdated then .Net Framework 4.8
- stackskipton 8mo ago
  Point? I’m SRE on .Net project, we have been through 6-8-10 and its cost us about 2ish hours of work each time. As long as you don’t get crazy, .Net upgrades is just matter of new SDK and runtime and away you go.
  - tgtweak 8mo ago
    You're talking about .net for server applications right? The discussion above is for client apps being distributed for windows endusers.
    - stackskipton 8mo ago
      We have a small MAUI part of the application, it's not massive but it's working fine with .Net Upgrades.
    - rblatz 8mo ago
      Just ship a self contained build?
      - tgtweak 8mo ago
        This was a sidecar application distributed by literally millions of installs per day - so having a 25MB "self contained" build was out of the question - we were targeting KB-sized distributables not 10's of MB.

the__alchemist 8mo ago

This is one of the things that tilts me about C and C++ that has nothing to do with mem safety: The compile/build UX is high friction. It's a mess for embedded (No GPOS) too in comparison to rust + probe-rs.

Pay08 8mo ago
That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.
- deleted 8mo ago
  [deleted]
- the__alchemist 8mo ago
  Ah sorry. I should clarify. Not referring to specifically cross compiling; just general compiling. In rust weather PC or embedded, I run Cargo run. For C or C++, it's who knows. A provincial set of steps for each project, error messages, makes me get frustrated. I keep a set of notes for each one I touch to supplement the project's own docs. I am maybe too dumb or inexperienced in some cases, but I am having a hard time understanding why someone would design that as the UX. I want to focus on the project itself; not jump through hoops in the build process. It feels hostile. For cross compiling to ARM from a PC in rust in particular, you do one CLI cmd to add the target. Then cargo run, and it compiles, flashes, with debug output. These are from anecdotes. I am probably doing something wrong, but it is my experience so far.
  - Pay08 8mo ago
    That sounds like you don't have a build system for C/C++.
  - ryandrake 8mo ago
    I’m the opposite: I want my development tools to use my operating system’s package manager. Nothing enrages me quite like how, when I want to pull in a Python dependency, I have to reach for Python’s parallel package manager. Now I have to keep track of what apt installed and what pip installed. Then I move to do a rust project and there’s now another parallel package manager I need to use to install those dependencies! Yuck! apt install build-essential or whatever the rpm equivalent is, gets you most of the way to building a C or C++ project.

IshKebab 8mo ago

> python in another realm here as well uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly). At this point they should just deprecate Pip.

LtWorf 8mo ago
Ah yes let's all depend on some startup that will surely change the license at some point.
- IshKebab 8mo ago
  Very clearly a better option than continuing to use Pip. Even if they do change the license in a few years I will definitely take several years of not being shat on by Pip over the comparatively minor inconvenience of having to switch to an open fork of uv when they rug-pull. If they ever do. Continuing to use Pip because Astral might stop maintaining uv in future is stupidly masochistic.
- kingstnap 8mo ago
  pip is really bad though so UV has a long ways to fall before you aren't still net better off :^)
rbanffy 8mo ago
I have never experienced issues with pip, and I’m not sure it’s whether I’m doing something that pip directly supports and avoiding things it doesn’t help with. I’d really love to understand why people get so mad about pip they end up writing a new tool to do more or less the same thing.
- IshKebab 8mo ago
  The problems with pip that uv fixes: 1. It's easy to install. 2. It's not dog slow. 3. It automatically sets up venvs. 4. It automatically activates the venv before running commands. 5. It supports a lock file out of the box. 6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore. 7. It installs your code in the venv in editable more by default. 8. It lets you install Python tools outside the venv (`uv tool install`). 9. It works reliably. There's probably more that I've forgotten. If pip had all of that nobody would have felt the need for a rewrite. And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.

calvinmorrison 8mo ago

> Toolchains on linux are not clear from dependency hell either - ever install an npm package. That's where I stopped. Toolchains on linux distributions with adults running packaging are just fine. Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine. I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.

crote 8mo ago
The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit. And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it. Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?
- fao_ 8mo ago
  > The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit. This is only the case for debian and derivatives, lol. Rolling-release distributions do not have this problem. This is why most of the new distributions coming out are arch linux based.
  - Pay08 8mo ago
    I'm going to need a source for both of those claims.

TZubiri 8mo ago

>Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? That seems more a property of npm dependency management than linux dependency management. To play devil's advocate, the reason npm dependency management is so much worse than kernel/os management, is because their scope is much bigger, 100x more package, each package smaller, super deep dependency chains. OS package managers like apt/yum prioritize stability more and have a different process.

tomkarho 8mo ago

.NET does have flags to include the necessary dependencies with the executable these days so you can just run the .exe and don't need to install .net on the host machine. Granted that does increase the size of the app (not to mention adding shitton of dll's if you don't build as single executable) but this at least is a solved problem.

tgtweak 8mo ago
They do now, after .net core and several other iterations. You'll also be shipping a huge executable compared to a clr linked .net app (which can be surprisingly small).
- cmoski 8mo ago
  Mine is 33mb. Could be smaller, but it does the trick.

arendtio 8mo ago

Well, traditionally, there was no Python/pip, JS/npm in Linux development, and for C/C++ development, the package manager approach worked surprisingly well for a long time. However, there were version problems: some Linux distributions had only stable packages and therefore lacked the latest updates, and some had problems with multiple versions of the same library. This gave rise to the language-specific package managers. It solved one problem but created a ton of new ones. Sometimes I wish we could just go back to system package managers, because at times, language-specific package managers do not even solve the version problem, which is their raison d'être.

majoe 8mo ago
Nix devShells works quite well for Python development (don't know about JS) Nixpkgs is also quite up to date. I haven't looked back, since adopting Nix for my dev environments.

vips7L 8mo ago

.net has been able to ship the runtime with your app for years.

eqvinox 8mo ago

> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.net/Articles/605607/ https://lwn.net/Articles/605607/ Now, if you're saying it's a dependency issue resulting from people specifying wrong glibc version constraints in their build… yeah, sure. I'm gonna say that happens because people are getting used to pinning dependency versions, which is so much the wrong thing to do with glibc it's not even funny anymore. Just remove the glibc pins if there are any. As far as the toolchain as a whole is concerned… GCC broke compatibility a few times, mostily in C++ due to having to rework things to support newer C++ standards, but I vaguely remember there was a C ABI break somewhere on some architecture too.

HexDecOctBin 8mo ago
> The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653 https://sourceware.org/bugzilla/show_bug.cgi?id=32653 Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first laptop)? __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");
- eqvinox 8mo ago
  > https://sourceware.org/bugzilla/show_bug.cgi?id=32653 https://sourceware.org/bugzilla/show_bug.cgi?id=32653 dlopen and dlmopen no longer make the stack executable if a shared library requires it I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I would call something that affects primarily closed source binaries (and mono on i386) a "huge" issue either. The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything. > __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5"); A 12 year old forward compatibility issue that is fixed by upgrading glibc, okay. (Note this is the same timeframe as the s390 thing I linked.) I guess people shipping binaries need to be aware of it if they want to support glibc pre-2.2.14. That said, the general rule of shipping binaries is that you need to assume whatever you build against becomes the minimum required version, anything else is a gift. I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?