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