<div dir="ltr">One of our build variants is a fully-static (or as-static-as-possible) done on CentOS 7 for old-Linux compatibility.<div><br></div><div>In reverse-dependency order we have static builds of</div><div><br></div><div>SQLite 3450100</div><div>Expat 2.5.0</div><div>KML 1.2.0</div><div>HDF5 1.12.1</div><div>NetCDF 4.8.1</div><div>TIFF 4.5.1</div><div>Proj 9.3.0</div><div>GeoTIFF 1.7.1</div><div>LittleCMS 2.15</div><div>WebP 1.3.2</div><div>Zstd 1.4.8</div><div>OpenJPEG 2.5.0</div><div>GDAL 3.7.3</div><div><br></div><div>We use GEOS as well, but directly, not linked into GDAL.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I can provide the build options we use for the static, if that would be helpful.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Not meaning to derail this thread, but just wondering if anyone else had encountered any strange run-time behavior with static builds.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 12, 2024 at 4:02 AM Michael Otto via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</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"><span style="font-size:10pt;font-family:sans-serif">Hello,</span><br><br><span style="font-size:10pt;font-family:sans-serif">I have been trying
for some time to compile GDAL and the GDAL apps as a static library / executable
programs.</span><br><br><span style="font-size:10pt;font-family:sans-serif">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. </span><br><span style="font-size:10pt;font-family:sans-serif">There should be
no dynamic dependencies.</span><br><br><span style="font-size:10pt;font-family:sans-serif">Unfortunately,
I have not had any success so far. The library is created statically but
the apps are not yet.</span><br><span style="font-size:10pt;font-family:sans-serif">Does anyone have
experience with this topic or possibly a procedure that leads to success?</span><br><br><span style="font-size:10pt;font-family:sans-serif">Best regards.</span><br><span style="font-size:10pt;font-family:sans-serif">Michael Otto<br></span><font face="sans-serif"></font>
_______________________________________________<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>