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 < [email protected]> 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Andrew Bell [email protected]
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
