On 2012-10-30 21:02, H. S. Teoh wrote:
But doesn't that mean the version wasn't correctly depended upon?
There should NEVER be generic dynamic library dependencies (i.e., "I can
link with any version of libc"), because they are almost always wrong in
some way. Maybe not obvious at first, but still wrong. They should
always depend on the *exact* version (or versions) of a library.
Anything else is fundamentally broken and will eventually cause
headaches and sleepless nights.
Mind you, though, a lot of libraries have a totally broken versioning
system. Many library authors believe that the version only needs to be
bumped when the API changes. Or worse, only when the existing API
changes (new parts of the API are discounted.) That is actually wrong.
The version needs to be bumped every time the *ABI* changes. An ABI
change can include such things as compiling with different flags, or
with a different compiler (*cough*gdc*dmd*cough*), *even when the source
code hasn't been touched*. Any library that breaks this rule is
essentially impossible to work with, because there is no way to
guarantee that what gets linked at runtime is actually what you think it
is.
Unfortunately, in practice, both of the above are broken repeatedly.
I completely agree. See my answer about RubyGems and Bundler:
http://forum.dlang.org/thread/ycigekrnsvjuulbxu...@forum.dlang.org#post-k6pc33:241ma3:241:40digitalmars.com
Packages in RubyGems are using Semantic Versioning:
http://semver.org/
Which is supposed to help with these problems. But Ruby doesn't have a
problem with breaking an ABI.
--
/Jacob Carlborg
