[gdal-dev] Build static GDAL-Lib and static GDAL-Apps

[Simon Eves]

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 at 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 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/20240220/99066b2e/attachment.htm>