On 2022-04-07 11:07 a.m., Andrew C Aitchison wrote:
On Thu, 7 Apr 2022, 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.
I wondered whether it made a difference to driver plugins and "DLL hell"
- the PNG driver uses zlib/libz and libpng -
but it seems that we outlaw building gdriver plugins and internal
libraries, so that would not be a reason to keep the internal libraries.
I can confirm the 'DLL hell' on Windows builds, with GDAL's internal
zlib clashing (even with trying to disable all references to the
internal code).
-jeff
--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
