[Gdal-dev] Re: Any possibility of static compile?

[John Johnson]

>
> Date: Sun, 3 Dec 2006 20:52:44 -0800 (PST)
> From: Curt Mills <archer at eskimo.com>
> Subject: [Gdal-dev] Any possibility of static compile?
> To: gdal-dev at lists.maptools.org
> Message-ID: <Pine.LNX.4.58.0612032041100.22180 at wapiti.we7u.net>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> I need to do a static compile of my app.  I've been able to compile
> Shapelib, proj, geotiff, and a few other libraries statically so
> far.


If you use OGDI, it's a no-go for a completely static build. That library
explicitly runs dlopen on itself.


I'd like to get GDAL compiled in, of which we use some of the OGR
> functions, but I recall reading earlier about some problems with
> static compiles of GDAL.  Is there a way to get OGR or the full
> GDAL/OGR library compiled statically these days?


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.

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
significantly 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.

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.


-- 
John Johnson <jdjohnso at google.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20061204/1ca85496/attachment.html