[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