Am 10.12.25 um 16:36 schrieb David Klaus via gdal-dev:
My company produces a custom GDAL build using vcpkg. GDAL itself is
built as a DLL, while all of its dependencies are built as static
libraries and linked into GDAL. To support this, I created a custom
triplet -- x64-windows-mixed-carlson-gdal.cmake -- included in the
attached custom-triplets folder.
The resulting GDAL DLL works, but it exposes an unintended side
effect: symbols from some static dependencies—for example,
libspatialite and libcurl—are being exported from the GDAL DLL. This
becomes a problem because the environment where our GDAL build runs
also loads its own custom builds of these libraries, and the exported
symbols conflict with those versions.
I have this seen this in vpckg for other libraries, and it can be fixed.
However, I would be surprised if it really occurs for libcurl.
So far, I have mitigated this for libspatialite by adding a patch --
cs_ensure_no_dll_export.patch -- in its portfile to disable symbol
export by overriding defines in various libspatialite headers.
However, this approach is not ideal because:
1. It requires maintaining patches for every conflicting library
indefinitely, adding ongoing development overhead.
2. The solution is brittle; updates to any patched library may break
the build.
To me this seems like a fairly common use case, but our environment is
unique. So, perhaps others don't need a build of GDAL that links it's
dependencies statically. In any case, I would appreciate any guidance
on how to prevent symbol exports from GDAL’s statically linked
dependencies in a more robust, maintainable way.
You get a robust solution by upstreaming. At least to vcpkg, better to
each actual source (libspatialite etc.). GDAL can't fix anything about
careless dllexport in its dependencies.
Kai
vcpkg contributor
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
