conda-forge / libpng-feedstock

A conda-smithy repository for libpng.

About libpng-feedstock

Feedstock license: BSD-3-Clause

Home: http://www.libpng.org/pub/png/libpng.html

Package license: zlib-acknowledgement

Summary: PNG reference library

Development: https://sourceforge.net/p/libpng/code/ci/libpng16/tree/

Documentation: http://www.libpng.org/pub/png/libpng.html

libpng is the official PNG reference library. It supports almost all PNG features, is extensible, and has been extensively tested for over 20 years.

Current build status

Azure

Variant Status linux_64 linux_aarch64 linux_ppc64le osx_64 osx_arm64 win_64

Current release info

Name	Downloads	Version	Platforms

Installing libpng

Installing libpng from the conda-forge channel can be achieved by adding conda-forge to your channels with:

conda config --add channels conda-forge
conda config --set channel_priority strict

Once the conda-forge channel has been enabled, libpng can be installed with conda:

conda install libpng

or with mamba:

mamba install libpng

It is possible to list all of the versions of libpng available on your platform with conda:

conda search libpng --channel conda-forge

or with mamba:

mamba search libpng --channel conda-forge

Alternatively, mamba repoquery may provide more information:

# Search all versions available on your platform:
mamba repoquery search libpng --channel conda-forge

# List packages depending on `libpng`:
mamba repoquery whoneeds libpng --channel conda-forge

# List dependencies of `libpng`:
mamba repoquery depends libpng --channel conda-forge

About conda-forge

conda-forge is a community-led conda channel of installable packages. In order to provide high-quality builds, the process has been automated into the conda-forge GitHub organization. The conda-forge organization contains one repository for each of the installable packages. Such a repository is known as a feedstock.

A feedstock is made up of a conda recipe (the instructions on what and how to build the package) and the necessary configurations for automatic building using freely available continuous integration services. Thanks to the awesome service provided by Azure, GitHub, CircleCI, AppVeyor, Drone, and TravisCI it is possible to build and upload installable packages to the conda-forge anaconda.org channel for Linux, Windows and OSX respectively.

To manage the continuous integration and simplify feedstock maintenance conda-smithy has been developed. Using the conda-forge.yml within this repository, it is possible to re-render all of this feedstock's supporting files (e.g. the CI configuration files) with conda smithy rerender.

For more information please check the conda-forge documentation.

Terminology

feedstock - the conda recipe (raw material), supporting scripts and CI configuration.

conda-smithy - the tool which helps orchestrate the feedstock. Its primary use is in the construction of the CI .yml files and simplify the management of many feedstocks.

conda-forge - the place where the feedstock and smithy live and work to produce the finished article (built conda distributions)

Updating libpng-feedstock

If you would like to improve the libpng recipe or build a new package version, please fork this repository and submit a PR. Upon submission, your changes will be run on the appropriate platforms to give the reviewer an opportunity to confirm that the changes result in a successful build. Once merged, the recipe will be re-built and uploaded automatically to the conda-forge channel, whereupon the built conda packages will be available for everybody to install and use from the conda-forge channel. Note that all branches in the conda-forge/libpng-feedstock are immediately built and any created packages are uploaded, so PRs should be based on branches in forks and branches in the main repository should only be used to build distinct package versions.

In order to produce a uniquely identifiable distribution:

• If the version of a package is not being increased, please add or increase the build/number.
• If the version of a package is being increased, please remember to return the build/number back to 0.

Feedstock Maintainers

• @msarahan
• @ocefpaf
• @pkgw

libpng-feedstock's Issues

APNG support?

https://sourceforge.net/projects/libpng-apng/

See https://en.wikipedia.org/wiki/APNG#History

libpng cannot be installed without python (msvc)

