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

[David Klaus]

Andrew,

Thank you for that. Let me research that option a little bit,

On Wed, Dec 10, 2025 at 11:09 AM Andrew Bell <andrew.bell.ia at gmail.com>
wrote:

> 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
>> <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>>
>
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
>


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