Binary packages not rebuilding against updated libraries

[Joshua Root]

On 2018-4-25 02:05 , 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.
> 
> 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)

That in itself looks reasonable, but the important thing is the actual
install_name. From your first post that appears to be
"/opt/local/lib/libcfitsio.dylib", whereas it apparently should be
"/opt/local/lib/libcfitsio.6.dylib".

So yes, libcfitsio seems to be linked incorrectly. Whether that's an
upstream issue or a MacPorts one I don't know.

- Josh