Gnome and KDE run in userspace. They are desktop environments, they don't "break userspace".
I feel like you're talking about GTK and Qt, both of which (don't break userspace either) are libraries you can statically link and nothing will break.
they both break library compatibility and break their environment (like when kde removed the widget toolbar and a whole lot of app suddenly stopped working)
sure you can have bunch of ifdef in the code, and an autoconf, and make sure you support a wide set of options, but that is basically the whole point, it makes for a painful experience and costlier, slower development (for closed source application that comes prepackaged)
I feel like you do not understand the concept of static linking, because the entire point is that you don't need a bunch of ifdefs, since you target exactly the version you develop against and ship with it.
The problem is services and non-ABI/non-library APIs. The way I suspect that this is set up is that there is precisely one KDE widget displayer service at any given time, running as part of the desktop environment and presenting an IPC interface that widgets talk to to get themselves added to the widget display area that the window manager maintains. You can link statically to the KDE widget client libraries all you want; if the KDE widget server decides to change the language it speaks, your widgets are hosed unless you included a not-a-widget mode that makes it a normal window. Seeing as how widgets tend to have special build systems (or, worse, the widget server is actually an interpreter for a declaration-heavy widget definition language that's not strictly plaintext), I don't think I've ever seen a widget with a non-widget mode supported.
"Breaking userspace" probably is a misnomer, if only because userspace has a precise technical definition. This is more like changing an interpreted language without maintaining backwards compatibility (python3, anybody?) or changing a json API.
While that may very well be true I feel like this doesn't have much to do anymore with:
> with the ABI changing every year for no reason and yet having to support users having all kind of version combinations.
To which I originally replied. And my point here still stands. I'm not arguing about the backwards or forward compatibility of every single library that might or might not use an IPC mechanism to talk to another component which could break if they're different versions.
the example I gave is exactly how stuff has broken in projects. static linked on a kde library that had widget, new one doesn't have that nor a fallback, application crashes.
or just go get some old static compiled stuff run on your modern distro and see yourself. like, mindrover the europa project port.
Completely off topic but thank you ! I was starting C programming and I was wondering how to check an executable dependencies. If I were to package an executable which was dynamically linked to use it on another computer without recompiling binaries, how could I proceed ? does ldd show the dependencies of the dependencies too ? Would it be sufficient to put all shared libraries into the same folder as the executable ? thanks.
Even better, one can embed the relative path to dynamic libraries by editing the RPATH or RUNPATH attributes in the binary (and using $ORIGIN in the path). Check out chrpath and patchelf.
