Opened 5 years ago

Closed 5 years ago

#6881 closed enhancement (invalid)

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

Reported by: bartoli Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords:


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

Change History (3)

comment:1 by Even Rouault, 5 years ago

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

comment:2 by bartoli, 5 years ago

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

comment:3 by Even Rouault, 5 years ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.