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

[Andrew Bell]

Hi,

All symbols that aren't specifically exported should be hidden if when you
build the flag "-fvisibility=hidden" is set. See
cmake/helpers/configure.cmake.

On Wed, Dec 10, 2025 at 10:43 AM David Klaus via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> All,
>
> *Current Problem:*
>
> 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.
>
> 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.
>
> *Why We Need a Custom GDAL Build:*
>
> Our program has a number of unique requirements which we haven't been able
> to satisfy through any means besides a custom build. A key example of this
> is our use of the Proj library.
>
> In our builds, we statically link the Proj library into GDAL. This
> approach is necessary because our product integrates with other
> environments that often include their own GDAL builds. In the past,
> dynamically linking the Proj library caused significant issues: these other
> environments would sometimes load their Proj dll in such a way that our
> GDAL would mistake their Proj dll for ours and attempt to use it. This
> mismatch resulted in crashes for our users.
>
> To address this problem and meet our other requirements, we opted for
> custom GDAL builds.
>
> *Any help would be appreciated:*
>
> I plan to continue patching libraries to suppress symbol export as needed,
> but I would greatly appreciate any recommendations, best practices, or
> alternative approaches that might simplify this process or eliminate the
> need for per-library patches.
>
> Thank you for your time and assistance.
> --
> David Klaus
> Carlson Software
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251210/ae69d7ac/attachment.htm>