[gdal-dev] Error compiling trunk (nitf)

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


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

> 
> -jeff

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


More information about the gdal-dev mailing list