[osgeo4w-dev] osgeo4w installer for windows

[Garrett Potts]

Hello Frank:

thank you for the  feedback.


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

Yes, I understand,  and I also understand why there is a mix.  For  
instance the ffmpeg group will never support Microsoft compilers and  
so must be a mingw build to use that video library on windows.  This  
could be true for other dependencies.

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

Hmm, will have to see the best option for this.  I have done the  
override in the Planet for in memory jpeg decoding and could be  
feasable to create a generalized IO override sort f like what you did  
in GDAL jpeg handler for you IO override.


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


There are probably several reasons but for me I hate always trying to  
find and keep at least source trees in synch on unix based machines  
and windows, ... etc.  Supplying source distribution will allow one to  
just copy the source from the osgeo4w installer and build it on  
another platform, assuming the full source tree is there and not just  
a windows specific tree.    The other option is to just mirror the tgz  
files that were used to build your osgeo4w installer.  My thing is not  
only do we have a way for Windows to install a dependency for you  
applications but also have a way to get to the source so we can keep  
the same dependency builds on other platforms.


Take care

Garrett