[gdal-dev] cmake status update - 99% good news!

[Kurt Schwehr]

Just a note on static builds to follow-on to Even's comments:

I do static builds of gdal driven by bazel.

This has pros and cons:

- Plugins are explicitly not allowed in the system I work in for security
reasons (I also remove almost all networking)
- The resulting bins are big, but VMs are very focused, so typically there
is only 1 or a couple binaries with GDAL linked in.
- No static libs are kept beyond build caching
- For python, everything is wrapped into one bin at build so there ends up
only being one copy of gdal per binary
- 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
- This makes for easier supply chain tracking
- This means that any changes require a complete rebuild of everything

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)

 It's something that I don't plan to bring to upstream GDAL, but I've
shared the basics in the past.

On Fri, Feb 11, 2022 at 10:13 AM <dg0yt at darc.de> wrote:

> Even,
>
> I understand the downsides and agree with everything you say.
>
> 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.
> Also, vcpkg doesn't aim to offer a binary "distribution" of tools for
> users but is focused on libraries for developers, built from source.
>
> Kai
>
> > Even Rouault <even.rouault at spatialys.com> hat am 11.02.2022 13:15
> geschrieben:
> >
> >
> > Kai,
> >
> > there's a point I had in mind regarding your mention of static builds
> > but forgot to mention. I consider GDAL static builds as inferior in term
> > of capabilities compared to dynamic builds because:
> >
> > - they don't allow to have GDAL drivers built as plugins : due to the
> > design of GDAL drivers, plugins need to link against libgdal. You don't
> > want each plugin to have its copy of libgdal. At runtime I'm not sure
> > how that would behave regarding the multiple instances of the same GDAL
> > symbols.
> >
> > - and I don't believe you can build Python bindings against as static
> > libgdal because we have several Python modules (gdal, ogr, osr,
> > gdal_array) with each linking to libgdal. So if you ever managed to make
> > them build, at runtime you'd get again several copies of the GDAL symbols
> >
> > Without mentioning the size of the GDAL binaries with each of them
> > embedding libgdal.
> >
> > So even if I understand there are use cases for GDAL static builds
> > (thanks for all the work you do on that side with your pull requests !),
> > having them as the default in a distribution seems problematic to me.
> >
> > Even
> >
> > Le 25/01/2022 à 08:23, Kai Pastor, DG0YT a écrit :
> > > I made an initial attempt on gdal with cmake for vcpkg:
> > > https://github.com/microsoft/vcpkg/pull/22392
> > >
> > > Now vcpkg's default is static linkage on Linux and macOS. AFAICT
> > > static linkage is not covered very well. Fixing this needs a lot of
> > > work either on the find modules, or on getting dependencies to provide
> > > exported config. In some cases (e.g. GEOS), config files already
> > > exist, but they are neither used nor a drop-in replacement (target
> > > names differ).
> > >
> > > On the export side, all custom find modules must be made available to
> > > the exported configuration if not burning the depended-on libraries
> > > into the exported cmake config. Generating a complete gdal.pc needs
> > > work, too. CMake doesn't provide any help ATM. (But note
> > > https://gitlab.kitware.com/cmake/cmake/-/issues/22621.)
> > >
> > > This is not meant as an argument against shortening the release
> > > schedule for cmake. I just want to underline that the CMake build
> > > system will continue to need significant changes, including
> > > user-facing changes.
> > >
> > > Kai Pastor
> > >
> > > _______________________________________________
> > > gdal-dev mailing list
> > > gdal-dev at lists.osgeo.org
> > > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > --
> > http://www.spatialys.com
> > My software is free, but my time generally not.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220211/a4de8e16/attachment-0001.html>