[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