> So if I have a full set of gnome applications (say 50) would I have 50 copies of Adwaita icon set?
No. Icons is easier to load with regular open/read, then with dlopen. But in any case they go into separate files, they are not in a binary.
Dynamic loading might be used to load data into the process, but it will be a very strange way to do it.
> And just because shared libs are PITA it's not just because of their nature, it's the lack of tooling from supposedly modern languages, ...
It is more complex than this. Dynamic linkage is limited in its ways. It couldn't do a type parametrization, for example. All it could do is to fill gaps in a code with function addresses. But it is not enough. Far not enough. For instance, you wouldn't like to dynamically link a c++ vector, because it is meant to be inlined and highly optimized then. Dynamic linker cannot inline or optimize.
So you are forced to use a lot of inlining at the stage of the static linking of the application binary, but then you get a problem of binary incompatibility between an app and a lib coming from lib being rebuilt with different optimizations.
So I'd say, that modern linux distributions should adapt to modern languages (like c++, lol), not vice versa.
> Each of these problems can be solved by not sweeping them under the rug.
For what end? What we possibly might gain, from solving these problems? Dynamic linkage is a runtime cost. Why should we prefer runtime costs to compile-time ones?
No. Icons is easier to load with regular open/read, then with dlopen. But in any case they go into separate files, they are not in a binary.
Dynamic loading might be used to load data into the process, but it will be a very strange way to do it.
> And just because shared libs are PITA it's not just because of their nature, it's the lack of tooling from supposedly modern languages, ...
It is more complex than this. Dynamic linkage is limited in its ways. It couldn't do a type parametrization, for example. All it could do is to fill gaps in a code with function addresses. But it is not enough. Far not enough. For instance, you wouldn't like to dynamically link a c++ vector, because it is meant to be inlined and highly optimized then. Dynamic linker cannot inline or optimize.
So you are forced to use a lot of inlining at the stage of the static linking of the application binary, but then you get a problem of binary incompatibility between an app and a lib coming from lib being rebuilt with different optimizations.
So I'd say, that modern linux distributions should adapt to modern languages (like c++, lol), not vice versa.
> Each of these problems can be solved by not sweeping them under the rug.
For what end? What we possibly might gain, from solving these problems? Dynamic linkage is a runtime cost. Why should we prefer runtime costs to compile-time ones?