>>> Not quite. I'm noting that the package version isn't a reliable >>> indication of the ABI version, and neither (sadly, see the current >>> protobuf issues and the issues with LibreSSL) is the library dylib >>> name. Thus I'm proposing to have an internal ABI revision number that >>> we can use for deciding whether dependents need a rebuild. >> >> I haven't followed the protobuf issue closely enough to be able to comment >> on it here. If they use the same install_name for incompatible versions of >> their library, their development process is erroneous. >> > Now that I've taken a quick look at it, protobuf3-cpp provides > libprotobuf.15.dylib > while protobuf-cpp provides libprotobuf.9.dylib. Since they are different > major > versions of the software, their dylib name and therefore install_name are > different. > This seems perfectly normal and expected to me.
Now what would be a really powerful tool, would be something that can check that the following mistake was made: the major number is not changed correctly for shared libraries that are in fact not compatible with each other. This is exactly what happened in the cfitsio package. However, I'm afraid that this would be non trivial.
