[osgeo4w-dev] osgeo4w installer for windows

[Frank Warmerdam]

Garrett Potts wrote:
> Hello All:
> 
> Been doing some testing of the binary installer of the osgeo4w package.  
> I have ran into a couple of roadblocks.  I am using a VisualStudio 2005 
> and I think the binary package is compiled to a 2003 version.  The one 
> issue that I have ran into is still the libjpeg core dumping when I use 
> it in my software environment.  Not sure if this is the case but seems 
> that some of the libjpeg internals is not hidden with respect to file IO 
> and I think the difference in the c runtime libraries might be causing 
> some problems. 

Garrett,

A light goes off!

Are you using jpeg_stdio_dest() and/or jpeg_stdio_src()?  If so, then it
is important that libjpeg be using the same C runtime as the caller.

Generally speaking OSGeo4W includes a mix of DLLs built with different
compiler versions (VC7.1, VC8, MingW).  This works as long as certain
practices are avoided.  One of the things that must be avoided is
assuming that different DLLs/EXEs share the same heap, and the other
is assuming that FILE *'s are compatible across DLL/EXE boundaries.

My suggestion is that you actually duplicate the code in jdatasrc.c
and jdatadst giving the functions a different name, and use that
implementation in your own code for jpeg file io.  This will ensure that
no matter how (within reason) the jpeg dll is built, it will still be
compatible with the OSSIM choice of runtime.

The alternative (which I'm not keen on) would be for you to embed a static
copy of the jpeg library in the OSSIM dll instead of using the OSGeo4W
version.  But, I would claim, insulating yourself from the runtime
used by the jpeg dll will pay dividends in the long term.

> I don't have any issues with libtiff.  The API part I am 
> using is hidden behind the TIFF Pointer  and I have not ran into any IO 
> core dumps.  

This is because normal use of libtiff lets libtiff do the file opening,
so there is no FILE * compatability issue across DLLs.  And libtiff's
use of libjpeg goes through a custom file io layer (since the jpeg
is really in the tiff file).

 > Given that we might need to have source distribution added
> to the download for all source code being compiled in the osgeo4w 
> installer. 

I'm not sure I understand why you think this.  I do like to prepare
source distributions for OSGeo4W when it is convenient, if only to
document how a particular package was built in case the packager
gets hit by a bus or loses track of their build directory.  But I'm
not sure why it is particularly important to do so.

I'd add that source distributions vary in their approach and completeness.
For instance, for GDAL I just include files changes from the standard
distribution, plus osgeo4w packaging scripts in the source distribution.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org