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

[David Klaus]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251210/a9ba8f94/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom-ports.zip
Type: application/x-zip-compressed
Size: 40138 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251210/a9ba8f94/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: custom-triplets.zip
Type: application/x-zip-compressed
Size: 1019 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251210/a9ba8f94/attachment-0003.bin>