<html><head><style type="text/css">.style1 {font-family: "Times New Roman";}</style></head><body><div dir="ltr"><div dir="ltr">All,<div><br></div><div><b>Current Problem:</b></div><div><br></div><div>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.<br><br>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.<br><br>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:<br><br>1. It requires maintaining patches for every conflicting library indefinitely, adding ongoing development overhead.<br>2. The solution is brittle; updates to any patched library may break the build.<br><br>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.</div><div><br></div><div><div><b>Why We Need a Custom GDAL Build:</b><br><br>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.<br><br>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.<br><br>To address this problem and meet our other requirements, we opted for custom GDAL builds.<br><br><b>Any help would be appreciated:</b><br><p>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.</p>
<p>Thank you for your time and assistance.</p></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">David Klaus<div>Carlson Software</div></div></div></div>
</div>
<br><br><p style="font-family: Verdana; font-size:10pt; color:#777777;"><b>Disclaimer</b></p><p style="font-family: Verdana; font-size:8pt; color:#777777;">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.</p></body></html>