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? 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? 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. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87wqqyqw8x....@windlord.stanford.edu
