>> 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.
So then there is a bug from what I understand, or cfitsio in MacPorts is being built incorrectly. Compare file names for the newer Cfitsio: /opt/local/lib/libcfitsio.6.3.44.dylib /opt/local/lib/libcfitsio.6.dylib -> libcfitsio.6.3.44.dylib (symlink) and the older Cfitsio: /opt/local/lib/libcfitsio.5.3.41.dylib /opt/local/lib/libcfitsio.5.dylib -> libcfitsio.5.3.41.dylib (symlink)
