Closed jorisvandenbossche closed 9 months ago
Reproducing the linux build failure locally, this is the logs vcpkg produces to open an issue about it:
Package: gdal[core,curl,expat,geos,jpeg,lerc,png,qhull,recommended-features,sqlite3]:x64-linux-dynamic -> 3.7.2
Host Environment
To Reproduce
vcpkg install
Failure logs
-- Downloading https://github.com/OSGeo/gdal/archive/v3.7.2.tar.gz -> OSGeo-gdal-v3.7.2.tar.gz...
-- Extracting source /opt/vcpkg/downloads/OSGeo-gdal-v3.7.2.tar.gz
-- Applying patch find-link-libraries.patch
-- Applying patch fix-gdal-target-interfaces.patch
-- Applying patch libkml.patch
-- Applying patch fix-jpeg.patch
-- Using source at /opt/vcpkg/buildtrees/gdal/src/v3.7.2-79e9b709aa.clean
-- Configuring x64-linux-dynamic
-- Building x64-linux-dynamic-rel
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
Command failed: /opt/_internal/pipx/venvs/cmake/lib/python3.10/site-packages/cmake/data/bin/cmake --build . --config Release --target install -- -v -j9
Working Directory: /opt/vcpkg/buildtrees/gdal/x64-linux-dynamic-rel
See logs for more information:
/opt/vcpkg/buildtrees/gdal/install-x64-linux-dynamic-rel-out.log
Call Stack (most recent call first):
installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
buildtrees/versioning_/versions/gdal/d01864aaa21a85e1e8f7bb6748d607e953c52e77/portfile.cmake:104 (vcpkg_cmake_install)
scripts/ports.cmake:147 (include)
Additional context
The build error happens in frmts/zlib/contrib/infback9/minified_zutil.c:8
, which was added to GDAL in 3.7 to support deflate64 zip files (https://github.com/OSGeo/gdal/pull/7014).
My current understanding of the problem: this vendored code assumes a more recent zlib version than what we are using here to build with (it uses z_const
, which was added in https://github.com/madler/zlib/commit/5ab9f47745fe9353291b217f705086b6070575d5, which maps to zlib 1.2.5.2).
The custom port for zlib we use (https://github.com/geopandas/pyogrio/pull/57) is set to 1.2.5, but we can maybe try to "just" update that to 1.2.5.2 (that should be fine for manylinux, as that's the max version for manylinux2014 policy: https://github.com/pypa/auditwheel/blob/3636dad88d6168aa745684db9ea6a7c6df4d4484/src/auditwheel/policy/manylinux-policy.json#L83)
(another option would be to let GDAL use its internal zlib copy, but that is not enabled in vcpkg, so that would require finding a way to override that, and not sure if that's possible without a custom port of gdal where we just override that one option)
That seems to have worked! The only failures are two windows wheel test builds that regularly fail (segfault at cleanup, https://github.com/geopandas/pyogrio/issues/213)
Thanks @jorisvandenbossche ! 💯
Closes #295
Like https://github.com/geopandas/pyogrio/pull/248, now updating to GDAL 3.7.2 (https://github.com/microsoft/vcpkg/commit/62988594de235334bc83609a060773eb2c8a8478)