Binary packages not rebuilding against updated libraries
Joshua Root
jmr at macports.org
Tue Apr 24 15:42:27 UTC 2018
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>
More information about the macports-dev
mailing list