[gdal-dev] Improving GDAL production in our release

[Kai Pastor, DG0YT]

> 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.

Isn't it enough to take a static build of PROJ and let GDAL find the 
exorted CMake config?

FTR in vcpkg, it is possible to override the desired library linkage for 
individual packages (with triplet customization). Basically it should be 
fairly easy to test the desired combination.
(Difficulties would start with (proprietary) formats which are not 
handled in the recipes.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250107/8244b58e/attachment.htm>