Hi! On Thu, 2013-05-16 at 17:35:10 -0700, Russ Allbery wrote: > I have a C shared library that takes a pointer to an opaque struct as the > first argument to most of its API calls. The internal layout of that > opaque struct is changing (to add new members). The only way to create > the opaque state struct is via a call to remctl_new(), which returns a > pointer to it. Nothing else about the ABI is changing, and client > programs cannot see or manipulate the struct members directly (at least > without poking about in memory, of course). > > Is that an ABI break that requires an SONAME change?
Nope, that's the customary way to preserve ABI. > If you have two versions of the library loaded in memory at the same time, > call remctl_new() from one version, and then call functions from the other > version, this will break horribly, since the struct layout has changed and > will be misinterpreted. However, all the ABI calls are identical between > the two versions of the library, so this would require the dynamic linker > resolve two calls to the same library differently. Also, if both > libraries have the same SONAME, I don't see any way that you could load > two versions into memory at the same time without playing tricks with > dlopen() that I don't see any reason to support. > > Is that something that one has to guard against, or can one assume that > the ABI calls from a client of a shared library will be consistent in this > situation: that all the symbols will resolve to the same version of the > shared library when both share the same SONAME? Yeah that should be the case, the dynamic linker should not be loading the same SONAME multiple times, so there should be no race here, and I agree dlopen()ing shared libraries in general should not be supported (I'd even go further and say this should be outright banned, given the pain it causes, and optional library support should always be implemented by loading a plugin properly linked against such library with an ABI under the control of the program loading it). > I'm pretty sure this change is not an ABI break, but the more I thought > about it, the more I wasn't absolutely certain that I had the right mental > model here, so I thought I'd ask. It could be problematic in case there's more than one instance of the library with different SONAMEs used by other stuff and none use versioned symbols, but that's not the case you were presenting here so... Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130517051748.ga6...@gaara.hadrons.org
