Recent Features
| |||||||||||||
Slackware 14 releasedSlackware 14 releasedPosted Oct 1, 2012 14:15 UTC (Mon) by vonbrand (subscriber, #4458)In reply to: Slackware 14 released by geofft Parent article: Slackware 14 released
No. One of the (many) benefits of dynamic linking is that you can change the library (as long as the ABI remains) under the executables. Thus, a change to fix, e.g. a security problem, doesn't require rebuilding the world. If the library developer is careful, this can work for a surprisingly long range. And you can (via library versions) have several ABIs supported at the same time.
(Log in to post comments)
Slackware 14 released Posted Oct 1, 2012 19:24 UTC (Mon) by zlynx (subscriber, #2285) [Link]
Unfortunately the Linux community is lucky if the developer even notes an ABI change in the change log, let alone bumps the .so version or maintain versioned symbols. (Although as someone who maintains a proprietary C++ library for Linux, I understand what a pain versioned symbols are for anything but C.)
Of course if the developer does bump the .so version, good luck getting any bug fixes back-ported into the last version.
Slackware 14 released Posted Oct 4, 2012 0:26 UTC (Thu) by nix (subscriber, #2304) [Link]
For ABI additions, you're pretty much right (which means you can run older binaries on newer systems, but not generally vice versa). However, for ABI changes and deletions, soname compatibility is maintained pretty well for the vast majority of packages, and it is universally considered a bug if it is accidentally broken. Recently, even some of the odious old standbys like OpenSSL have come into the light. (Berkeley DB remains a frequent-breakage annoyance, but even it bumps its soname when appropriate. And often when not appropriate.)
|
|||||||||||||