libphobos.so libdruntime.so

[Trass3r]

> 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.