[gdal-dev] Preventing symbol export in custom GDAL build

[Kai Pastor, DG0YT]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251210/e2b2f322/attachment.htm>