[wenzeslaus]

The CI OSGeo4W job fails loading GDAL and GRASS libraries. My search did not find discussion in our repo, and the fix is ultimately an update in the OSGeo4W packaging, but anyway, as as a workaround, I think we can use this as a workaround to get the CI green. OpenSSL coming from cURL is forced into the Python install by copying the file.

Details and AI use (mostly AI generated)

The investigation (log and package diffing, DLL import and export analysis) and the workflow change were done with AI assistance (Claude Code); the result was verified by a CI run on the [fork repo](https://github.com/wenzeslaus/pull/50).

Since 2026-09-25 (curl 8.22 update) the OSGeo4W "windows-2022 build and tests" job fails in
"Run pytest with multiple workers in parallel" with collection errors
ImportError: Could not load grass_gis.8.6. and ImportError: DLL load failed while importing _gdal: The specified procedure could not be found.,
accompanied by Windows fatal exception: code 0xc0000139. Last green run:
36112398152; first failures: 36126600837, 36134900476.

Between those runs OSGeo4W updated curl 8.21.0-1 -> 8.22.0-1 and gdal
3.13.3-1 -> 3.13.3-2. The new libcurl.dll imports SSL_get0_group_name
(OpenSSL >= 3.2). OSGeo4W python3-core 3.12.14-2 bundles OpenSSL 3.0.21 as
apps\Python312\DLLs\libssl-3-x64.dll, the same file name as the OSGeo4W
openssl 3.5.8 DLL in bin. Once Python has loaded its own libssl, libcurl
(pulled in by GDAL, and by PROJ for libgrass_gis) binds to it and fails with
STATUS_ENTRYPOINT_NOT_FOUND. GRASS tools run as separate processes and are
not affected.

Proposed CI workaround: after installing OSGeo4W, copy bin\libssl-3-x64.dll
and bin\libcrypto-3-x64.dll over the copies in apps\Python312\DLLs
(OpenSSL 3 is ABI compatible across minor versions). This passed on a fork:
wenzeslaus#50. The underlying packaging
problem should also be reported to OSGeo4W, since any OSGeo4W Python that
imports ssl before osgeo.gdal is likely affected.

Commit message for auto-merge:

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).

[echoix]

Thanks for the hack! I don’t know if you arrived to the same conclusions that I did or you had to redo the investigation, but it makes sense now knowing the cause

[echoix]

I saw in my emails that my OSGeo4W trac ticket got closed I’m retrying in a not-updated PR, then I’ll revert this one