This is not as easy as it sounds, because funny things happen if you ship your own libc - I remember last time I tried this there were problems with PAM and name services. But that was a number of years ago.

Can you ship with your own version of GNOME different from the currently running one?

> Can you ship with your own version of GNOME different from the currently running one?

I'm confused. GNOME is a desktop environment. It implements a task bar, a control panel, a way to set your desktop wallpaper etc. Why would you ship GNOME?

Maybe you meant shipping a proprietary application that uses a GTK version that is different than the OS-provided GNOME uses?

If so, of course you can. GTK is a bunch of shared objects that generate system calls, X messages, etc. It has no reason to interfere with the OS-provided GTK as long as it's got everything it needs in your bundle.

This doesn't work for things that are dynamically loaded into other applications (as VSTs are). In general, you need to be using the same version of the libraries as the rest of the application.

Your suggestion to ship glibc caused coffee to end up over my keyboard :) This is the road to hell, but you'd only know that if you had the slightest clue of the ABI interactions involved in swapping out a core library like that - starting with the reality that parts of the (probably binary-only) graphics stack must be linked and loaded in-process, and they naturally depend on at a minimum glibc. Your suggestion is to effectively ship the game in the form of its own Linux distro, which is of course complete nonsense.

Snap and Flatpack will hopefully help with the dependency aging problem, but they're brand new, and they both still suck one way or another.

To give you an idea of what swapping out glibc would involve, here is the list of shared libraries loaded by 'glxgears' on my machine, arguably the simplest possible OpenGL program:

    /lib/x86_64-linux-gnu/ld-2.28.so
    /lib/x86_64-linux-gnu/libbsd.so.0.9.1
    /lib/x86_64-linux-gnu/libc-2.28.so
    /lib/x86_64-linux-gnu/libdl-2.28.so
    /lib/x86_64-linux-gnu/libexpat.so.1.6.8
    /lib/x86_64-linux-gnu/libgcc_s.so.1
    /lib/x86_64-linux-gnu/libm-2.28.so
    /lib/x86_64-linux-gnu/libnsl-2.28.so
    /lib/x86_64-linux-gnu/libnss_compat-2.28.so
    /lib/x86_64-linux-gnu/libnss_files-2.28.so
    /lib/x86_64-linux-gnu/libnss_nis-2.28.so
    /lib/x86_64-linux-gnu/libpthread-2.28.so
    /lib/x86_64-linux-gnu/librt-2.28.so
    /lib/x86_64-linux-gnu/libz.so.1.2.11
    /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
    /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1.0.0
    /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0
    /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1.0.1
    /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
    /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0
    /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libpciaccess.so.0.11.1
    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
    /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
    /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0
    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
    /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0
    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
    /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0
    /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0  
    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 
    /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
    /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
    /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0
    /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0

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.

This is added complexity that neither the Windows nor Macintosh runtimes demand of their developers.

Windows actually does require this, which is why applications tend to ship with (or otherwise require) some kind of C(++) runtime, like those provided by MSVC or MinGW. Some rely on these being installed separately, while others include them as part of the app's installation process. Same deal for .NET. I haven't done enough macOS development to confirm or deny, but I'd assume the situation is similar there, too.

The actual difference is that Visual C++ and XCode (presumably) automate most or all of this, since this is the standard way of compiling and distributing applications for those platforms. In contrast, Linux development tends to revolve around software that can be recompiled for each distribution, so the tooling is going to be optimized around a workflow of relying on system-wide libraries and binaries and other data managed by a package manager.

Great and now I have to also track security updates and ship those for all my dependencies. libcurl is a great example with a release cycle of 2(!) months and tons of vulnerabilities being fixed each time.

That is completely ridiculous. Pointing out that statically compiling dependencies or shipping them with a game can solve many so called compatibility problems is directly related to games working on linux.

It is also the solution they currently use on Windows ... And what games are doing on Steam that support Linux.

I won't comment on shipping your own glibc, because that probably could cause issues.

As you can see, both comments were indeed flagged by one of those stackexchange types that is always marking useful questions as off-topic. Probably the same person who thinks using anything but rpm is bad.

The thread has then been detached for the crime of discussing voting, so only we can see it.

The first rule of HN voting is not to discuss voting.

It's a wonderful idea - on paper, but all that's needed is for one of the many mandatory deps for running a GL program to link against the system libcurl or any other replaced dep and you're back in Crashville again, population 1 - cloth-eared developer

Are there mandatory dependencies for running a GL program that can't work without using the system libcurl shared library? How does that make any sense?

If you distribute and link libcurl v69 dynamically, the dynamic linker symbol table for your process will contain references to v69 symbols. If you then load an e.g. GL driver that in turn links libcurl v42, the GL driver will end up with some combination of v69 and maybe v42 symbols, despite being compiled against v42 headers containing v42 struct sizes and offsets.

Now there is an opportunity for silent memory corruption in your program, one that even once detected, which may not happen for years, cannot easily be fixed without completely rearchitecting the build.

When using a wide variety of system APIs including at least NSS and OpenGL, there is little control over what dynamic libraries end up loaded, the exact configuration will vary across machines

Substitute libcurl for libexpat or libX11 or libstdc++ and the principle continues to apply. I can't think of a good reason something like libcurl would be used by the Nvidia driver or some bizarro embedded board's GL driver, but that doesn't mean the Nvidia driver doesn't now or in the future link it, and if/when that day arrives, the problem lies entirely with the program that mixed random system deps with random self-compiled deps.

> If you distribute and link libcurl v69 dynamically,

This whole thread is about avoiding this.