Binary packages not rebuilding against updated libraries

[Ryan Schmidt]

On Apr 24, 2018, at 11:37, Artur Szostak wrote:

>>> 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.
> 
> Considering the following full dump from otool:
> 
> macosx-10-13:~ vagrant$ otool -L /opt/local/lib/libcfitsio.6.dylib 
> /opt/local/lib/libcfitsio.6.dylib:
>        /opt/local/lib/libcfitsio.dylib (compatibility version 6.0.0, current version 6.3.44)
>        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>        /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
> 
> since /opt/local/lib/libcfitsio.dylib is indicated rather than /opt/local/lib/libcfitsio.6.dylib, do you agree this is a bug in cfitsio then?

Yup. Thanks for filing the bug report with the patch:

https://trac.macports.org/ticket/56347