Bug#1132628: libminizip-dev: minizip.pc breaks builds with different include path
clone 1132628 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
reassign -1 src:assimp
reassign -2 src:collada-dom
reassign -3 src:deepin-log-viewer
reassign -4 src:ezquake
reassign -5 src:fceux
reassign -6 src:globalplatform
reassign -7 src:gwyddion
reassign -8 src:mupen64plus-core
reassgin -9 src:netradiant
reassign -10 src:widelands
reassign -11 src:wordgrinder
close 1132628
kthxbye
On Tue, Apr 14, 2026 at 12:46:13PM +0200, Santiago Vila wrote:
> Mark Brown wrote:
> > Note that this is an upstream change in minizip not a packaging one so I
> > suspect that this is something that your upstream might want to be aware
> > of and consider handling.
> If this is really the case please clone this bug to all the above
> packages and explain the maintainers that the packages have to adapt
> to this change.
Yes, this is as I said a deliberate upstream change. The .pc file has
been changed to not add a -I and require an explicit minizip/ prefix
when including the headers. See 7e6f0784cc0c3 ("Remedy conflict between
libzip and minizip zip.h.") in upstream git:
Remedy conflict between libzip and minizip zip.h.
minizip.pc.in would add @include@/minizip to the include path,
which would permit simply #include to use minizip. However
that conflicts with the zip.h from libzip that is put in the root
include directory. This now does not add /minizip to the include
path. Now when using pkg-config, #include must be
used, where #include would be used for libzip. This is an
incompatible change with the previous state. Users of minizip and
pkg-config will need to update their code. #include will
need to be updated to #include as well.
It's not the sort of thing I'd expect to see customised as part of
packaging.
signature.asc
Description: PGP signature
Bug#1132628: libminizip-dev: minizip.pc breaks builds with different include path
affects 1132628 src:assimp src:collada-dom src:deepin-log-viewer src:ezquake src:fceux src:globalplatform src:gwyddion src:mupen64plus-core src:netradiant src:widelands src:wordgrinder thanks Timo Röhling wrote: > This breaks codebases like Open3D, which tries to include . Indeed. I'm adding a few more packages. All the ones above contain this string in their build logs when they are built today: zip.h: No such file or directory Mark Brown wrote: > Note that this is an upstream change in minizip not a packaging one so I > suspect that this is something that your upstream might want to be aware > of and consider handling. If this is really the case please clone this bug to all the above packages and explain the maintainers that the packages have to adapt to this change. Thanks.
Bug#1132628: libminizip-dev: minizip.pc breaks builds with different include path
On Sat, Apr 04, 2026 at 08:35:30AM +0200, Timo Röhling wrote: > minizip installs its headers in "/usr/include/minizip" and, until > recently, also exported this path in its minizip.pc configuration. > I don't know if intentional or not, but minizip.pc only exports > "/usr/include" now (see diff at the end). This breaks codebases like > Open3D, which tries to include . > I would prefer for minizip to remain backwards-compatible and revert to > the previous behavior, hence this bug report. Note that this is an upstream change in minizip not a packaging one so I suspect that this is something that your upstream might want to be aware of and consider handling. signature.asc Description: PGP signature
Bug#1132628: libminizip-dev: minizip.pc breaks builds with different include path
Package: libminizip-dev
Version: 1:1.3.dfsg+really1.3.2-3
Severity: serious
Control: affects -1 src:open3d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
minizip installs its headers in "/usr/include/minizip" and, until
recently, also exported this path in its minizip.pc configuration.
I don't know if intentional or not, but minizip.pc only exports
"/usr/include" now (see diff at the end). This breaks codebases like
Open3D, which tries to include .
I would prefer for minizip to remain backwards-compatible and revert to
the previous behavior, hence this bug report.
Cheers
Timo
- --- minizip-forky/usr/lib/x86_64-linux-gnu/pkgconfig/minizip.pc 2026-02-16
15:40:58.0 +0100
+++ minizip-unstable/usr/lib/x86_64-linux-gnu/pkgconfig/minizip.pc
2026-04-01 23:50:49.0 +0200
@@ -1,12 +1,13 @@
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
- -includedir=${prefix}/include/minizip
+includedir=${prefix}/include
Name: minizip
Description: Minizip zip file manipulation library
Requires:
- -Version: 1.3.1
+Version: 1.3.2
+License: Zlib
Libs: -L${libdir} -lminizip
Libs.private: -lz
Cflags: -I${includedir}
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmnQsTEACgkQzIxr3RQD
9MoVJw/+MTi7isX2+DB3LrPcSyJmywvVQNg1fSJs3K2w29Zvxqlwcg1dAT5CYkVQ
RaB+HptoFlB3Ob8DviRAKd1ljlDj88jIWWdwPziNR0/567LzMeWWHPzzJlOue/Jc
/f1P2aLXL5WWHT9HfX3jqfGuMyNjyBMqX1nvpAo1dgqEsYX6Zr/RFztjudvDgd9x
vhtBAdTbNt4UD8T6hKKR5ig/YIKKTH9JzpT2ZjIDNUefktulF+uvbOr0UNo13raz
5ymAglwHJ42xKjAyfMKRW6irJAL9UFJl+uRpIho34ZSGSJaDFwip+WCJ+rZ7QrWf
wUs+xum2SQ8iTIMQ9DZQtxlJuPhvkTpz+zlIuBOv1aU9RnlDMZg38Nz9VEjnQ66Y
VFeVemitVducoubCQ/wsQdrnvuUpPPK2stfrwW7x/BRuZP7ZEkSt3zWRrG31h0Bn
8+X54C4tCaDWw2sStjo5bXR4WUIfua5CXBWmwTqZUJbghYln1a5fAeHdJIsnHxeM
nvt0frR2xf1OAndEGx+3/6dy5rd7aJHk3iAoGpueByBaedOLefKcPGUurjO4PkuJ
qKIgNtBbrL+rqBoLZtOquUKfHur/MotW9BPNnL1HK8IfrxjuvHyHQ/W01o3RWUCX
MxgzP+bvz1Lj3oljJG3yGqGpfdGNXQBUQli2vIvYEdSBh7gscqM=
=Wrlp
-END PGP SIGNATURE-
