Inconsistency between proj4 linked at build time and proj4 dynloaded in ogrct.cpp

[bartoli]

On windows, i just noticed that ogr/ogrct.cpp loads symbols from proj.dll

In my debug build of GDAL, i link to a debug "projd.lib", so that gdal uses a debug "projd.dll". projd.lib is really passed at GDAL link time by the gdal makefile, but no binary in my output GDAL distribution ends up having a dependency to it. And that GDAL debug dll still loads proj.dll because of ogrct.cpp. As my application is using proj from somewhere else, i end up having a debug version that loads proj.dll and projd.dll because of this.

If the presence of proj config options in the windows makefiles is still legitimate for some reason, then shouldn't the dll of the specified proj library be used in ogrct.dll to avoid loading it twice (or avoid ogrct failure if proj dll is not called proj.dll on some configs)?

For example by simply :

• definining a new makefile variable in nmake.opt (PROJ_BINARY?) that specifies the name of the dll to dynload, which value would be passed as LIBNAME preprocessor macro at ogrct.cpp compilation
• in ogrct.cpp, not redefining LIBNAME if it is already defined, and only keep trying to use default library name when it is not

[Even Rouault]

I'd bet your nmake options lack PROJ_FLAGS = -DPROJ_STATIC to use standard linking mechanism ?

[bartoli]

Indeed, i did not read hard enough. You can close this sorry