On 17-05-13 02:35, 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?
No. The return values of all your functions are still void* (or struct foo*, where struct foo is not defined for the library user), which has the exact same signature. > 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, Yes. If you're going to support that, you need symbol versioning. This is somewhat complicated, and I would recommend against it unless you really need it. > 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. If a program links your library statically in but loads plugins (one of which might also load your library, but dynamically) you have the same problem. However, doing something like that is a bad idea for multiple reasons (including this one), so I wouldn't worry about it too much. > 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. I'm pretty sure you're right. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/519728ea.6010...@debian.org
