Opened 2 months ago
Closed 2 months ago
#854 closed defect (wontfix)
Loading gdal307.dll fails, some dependencies missing/renamed
Reported by: | rkolka | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | Package |
Version: | Keywords: | ||
Cc: |
Description
I have installed the latest OSGeo4W/QGIS, in particular gdal verision 3.9.2-1.
The installation also includes gdal307-runtime (3.7.3-1).
But to me it seems gdal307.dll cannot be loaded at all, because it needs
libcrypto-1_1-x64.dll
, libssl-1_1-x64.dll
, and webp.dll
.
This is according to Dependency Walker and also a third party software that tries to load gdal307.dll and fails. From Process Monitor I can see the third party process finding gdal307.dll, looking for all the deps and failing on libcrypto-1_1-x64.dll
and libssl-1_1-x64.dll
. I see that gdal309.dll links to newer and renamed libcrypto-3-x64.dll
, libssl-3-x64.dll
and libwebp.dll
.
I do have older package, that I can successfully use (gdal 3.7.3, when gdal307 was *the* main runtime).
My question: Is this intended? Can it be changed? Can a third party app continue using the gdal307-runtime that comes with newer main runtime?
Attachments (1)
Change History (4)
by , 2 months ago
Attachment: | gdal307_missing_deps.png added |
---|
comment:2 by , 2 months ago
Oh, thanks. I see now! Older runtime are not automatically added anymore while doing a fresh OSGeo4W install. That makes things clearer. No pollution in the PATH for example.
comment:3 by , 2 months ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Third party apps are not considered. There shouldn't be any packages in OSGeo4W anymore that depend on gdal307-runtime, so gdal307-runtime should be unused as far as packages are concerned an can therefore be safely removed.
Dependencies in OSGeo4W are generally unversioned, so doing partial updates has the potential risk of producing broken installations. Updating everything should always be safe. Downgrading part might work, but might also break.
As a starting point to cure this, GDAL and PROJ deviate from that rule and have the (abi) version name in the name of the runtime package. So packages built against GDAL and PROJ should depend on the actual package version. But that was never extended to all packages. So currently having versions for GDAL and PROJ eases some transitions, but doesn't help if their dependencies change (like openssl and webp in this case).
Installing older versions should still succeed when you go back completely using snapshots.