[gdal-dev] Error compiling trunk (nitf)

[Even Rouault]

Le jeudi 14 janvier 2016 20:14:01, Even Rouault a écrit :
> Le jeudi 14 janvier 2016 20:04:02, Jeff McKenna a écrit :
> > On 2016-01-14 3:05 PM, Even Rouault wrote:
> > > Le jeudi 14 janvier 2016 19:54:32, Jeff McKenna a écrit :
> > >> Hi all!
> > >> 
> > >> With today's trunk, I'm getting a compile error, during linking, with
> > >> Windows visual studio 2008:
> > >> 
> > >> ***
> > >> Creating library gdal_i.lib and object gdal_i.exp
> > >> nitfwritejpeg_12.obj : error LNK2001: unresolved external symbol "void
> > >> __cdecl jpeg_vsiio_
> > >> dest_12(struct jpeg_compress_struct12 *,struct _iobuf *)"
> > >> (?jpeg_vsiio_dest_12@@YAXPAUjpeg
> > >> _compress_struct12@@PAU_iobuf@@@Z)
> > >> ***
> > >> 
> > >> The problem line seems to be in nitfwritejpeg_12.cpp on the 4th line:
> > >> https://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/nitf/nitfwritejpe
> > >> g_ 12. cpp#L4
> > >> 
> > >> This line seems to have been added during a change a few weeks ago
> > >> with the comment "Fix One Definition Rule violations"
> > >> https://trac.osgeo.org/gdal/changeset/32062/#file8
> > >> 
> > >> I'm not sure if this is relevant, but my builds use libjpeg-9a
> > >> 
> > >> Please let me know if you have any ideas, thanks,
> > > 
> > > Jeff,
> > > 
> > > is this is a fresh checkout / clean build ?
> > > 
> > > Even
> > 
> > Yes very fresh, when I first got this error I deleted the old
> > checkout/folder and did an "svn co" with a fresh new copy.
> 
> Mmm, could you share your precompiled libjpeg-9a includes, .lib and .dll
> and your nmake.opt ?
> Our appveyor bots use internal libjpeg-6b and Tamas builds external
> libjpeg-6b apparently.

Hum actually thinking about this and trying on Linux...

I don't get build errors on Linux but at runtime this doesn't work properly 
(12bit JPEG not working) due to the mix of ABI between internal libjpeg-6b 
used for jpeg 12bit and external libjpeg-9a for jpeg 8bit (they have 
incompatible ABI). This also holds true for GDAL 2.0 (just checked) and older 
versions.

Such a mix could theoretically be supported but would require annoying changes 
to the build system to make sure that source files using jpeg 8bit only include 
headers of the external libjpeg, and source files using jpeg 12bit only use the 
internal libjpeg... Currently NITF/GTiff will probably use the headers of 
external libjpeg even for jpeg 12 bit (they should use the headers of the 
internal libjpeg), so chaos will happen.

So for now, your choice is :
1) use libjpeg-6b, internal or external (or something with a compatible ABI 
like libjpeg-turbo which has nice speedup optimizations)
2) or use external libjpeg > 6b and disable jpeg12 bit support. So 
comment/disable JPEG12_SUPPORTED = 1 in nmake.opt

I guess my change now exhibits the fact that the mix of different libjpeg is 
incompatible (although I'm not completely clear why you get it. Perhaps the 
struct jpeg_compress_struct12 being not the same when internal libjpeg12 is 
compiled and when it is used by the NITF driver), whereas previously it was 
somewhat hidden.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com