[GRASS-git] [OSGeo/grass] d6d2eb: CI: Workaround OSGeo4W OpenSSL DLL conflict by for...

[Vaclav Petras]

  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: d6d2eb2845444abbabc309f543fc534ff2dc4fd8
      https://github.com/OSGeo/grass/commit/d6d2eb2845444abbabc309f543fc534ff2dc4fd8
  Author: Vaclav Petras <wenzeslaus at gmail.com>
  Date:   2026-09-27 (Sun, 27 Sep 2026)

  Changed paths:
    M .github/workflows/osgeo4w.yml

  Log Message:
  -----------
  CI: Workaround OSGeo4W OpenSSL DLL conflict by forcing one (#7959)

Copy the OSGeo4W OpenSSL DLLs over the Python copies so that there is
only one OpenSSL version in the process. OpenSSL 3 keeps ABI
compatibility across minor versions, so the Python ssl module works
with the newer DLLs. This is only a workaround.

The OSGeo4W python3-core package ships its own libssl-3-x64.dll and
libcrypto-3-x64.dll (OpenSSL 3.0.21) in apps/Python312/DLLs, with the
same names as the OSGeo4W openssl package DLLs (OpenSSL 3.5.8) in bin.
The curl 8.22.0-1 package, which arrived in OSGeo4W on 2026-09-25
together with a gdal 3.13.3-2 rebuild, has a libcurl.dll which imports
SSL_get0_group_name, available only since OpenSSL 3.2. In a Python
process which already loaded the Python copy of libssl, loading the GDAL
bindings or GRASS libraries (which pull in libcurl through GDAL or PROJ)
fails with STATUS_ENTRYPOINT_NOT_FOUND (0xc0000139), so pytest reports
collection errors.

The investigation and the change were done with AI assistance (Claude
Code).



To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications