<div dir="ltr">Just a note on static builds to follow-on to Even's comments:<div><br></div><div>I do static builds of gdal driven by bazel.   </div><div><br></div><div>This has pros and cons:</div><div><br></div><div>- Plugins are explicitly not allowed in the system I work in for security reasons (I also remove almost all networking) </div><div>- The resulting bins are big, but VMs are very focused, so typically there is only 1 or a couple binaries with GDAL linked in.</div><div>- No static libs are kept beyond build caching</div><div>- For python, everything is wrapped into one bin at build so there ends up only being one copy of gdal per binary</div><div>- The python libs never link in gdal lib(s) [I split port out as a separate lib target] - that's the job of the final link stage for the executable</div><div>- This makes for easier supply chain tracking</div><div>- This means that any changes require a complete rebuild of everything</div><div><br></div><div>In a normal linux environment, this doesn't make a lot of sense, but when deploying 1 program per vm to a cloud env, it works well (e.g. order millions of VMs)</div><div><br></div><div> It's something that I don't plan to bring to upstream GDAL, but I've shared the basics in the past.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 11, 2022 at 10:13 AM <<a href="mailto:dg0yt@darc.de">dg0yt@darc.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even,<br>
<br>
I understand the downsides and agree with everything you say.<br>
<br>
I work with the static builds because this is what is tested in vcpkg CI for macOS and Linux. For Windows, there are also dynamic builds in CI. Dynamic options for Linux and macOS exist but aren't tested, so I guess some of gdal's  dependencies won't build.<br>
Also, vcpkg doesn't aim to offer a binary "distribution" of tools for users but is focused on libraries for developers, built from source.<br>
<br>
Kai<br>
<br>
> Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> hat am 11.02.2022 13:15 geschrieben:<br>
> <br>
>  <br>
> Kai,<br>
> <br>
> there's a point I had in mind regarding your mention of static builds <br>
> but forgot to mention. I consider GDAL static builds as inferior in term <br>
> of capabilities compared to dynamic builds because:<br>
> <br>
> - they don't allow to have GDAL drivers built as plugins : due to the <br>
> design of GDAL drivers, plugins need to link against libgdal. You don't <br>
> want each plugin to have its copy of libgdal. At runtime I'm not sure <br>
> how that would behave regarding the multiple instances of the same GDAL <br>
> symbols.<br>
> <br>
> - and I don't believe you can build Python bindings against as static <br>
> libgdal because we have several Python modules (gdal, ogr, osr, <br>
> gdal_array) with each linking to libgdal. So if you ever managed to make <br>
> them build, at runtime you'd get again several copies of the GDAL symbols<br>
> <br>
> Without mentioning the size of the GDAL binaries with each of them <br>
> embedding libgdal.<br>
> <br>
> So even if I understand there are use cases for GDAL static builds <br>
> (thanks for all the work you do on that side with your pull requests !), <br>
> having them as the default in a distribution seems problematic to me.<br>
> <br>
> Even<br>
> <br>
> Le 25/01/2022 à 08:23, Kai Pastor, DG0YT a écrit :<br>
> > I made an initial attempt on gdal with cmake for vcpkg: <br>
> > <a href="https://github.com/microsoft/vcpkg/pull/22392" rel="noreferrer" target="_blank">https://github.com/microsoft/vcpkg/pull/22392</a><br>
> ><br>
> > Now vcpkg's default is static linkage on Linux and macOS. AFAICT <br>
> > static linkage is not covered very well. Fixing this needs a lot of <br>
> > work either on the find modules, or on getting dependencies to provide <br>
> > exported config. In some cases (e.g. GEOS), config files already <br>
> > exist, but they are neither used nor a drop-in replacement (target <br>
> > names differ).<br>
> ><br>
> > On the export side, all custom find modules must be made available to <br>
> > the exported configuration if not burning the depended-on libraries <br>
> > into the exported cmake config. Generating a complete gdal.pc needs <br>
> > work, too. CMake doesn't provide any help ATM. (But note <br>
> > <a href="https://gitlab.kitware.com/cmake/cmake/-/issues/22621" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/cmake/-/issues/22621</a>.)<br>
> ><br>
> > This is not meant as an argument against shortening the release <br>
> > schedule for cmake. I just want to underline that the CMake build <br>
> > system will continue to need significant changes, including <br>
> > user-facing changes.<br>
> ><br>
> > Kai Pastor<br>
> ><br>
> > _______________________________________________<br>
> > gdal-dev mailing list<br>
> > <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
> > <a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
> <br>
> -- <br>
> <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
> My software is free, but my time generally not.<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>