On 2018-4-25 01:25 , Artur Szostak wrote: > Hi, > > I have a Portfile for a library (called CPL) that was linked against Cfitsio > from a week ago. Cfitsio was updated very recently. What I expect is that > during the installation of CPL, MacPorts is able to figure out that Cfitsio > changed and that CPL needs to be rebuilt. However, during the "Scanning > binaries for linking errors" stage it indicates "No broken files found". Why > would the MacPorts mechanism not be working? > > The relevant parts from "otool -L /opt/local/lib/libcfitsio.dylib": > /opt/local/lib/libcfitsio.dylib (compatibility version 6.0.0, current > version 6.3.44) > and from "otool -L /opt/local/lib/libcplcore.dylib": > /opt/local/lib/libcplcore.26.dylib (compatibility version 28.0.0, > current version 28.0.0) > /opt/local/lib/libcfitsio.dylib (compatibility version 5.0.0, current > version 5.3.41) > > Surely MacPorts should see that what libcplcore.dylib was linked against is > no longer compatible with the installed libcfitsio.dylib? or am I not > understanding how compatibility version is working on MacOS?
An increased compatibility version means that symbols have been added. A program thus can't run with an older compatibility version of a library than it was built against, but it can run with a newer one. If symbols are removed or their semantics change, the library major version needs to change. This is part of the install_name, e.g. "26" in the case of libcplcore. If libcfitsio is not changing its install_name when its ABI changes incompatibly, that's a problem. - Josh Reference: <https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html#//apple_ref/doc/uid/20002255-BCIECADD>