Not sure that is going on, but if I try to create an env with just libpng (no python) the package refuses to install (see matplotlib/matplotlib#6460 (comment)):

conda create -n cf_png2 libpng=1.6.21 -c conda-forge

I did follow the same features logic as the other packages, but I am sure I made a mistake somewhere that I cannot see. @msarahan can you take a look to see if you can spot my error?

pkgconfig thinks that windows needs to link to -lm

Comment:

@conda-forge-admin please rerender

Invalid pkg-config files shipped on Windows

The Windows package includes a pkg-config file with the following contents:

Name: libpng
Description: Loads and saves PNG files
Version: 1.6.36
Requires: zlib
Libs: -L${libdir} -lpng16
Libs.private: -lz -lm
Cflags: -I${includedir}

When invoking pkg-config (e.g., from m2w64-pkg-config or m2-pkg-config and after poiting the %PKG_CONFIG_PATH% environment variable to the directories containing the libpng.pc and the (dependent) zlib.pc files), one gets

pkg-config --libs --msvc-syntax libpng
/libpath:C:/path/to/conda/env/Library/lib png16.lib z.lib

But the name of the lib file is actually libpng16.lib, not png16.lib, so the linker would fail.

Put it simply, -lpng16 should be replaced by -llibpng16 in the pkg-config file (looks like upstream is not intending this pkg-config file for Windows use anyways and it's only included per #23).

Libpng 1.6.17 in defaults is incompatible with 1.6.21 in conda-foge

This may not be an issue of this feedstock but I am reporting it here.
Till now all packages are pinned with version 1.6* of the libpng but sometimes conda decides to pull libpng-1.6.17-0 from defaults instead of libpng-1.6.21-1 from conda-forge. When that happens I face this error in this pull:

import bob.io.image

  File "/Users/travis/miniconda3/envs/_test/lib/python3.5/site-packages/bob/io/image/__init__.py", line 4, in <module>

    from . import _library

ImportError: dlopen(/Users/travis/miniconda3/envs/_test/lib/python3.5/site-packages/bob/io/image/_library.cpython-35m-darwin.so, 2): Library not loaded: @rpath/libpng16.16.dylib

  Referenced from: /Users/travis/miniconda3/envs/_test/lib/python3.5/site-packages/bob/io/image/_library.cpython-35m-darwin.so

  Reason: Incompatible library version: _library.cpython-35m-darwin.so requires version 38.0.0 or later, but libpng16.16.dylib provides version 34.0.0

The problem here is bob.io.image is built with libpng-1.6.21-1 but here libpng-1.6.17-0 is being pulled when it is used in bob.ip.optflow.liu.
How do you think we could prevent this? Should we pin libpng to 1.6.21*?

Update to 1.6.28 , 1.6.26 has a security bug.

details here: http://www.libpng.org/pub/png/libpng.html

I can take a try at updating.

Proposal: split the package into dev and binary

[This came out of the last conda-forge hangout + original proposal; this proposal is only for native packages, not python/... ones]

Problem

The problem is that packages end up being incompatible between versions ("SONAME change"). This is currently not the "real" problem with libpng (but with jpeg -> 8 vs 9). To guard against this (future potential) problem, the dependency to this package is pinned to libpng 1.6*, so that packages linking against this packages can't install a future libpng 1.7. The problem with that is that in some cases (aka the jpeg package) different packages in the archive (in this cases matplotlib in conda-forge and pyqt in defaults) depend on different versions of the library and can't therefore be installed together.

The solution is to make multiple versions of a package installable next to each other. This is possible because the actual binary library libpng16.{so|dll} has the version in the name and therefore two versions can be installed next to each other. Unfortunately, the current package also contains the header files (png.h and also the *lib files on windows) and these are unversioned. Therefore, to not overwrite files from another packages, the header files need to be separated from the binary file.

proposal

(roughly modeled after the way debian does it):

• add two new packages/feedstocks libpng16-dev and libpng16 which are named after the complete SONAME of the *.so/*.dll file in the package (name+version). The recipes are basically a copy of the current recipe with one packages deleting everything but the one binary *so/*dll file (libpng16) and the other deleting only the binary (libpng16-dev).
• libpng-dev needs to runtime depend on the same version as the libpng16 package to pull in the right so/dll at compile time -> at compile time the same file content as the current libpng package is present on the file system -> this needs coordinated uploads for libpng16 and libpng16-dev
• changing all dependencies to build-depend on libpng16-dev >=1.6.21 (the current minimum compatible version) and the runtime dependency to ``libpng16 >=1.6.21. This only needs greater than` dependencies as well behaving libraries should change the SONAME on incompatible ABI/API changes and so the package would need to depend on `libpng17{,-dev}`

The result of these is that the current libpng and libpng16 will be coinstallable but overwrite the actual binary lib (_so/_dll), but this can't be worked around without changing the SONAME/Filename on disk (not a good idea...) or having the packages conflict with each other (which conda currently can't do?!). The idea is to do the split and then do a rebuild of all the conda-forge packages to get the new version until no package in conda-forge depends on libpng anymore.

Bad things which can still happen:

• if all libpng dependent packages in conda-forge get rebuild and if libpng gets removed from conda-forge, then a package which gets installed from defaults alone will pull in libpng again but this package will overwrite the libpng16.so/dll file and so an incompatible version would be present. For that I would suggest that an empty libpng (with a specific higher version, which the libpng package in defaults would not reach) would be kept in the archive and libpng16 would depend on that version until defaults gets updated to this new split libpng package. On the other hand, this can lead to the situation that a package from the defaults channel would depend on libpng without a * pin or a less than restriction (haven't investigated how the default packages declare their dependency on libpng) and would end up without a libpng16.so/dll :-(
• potentially two different versions of the dev packages could be installed. Conda currently does not complain about overwriting files in a different package. Unfortunately, this would make linking against a *so/*dll nondeterministic as the last package installed would "win" the link. This needs conflicts in the libpng16-dev package (and stuff like virtual packages -> libpng16-dev would providelibpng-devand conflict withlibpng-dev-> only one package providinglibpng-dev` can be installed). But unless someone screws up a recipe and the CI services/conda-build install both versions I don't think it will matter.
• other problems?

"Future directions" :-)

• The same proposal should be used for jpeg and the other native packages. jpeg is actually easier because AFAIK only conda-forge has the incompatible jpeg9 version and defaults is on jpeg8 -> no compatibility is needed, we just need to remove the old conda-forge jpeg package
• if conda gets multiple binary packages per recipe, then libpng16-dev and libpng16 should be build from the same source and the version can be set in one recipe. Until then it needs coordinated uploads.
• if conda gets dynamic build time runtime dependency (= the actual dependencies of the runtime package are generated at build time from the actual versions of the "linked against" packages), then the build time dependency could be relaxed to libpng-dev/libpng16-dev (-> without a specific version; without the version in the name only if the API is kept and only the ABI is changed -> the recipe would be call "libpng" for all libpng versions) -> whatever version is present would end as the runtime version dependency and all is fine :-)
• Conflicts would make the "one package could overwrite the *so/*dll with an older version"-problem much easier: We could then declare a conflict in libpng16 against libpng and force that package out.
• if conda would error when a file from another package is overwritten would make the problem of libpng from defaults overwriting the so/dll from libpng16 from conda-forge at least detectable on install time and not on runtime.

libpng 1.6.40?

Comment:

Any ETA on when 1.6.40 will be uploaded?

Clean out `man` and other `share` files

There seems to be some man files getting bundled. As we don't supply man or any way to use these, they should be removed.

libpng breaks compatibility in mac each time with a patch version

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

use run_export for zlib

Comment:

@conda-forge-admin please rerender