[gdal-dev] Orfeo tool box and gdal

[Even Rouault]

Le vendredi 09 novembre 2012 13:29:32, DmitriyS a écrit :
> Hello, dear developers. I wish to build OTB v.3.14 with gdal v.1.8.1 and
> have several problems (Windows 7). I could generate OTB solution through
> CMake, but ,bulding projects, got one mistakes, which for me is unresolved
> at this moment. As an import gdal lib I set gdal_i.lib of debug version,
> and according to source gdal must export class GDALJP2Box with the next
> constructor: GDALJP2Box::GDALJP2Box(struct _VSILFILE *).
> But OTB looks for GDALJP2Box::GDALJP2Box(struct iobuf *) and there is the
> error of unresolved external. Ok, if I build OTB with gdal of release mode
> there are no problems, as in release it exports
> GDALJP2Box::GDALJP2Box(struct iobuf *). However it does not help me any way
> because I need integrate OTB in application which has already used gdal
> v1.8.1 for a long time. In case I build OTB through gdal v.1.9.1 it is
> allright. And I am surprised that in debug mode gdal v.1.9.1 exports
> GDALJP2Box::GDALJP2Box(struct iobuf *), though its code has no differences
> in that section compare to v1.8.1. I corrected  gdal v1.8.1 sources  to
> make it export GDALJP2Box::GDALJP2Box(struct iobuf *) in debug, but this
> variant produced memory leaks in library which I had never had before,
> though application worked. Nevertheless it is intermediate solution.
> Does anybody know what I should do?

The issue you hit comes from the following snippet in port/cpl_vsi.h :

/* Make VSIL_STRICT_ENFORCE active in DEBUG builds */
#ifdef DEBUG
#define VSIL_STRICT_ENFORCE
#endif

#ifdef VSIL_STRICT_ENFORCE
typedef struct _VSILFILE VSILFILE;
#else
typedef FILE VSILFILE;
#endif

The rationale was to have strict typing in debug builds so that people don't 
confuse FILE* and VSILFILE* in the GDAL drivers, while in release mode we 
still alias VSILFILE* to FILE* as people have used that for a long time and we 
didn't want to break things.

(I'm going to add in the http://trac.osgeo.org/gdal/wiki/GDAL20Changes that we 
should use typedef struct _VSILFILE VSILFILE; in both debug and release 
versions of GDAL)

This was already in place in 1.8, so I'm not sure why you would see a 
difference of behaviour between 1.8 and 1.9, but I'm afraid I have not 
completely followed all your attempts (perhaps that one of the builds didn't 
have DEBUG defined as you thought ?).

Anyway, the solution is to not use a GDAL built with DEBUG defined with other 
applications that have been built against a GDAL without DEBUG defined. The 
problem should only arise with C++ symbols.

I don't understand why changing the signature of GDALJP2Box::GDALJP2Box() 
would cause memory leaks however.