libpng breaks compatibility in mac each time with a patch version

[183amir]

This is happening again: https://travis-ci.org/conda-forge/bob.ip.facedetect-feedstock/jobs/163096192

Matplotlib is compiled against libpng 1.6.24 but does not work with libpng 1.6.23 as seen in the log above.

@ocefpaf we have discussed this before but again you advised against pinning it on a patch version. If it doesn't work what's the point of having more flexible pinnings?

Same thing last time: #3

[183amir]

Also discussed here: conda-forge/matplotlib-feedstock#41

[stuarteberg]

Is this just a bug in the libpng build scripts for Mac? If I understand this table correctly, there should be no need to change the compatibility version for minor releases.

Here's a link to Apple's documentation for setting the compatibility version at build time. Does anyone know how to patch the libpng sources to make them use it correctly?

[183amir]

No library guarantees that it will work with an older version if you compile with a newer version. There is no such thing. The only thing they guarantee is that if you build it with an old version, it will work with newer versions too. Hence the pinnings should be like this:

requirements:
  build:
    - libpng 1.6.23
  run:
    - libpng >=1.6.23,<1.7

Conda build 3 makes implementing this very easy using the variants: https://conda.io/docs/building/variants.html
which would make the recipe look like:

requirements:
  build:
    - libpng {{ libpng }}
  run:
    - {{ pin_compatible('libpng', max_pin='x.x') }}

There are different and better ways too. read here: https://conda.io/docs/building/variants.html

[stuarteberg]

Thanks for the pinning syntax; that's useful.

No library guarantees that it will work with an older version if you compile with a newer version.

IIUC, some libraries can, at least within certain constraints. Right? All that matters is the ABI compatibility, which is determined by whether or not they added any new symbols between releases. For example, you can build a python extension module against libpython.so from python 2.7.12, but then give it to your friend who uses python 2.7.3.

Libpng doesn't use semantic versioning per se, but it turns out that most libpng patch updates are nonetheless ABI-compatible with previous versions, at least according to the ABI Laboratory. Unless I'm missing something (which could be the case), there is no need for the libpng's configure script to increment the -compatibility_version with every patch release.

[183amir]

IIUC, some libraries can, at least within certain constraints. Right? All that matters is the ABI compatibility, which is determined by whether or not they added any new symbols between releases. For example, you can build a python extension module against libpython.so from python 2.7.12, but then give it to your friend who uses python 2.7.3.

libpng does add symbols between patch versions so it doesn't work.

but it turns out that most libpng patch updates are nonetheless ABI-compatible with previous versions

Those few are going to break people's installations.

Unless I'm missing something (which could be the case), there is no need for the libpng's configure script to increment the -compatibility_version with every patch release.

Maybe not with every patch release but for some yes (when they add symbols). But anyway, the pinning syntax that I gave you works, right? I have been doing this in our Bob channel for a long time now: https://gitlab.idiap.ch/bob/bob.conda/blob/2011b52a9cb197f1ee02d4b57e94cca77eb717d9/recipes/bob.io.image/meta.yaml#L28

The thing is that you do not know what libpng developers are going to do in future so you better pin packages properly instead of having to pull them later. You can also read on this pull request here: conda-forge/conda-forge.github.io#245 and conda-forge/conda-forge.github.io#170

[ocefpaf]

Closing this as stale. We are moving to conda-build 3 which will improve this situation.