[gdal-dev] Error compiling trunk (nitf)

[Jeff McKenna]

On 2016-01-14 3:47 PM, Even Rouault wrote:
> 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.
>
>

Oh thanks Even, makes sense, and my guess at option2 was right :) 
Thanks again for checking this.

-jeff


-- 
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/