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. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev