[gdal-dev] Error compiling trunk (nitf)

Even Rouault even.rouault at spatialys.com
Thu Jan 14 12:11:38 PST 2016


Le jeudi 14 janvier 2016 20:45:49, Jeff McKenna a écrit :
> On 2016-01-14 3:14 PM, Even Rouault wrote:
> > 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.
> 
> Ah, darn version issues (I just assumed that since libjpeg-9a has been
> out since 2014 we were all using it).

Not really. I see that recent Ubuntu versions use libjpeg-turbo with IJG 8c 
ABI compatibility (libjpeg-turbo can emulated 6b, 7x and 8x ABI depending on 
how you compile it). libjpeg-turbo explicitly refuses the new capabilities/ABI 
of IJG libjpeg-9a ( detailed at http://www.libjpeg-turbo.org/About/Jpeg-9 )

On Linux, GDAL works well on Ubuntu Trusty with its libjpeg-turbo with IJG 8c 
compatibility ABI and its internal 12bit 6b. This is probably a bit of luck...

> 
> Digging deeper, I notice that this code is triggered by a
> "JPEG12_SUPPORTED" parameter, which I have been setting for years in my
> nmake.opt   Disabling that solves this problem for now :)

You will loose JPEG-12 in GeoTIFF and NITF, but those are quite niche features 
admitedly. On the other side, the new features (lossless SmartScale 
compression) brought by libjpeg-9a are even more niche ! libjpeg-turbo, 
especially for its speedups for compression/decompression, would certainly be 
a better fit for MapServer use cases.

> 
> -jeff

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


More information about the gdal-dev mailing list