Is your feature request related to a problem? Please describe.
I installed libpng-apng and then went to install freetype, but it requires libpng.
The current way it works is libpng-apng is a patch that does not have a dependency to libpng, so I "don't have" libpng installed. Therefore, both libs/dlls are the same and vcpkg identified that the files already existed and aborted install.
The following packages will be built and installed:
freetype[core]:x64-windows
* libpng[core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/2: libpng:x64-windows
Building package libpng[core]:x64-windows...
-- Using cached C:/GitHub/vcpkg/downloads/glennrp-libpng-v1.6.37.tar.gz
-- Using source at C:/GitHub/vcpkg/buildtrees/libpng/src/v1.6.37-6445e5863e
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Performing post-build validation
-- Performing post-build validation done
Building package libpng[core]:x64-windows... done
Installing package libpng[core]:x64-windows...
The following files are already installed in C:/github/vcpkg/installed/x64-windows and are in conflict with libpng:x64-windows
Installed by libpng-apng:x64-windows
bin/libpng16.dll
bin/libpng16.pdb
debug/bin/libpng16d.dll
debug/bin/libpng16d.pdb
debug/lib/libpng16d.lib
include/libpng16/png.h
include/libpng16/pngconf.h
include/libpng16/pnglibconf.h
include/png.h
include/pngconf.h
include/pnglibconf.h
lib/libpng16.lib
Proposed solution
I have two proposed solutions:
The problem I see for the first one would be version inconsistency, such as libpng releases a new version but libpng-apng doesn't, so it's not possible to update one without the other.
Meanwhile, the second solution isn't exactly accurate, because having libpng-apng installed should count as having libpng installed. In my case, I solved it by changing the CONTROL file from freetype so it would require libpng-apng instead of libpng, but it should not be the ideal solution.
hmm so we need a png metapacket which the other ports depend on using features in the metaport to differentiate between the png libraries.
Hi @leleco95 thanks for posting this issue. This is a known vcpkg problem. Port libpng-apng and libpng have the same home page, when one of them is installed, delete the other.
Hey @AlvinZhangH, thanks for your attention.
In my project, I need freetype and libpng-apng installed, but freetype makes me install libpng because it is a dependency and, if I try to uninstall libpng after that (so I can install libpng-apng), it tells me freetype must be uninstalled also, so with the current setup I'd be stuck in a loop of:
As I mentioned earlier, I solved my case by modifying freetype's CONTROL file so it would take libpng-apng as a dependency instead of libpng, but it's not a solution that should be implemented, since someone else could simply want freetype and libpng.
Since you said this is a known problem, is it in the sense that I should stick to my workaround or that it might be solved some time in the future?
Thanks in advance.
@leleco95 I think the port libpng-apng just adds the feature apng to the port libpng, which conflicts with the port libpng. So I think we need to merge the two ports and fix the dependencies.
Since you said this is a known problem, is it in the sense that I should stick to my workaround or that it might be solved some time in the future?
This is the an issue we have faced with other libraries that are mutually exclusive, e.g.: openssl vs libressl.
Our current strategy has been to have one of them become the "blessed" package and have all other libraries that need an implementation depend on the "blessed" library. This also helps prevent file conflict errors during CI (where we build every package at the same time, and if we try to build conflicting packages the build will fail every time).
We decide if a meta-package is worth to implement on a case-by-case basis, such as the opencv meta-package.
Hi @leleco95, I create a PR #8622 to fix this issue, can you modify the freetype dependency from libpng to libpng[apng] and rebuild freetype?
Thanks.
@JackBoosY I removed libpng-apng and freetype, then tried to install it like this (having changed to libpng[apng] dependency on freetype):
> vcpkg install freetype:x64-windows
The following packages will be built and installed:
freetype[core]:x64-windows
* libpng[apng,core]:x64-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/2: libpng:x64-windows
Building package libpng[apng,core]:x64-windows...
Warning: abi keys are missing values:
zlib
-- Downloading https://downloads.sourceforge.net/project/libpng-apng/libpng16/1.6.37/libpng-1.6.37-apng.patch.gz...
-- Downloading https://github.com/glennrp/libpng/archive/v1.6.37.tar.gz...
CMake Error at scripts/cmake/vcpkg_extract_source_archive_ex.cmake:97 (file):
file SHA512 failed to read file "/libpng-1.6.37-apng.patch": No such file
or directory
Call Stack (most recent call first):
scripts/cmake/vcpkg_from_github.cmake:114 (vcpkg_extract_source_archive_ex)
ports/libpng/portfile.cmake:28 (vcpkg_from_github)
scripts/ports.cmake:94 (include)
Error: Building package libpng:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: libpng:x64-windows
Vcpkg version: 2019.09.12-nohash
Additionally, attach any relevant sections from the log files above.
It successfully downloaded both files and extracted the patch file to /buildtrees/libpng/src/ but failed to read it, which lead me to the conclusion that the path set for the patch could be wrong.
With my limited knowledge, I changed both ${SOURCE_PATH}/../libpng-${LIBPNG_VER}-apng.patch (lines 8 and 24) to ${CURRENT_BUILDTREES_DIR}/src/libpng-${LIBPNG_VER}-apng.patch and it worked.
On top of that, I don't think changing freetype's dependency is necessary because it doesn't seem to depend on [apng] itself, this seems to be specific to my project.
@leleco95 So, I think PR #8622 fixed this issue, I will close this issue after #8622 merge.
Yes and it will also fix #8598. Thank you very much for your help.
Close this issue via #8622 merged.