One of our build variants is a fully-static (or as-static-as-possible) done on CentOS 7 for old-Linux compatibility.
In reverse-dependency order we have static builds of SQLite 3450100 Expat 2.5.0 KML 1.2.0 HDF5 1.12.1 NetCDF 4.8.1 TIFF 4.5.1 Proj 9.3.0 GeoTIFF 1.7.1 LittleCMS 2.15 WebP 1.3.2 Zstd 1.4.8 OpenJPEG 2.5.0 GDAL 3.7.3 We use GEOS as well, but directly, not linked into GDAL. We do our own builds of TIFF and GeoTIFF since they are also dependencies of other libs we use (e.g. pdal for LIDAR import) and the rest are to activate desirable GDAL drivers. LittleCMS, WebP, Zstd, and OpenJPEG were added recently in order to activate the GDAL JPEG2000 driver (for Sentinel2 satellite raster data) and it took some time to get all the options right so the static stack would work. I can provide the build options we use for the static, if that would be helpful. I never got the GDAL tools compiling as full-static, but that's not important for us, as we don't bundle those with our product. Our development systems are Ubuntu with more conventional dynamic builds. We still have one VERY strange issue whereby FlatGeoBuf export fails in a very consistent and reproducible form down in the flatbuffer code, but only in the static build, and only in the full system. I have written a simple test harness that links the very same static libgdal and does a simple GDAL startup and FGB export of a single feature and that works fine. It's some kind of data/stack corruption when it first tries to write to the flatbuffer on the first feature, which results in a pointer member of the buffer class becoming 0x100000000000 (always) instead of null, and then it stops on an assert. There is also one private function in the vector_downward class which the debugger won't even step into in that build. I can even put printfs in that function and they don't come out. I've tried it on CentOS and on Ubuntu, with GCC and Clang, and it's always the same. Everything else in GDAL works just fine (we have LOTS of import/export unit tests). This makes zero sense as all the FGB code is internal to GDAL and compiled together. I've been poking at it for over a week and it's doing my head in. Not meaning to derail this thread, but just wondering if anyone else had encountered any strange run-time behavior with static builds. On Mon, Feb 12, 2024 at 4:02 AM Michael Otto via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hello, > > I have been trying for some time to compile GDAL and the GDAL apps as a > static library / executable programs. > > The goal is to cast GDAL and all its dependencies (PROJ / GEOS / all > dependencies to system libraries / ...) into a static library and to create > the GDAL apps as static executable programs. > There should be no dynamic dependencies. > > Unfortunately, I have not had any success so far. The library is created > statically but the apps are not yet. > Does anyone have experience with this topic or possibly a procedure that > leads to success? > > Best regards. > Michael Otto > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
