<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Date: Sun, 3 Dec 2006 20:52:44 -0800 (PST)<br>From: Curt Mills <<a href="mailto:archer@eskimo.com">
archer@eskimo.com</a>><br>Subject: [Gdal-dev] Any possibility of static compile?<br>To: <a href="mailto:gdal-dev@lists.maptools.org">gdal-dev@lists.maptools.org</a><br>Message-ID: <<a href="mailto:Pine.LNX.4.58.0612032041100.22180@wapiti.we7u.net">
Pine.LNX.4.58.0612032041100.22180@wapiti.we7u.net</a>><br>Content-Type: TEXT/PLAIN; charset=US-ASCII<br><br>I need to do a static compile of my app. I've been able to compile<br>Shapelib, proj, geotiff, and a few other libraries statically so
<br>far.</blockquote><div><br>If you use OGDI, it's a no-go for a completely static build. That library explicitly runs dlopen on itself.<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'd like to get GDAL compiled in, of which we use some of the OGR<br>functions, but I recall reading earlier about some problems with<br>static compiles of GDAL. Is there a way to get OGR or the full<br>GDAL/OGR library compiled statically these days?
</blockquote><div><br>I've been maintaining patches to do static builds of GDAL/OGR for the last three years. Only recently (3 months?) did we switch to the more common shared library builds.<br><br>Most of the problems came from the integration of various 3rdparty libraries into the static build of GDAL (Kakadu, libecw, etc.). Some of these relied on initialization routines being called from their shared library initializers. And there were a few other issues along the same line. Another large class of problems was the GDAL configure/make rules for integrating the 3rdparty libraries. These were the most problematic patches to maintain since the configure and makefiles are autogenerated and can change
<span style="text-decoration: underline;">significantly</span> between releases of GDAL. At one point I was maintaining apx 25 patches (not all for static builds). I just got tired of the maintenance and decided to change my installation of GDAL to be a shared library just to avoid the headaches. I'm down to 11 patches now for
1.3.2 builds. Fully half of those will go away with the next release since they've already been rolled into the source repository (gcc 4.1 fixes and the like). The rest are little ones for 3rdparty library integration.<br>
<br>If you compile in a large number of 3rdparty libraries, my personal experience tells me it's more work to maintain the static builds than it is to maintain the shared library in your distribution.<br><br></div></div><br>
-- <br>John Johnson <<a href="mailto:jdjohnso@google.com">jdjohnso@google.com</a>>