libjpeg is core dumping when doing a read header in ossim core engine.

[warmerdam]

> I am now down to one last issue with libjpeg and I can use all 
> of the osgeo4w depends successfully.  Looks like GDAL does the same 
> thing in libtiff and uses the cpl port for any IO performed on any input 
> jpeg.  The only difference I see in the jpeg-6b library I am compiling 
> and the one you are compiling is the jconfig.h.  When I built the 
> libjpeg library I just copied the jconfig.vc file to jconfig.h and then 
> built it.  In the one that is installed via the osgeo installer I see 
> something like this at the top and the contents are different and it 
> contains something like this at the top of the file:
> 
> jconfig.h. Generated automatically by configure.
> 
> Was wodnering if we could try the jconfig.h.vc to jconfig.h and see if 
> the direct IO use  will work.

[warmerdam]

I have discovered that I am using a slightly modified buildkit jpeg that does indeed seem to be using a jconfig.h from unix/configure rather than jconfig.h.vc. I'm not sure why.

However, I'm not clear on why this matters. It *seems* like applications would normally use jpeg_stdio_src() and jpeg_stdio_dest() functions to handle io and these are stdio based. I'm not sure how differences in jconfig.h will alter how these operate. If the issue is needing large file support, then it seems a custom src/dest handler would be required (as is provided by GDAL).

[gpotts]

A core dump occurs when using the read header from the jpeg library. I have compiled my own jpeg-6b source and the problem goes away. I have not done a detailed scan of the headers that came with osgeo4w install and the ones that I had in the jpeg-6b distribution but I did see a difference in the jconfig.h. I used the jconfig.h.vc and the one in osgeo4w seems to use something slightly different. I agree with Frank, not sure why this would have an affect and it might just be something else. This is the first difference I saw.

[warmerdam]

The problem was the ubiquitous "jpeg struct size" problem related to the type of boolean.

I have rebuilt and re-uploaded libjpeg and libjpeg-devel (and source) using the jconfig.vc for jconfig.h. I also had to rebuild and re-upload gdal with the new build.

After this change I can access jpeg files and jpeg-in-tiff files properly from GDAL so I think we are in good shape.

Garrett, could you update and confirm it fixes your problems as well? If so, then close this ticket.

[warmerdam]

We have come to the conclusion that Garrett is also running into a runtime issue because libjpeg is built with vc7.1 and ossim with vc8, but the normal way of opening a jpeg file involves passing in a FILE* which is runtime specific.

[jef]

Probably already fixed - feel free to reopen