On Jun 4, 2012, at 3:25 PM, Josh Triplett <j...@joshtriplett.org> wrote:
> On Mon, Jun 04, 2012 at 02:52:51PM -0700, Jeremy Huddleston wrote: >> On Jun 4, 2012, at 2:19 PM, Adam Jackson <a...@redhat.com> wrote: >>> On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote: >>>> On Jun 4, 2012, at 1:34 PM, Julien Cristau <jcris...@debian.org> wrote: >>>> Think about this from the libc perspective. libc *may have* strlcat >>>> or not, but they're named the same because all functions in libc have >>>> consistent signatures. >>> >>> A libc that had strlcat once, and then removed it, would no longer have >>> the same ABI. An application that had successfully linked against the >>> old libc's strlcat would reasonably expect it to be present at runtime >>> too. >> >> That argument breaks down when you reverse it. The "rules" state that the >> SONAME should not change when adding APIs. If all you're basing this on is >> SONAME, then there is absolutely no difference between the adding and >> removing case. If I link against a "newer" libc which has strlcat, then by >> your argument, I'd expect strlcat to be present on any libc matching that >> SONAME. When I run my application with the older libc without strlcat, it >> will fail to find it. > > That represents the difference between major and minor version changes. > When you add a new function (or otherwise extend the ABI, such as by > adding new flags to a flags parameter), you increase the minor version, > so that applications built against the new library won't run with the > old one, but applications built against the old one (and thus not > expecting the new function) will still work with the new library. > However, when you *remove* a function, applications built against the > old library will not work with the new one, so you have to bump the > major version. I guess this is where the "OS X" paradigm and the GNU paradigm just break down. Is there actually annotation done to specify that a specific function was added for a given minor version bump of a library? Does the loader just require that the runtime version be >= the linktime version (that seems particularly dangerous to me)? How is this actually enforced in practice? My understanding was that the minor version was nothing more than extra bits as a guide to the user or packager and that there wasn't actually any "real" mechanism in place to deal with this properly (ie weak linking the new symbols). >> SONAME is not the solution to this problem. The best practice is to >> properly annotate "new" functions (so they are weak linked) and not remove >> public API until it is really warranted. >> >> If you're removing a fringe API that is only used internally, then I'd argue >> against SONAME change. > > Only if you know for sure that it won't break any real applications; in > other words, does this represent de-facto public API, or not? Based on the commit logs, I was under the impression that these functions were only meaningful to already-removed functionality. If the removal of that functionality didn't even warrant a version bump, why would removing its support APIs? _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
