https://issues.dlang.org/show_bug.cgi?id=16794
--- Comment #6 from hst...@quickfur.ath.cx --- To be frank, versioning problems with shared libraries are the fault of the distributors (i.e., us). The current way shared libraries work, the only sane setup is to make the shared library name (or more specifically, the version part of it) *unique* across all potentially-incompatible builds, even if they are ultimately built from the same version of the compiler toolchain. And when linking, executables should link to the specific version of the library that they are compiled with, not with a generic name like libphobos.so that will pick up whatever version you currently have installed, because that WILL break as soon as you upgrade the library. (This is especially bad with our current state of affairs where basically every compiler release is ABI-incompatible with the previous release.) Currently it seems libphobos.so is versioned by DMD release, which apparently makes sense but actually is not good enough. The version must be bumped for every ABI-incompatible change, not just when the API changes. This includes compiler flags used when building the shared library that may introduce ABI-breakages. But this approach is also troublesome because it means the .deb's must be built in a way that multiple versions of libphobos.so must be simultaneously installable, otherwise after upgrading to the new release the older libphobos.so is gone and all your old executables won't run anymore. Debian does provide the mechanisms for doing this, but it's pretty involved, and I'm not sure if we have the manpower to babysit a potentially large set of libphobos packages that have to be simultaneously maintained for a good amount of time in order not to break old executables. In comparisons, static linking looks pretty attractive to me. Especially at this stage in D's development. --