Ignoring your personal attacks, you and I are on the same page.

I do agree that shipping your glibc is "the road to hell" and shipping with the glibc could be qualified as "shipping in the form of its own Linux distro", as amusing as that sounds :) But that's the price of freedom you pay if you want to draw your platform boundary at the kernel -- you need to ship the whole userland! Where's the surprise in that? That means you need to understand the interactions between different version of /usr/lib64/opengl/nvidia/lib/libGLX_nvidia.so.0 (that you need to ship) and nvidia.ko (that is nvidia's binary driver loaded by the kernel, that you do NOT ship)

That's what people mean when they say they "are targeting Linux", even when they don't really understand the kind of work that that statement entails :)

Linux is an OS kernel. I'd wager it's the most popular one by far, in terms of the number of platforms that uses it.

Saying that "Linux is fragmented" is the wrong way to look at the problem. One should rather realize that Linux is just and OS kernel that is used by countless platforms. It's up to the developer to draw platform boundaries and focus engineering effort on the chosen ones.

If you need to support GNU/Linux with glibc-2.25, then you need to set up your testing bench to accommodate that. If you need to have native look and feeling in ubuntu, kubuntu and lubuntu, you already have 3 platforms with at least 2 LTS versions that you need to test with.

Each platform has its own quirks. Linux distros are the ones with the least amount of quirks, but in exchange we get many many platforms, because it's so easy to create them.

I guess that's life :)

Why would you want to take on that massive burden for such a tiny percentage of sales - most of which you'd have gotten anyway?

glibc is pretty good at ABI backwards-compatibility. The right thing to do would be to statically link libstdc++, libgcc, and extras like libcurl, but dynamically link libc, libX11, and libGL. Luckily libX11 and libGL are pure-C so you can get away with static-linking libstdc++, which means you can use whatever C++ version you like.

It's definitely technically possible to find a hacky combination that works today, but only by shouldering the cost of understanding all the possible deps and symbols and the structure of their underlying objects used by all possible e.g. graphics drivers and X11 libraries now and into the future. You can hack around it today, but it's a fool's game and absolutely not something that can be relied on to continue working in any sound manner, without risking e.g. some memory corruption due to a struct layout difference long in the future, etc.

I wanted to check whether the official Nvidia driver uses C++, but it's not installed on this machine just now, and of course that I even have to check just highlights the problem with this approach.

> I wanted to check whether the official Nvidia driver uses C++,

I don't know for nvidia, but I had a problem two years ago on a machine with a radeon card: I was developing a GUI software which used LLVM at some point. Insta-crash at runtime on this computer whenever I'd oepn a window. The reason ? the radeon driver linked and initialized LLVM which didn't support being initialized twice...

There's no other option, though. If you aren't integrated into the distros' builds, then you have no way of getting your binary updated when a dependency makes an ABI-incompatible change -- much less shipping a single binary that works across all distros. The only reasonable option is to determine a subset of your dependencies which offer long-term stable ABIs, dynamically link those, statically link the rest, and hope for the best.

But there is another option, it was mentioned in the original complaint :)

> So it means for every product, have a build for every distro / version combination you want to support.

Of course it's a total pain in the ass, but it's still vastly preferable to unfixable bugs sometime in the distant future

I'm not sure how per-distro (or distro-version) builds fix the problem, unless you're committing to continuously produce new builds for future distro versions to account for ABI changes. If you can do that, you can also fix issues with static linking if/when the come up.

There's a better solution: don't ship on an OS that insists on being a pain in the ass to ship on.