The same has to happen with druntime and Phobos2 or otherwise our
programs will break with every new release that deprecates or changes
non-template functions. That would probably be *every* release at the
moment, so it could look like this:
/usr/lib64/libphobos2.so (link to /usr/lib64/libphobos2.so.060)
/usr/lib64/libphobos2.so.058
/usr/lib64/libphobos2.so.059
/usr/lib64/libphobos2.so.060
/usr/lib64/libdruntime.so (link to /usr/lib64/libdruntime.so.060)
/usr/lib64/libdruntime.so.058
/usr/lib64/libdruntime.so.059
/usr/lib64/libdruntime.so.060
And you don't consider this insane?
The 'shared' approach is fine if a library has settled and is used
pervasively like C runtime.
Also the library needs to have an appropriate development approach with
major (feature) revisions and smaller non-breaking versions.
Phobos is a fast-moving target and doesn't fit in this model neither will
it in the foreseeable future.
Why do people always treat D like a mainstream language? It isn't.
The chance that one has more than a few real D apps on one's machine is
quite low. The chance that they use the very same version of
phobos/druntime is even lower.
And usually the only ones you actually use are developed by yourself
anyway.
I rather have a slightly bigger executable than having my system cluttered
with hundreds of phobos versions I don't need.
And you should keep in mind that dmd's phobos is currently 17MB, gdc's is
25+5.5. Plus most apps only use a small share of that.
Making druntime shared sometime is ok I think, but it's just not ready
yet. See the recent associative arrays dilemma. And the crappy GC.
