Thank-you Greg, this is exactly my earlier comment directly on the
associated ticket this morning, but you explain it much better:
https://github.com/OSGeo/gdal/issues/5587
It has caused so much grief downstream (zlib inside GDAL), that I
believe it is time to remove it.
-jeff
On 2022-04-07 10:08 a.m., Greg Troxel wrote:
Even Rouault <even.roua...@spatialys.com> writes:
Most GDAL binary distributions don't use that internal copy but the
external zlib library provided by the operating system / distribution
channel.
I realize you are accomodating people who can somehow get and build gdal
sources but can't first install zlib, but from the packaging viewpoint
having included copies is a bad thing. Yes, it shouldn't get used, but
if a dependency isn't declared it would be hidden or not provided and
then be used anyway.
I therefore think it would be good to consider removing the vendored
copies, or at least requiring explicit config to turn them on. (I just
looked in the sources for how to build and didn't find it in README. I
know I have figured out how to build and this isn't a request for help,
but in terms of the cmake migration the instructions are missing.) It
looks like internal will just be used if zlib is not found.
I wonder if it's still really necessary/helpful to have included libs
like zlib.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
