GDAL fails to load proj4_9.dll

[battleguard]

I am attempting to port osgearth to vcpkg (#3257) and it is not able to do any spatial transformations because GDAL is unable to load the proj library.

I am guessing this might be an issue with the way the proj4 library is built through vcpkg.

Here is the lines that are causing problems in GDAL: https://github.com/OSGeo/gdal/blob/v2.2.2/gdal/ogr/ogrct.cpp#L191

static const char GetProjLibraryName() { const char pszLibName = LIBNAME; if( CPLGetConfigOption("PROJSO", NULL) != NULL ) pszLibName = CPLGetConfigOption("PROJSO", NULL); return pszLibName; } The pszLibName is being returned as proj.dll when it is proj4_9.dll in the bin folder.

Here is the block that is actually trying to load the dll https://github.com/OSGeo/gdal/blob/v2.2.2/gdal/ogr/ogrct.cpp#L200

I am not sure of a solution right now, but hopefully someone can let me know if this is an actually problem and I am not just doing something wrong.

[treigilbert]

I have also seen this problem with using osgearth with gdal and was looking at the same code block trying to load proj.dll. A fast solution (not a good one) is to make a copy of proj4_9.dll and rename it proj.dll in the exectuable's path. This seemed to bypass the issue (allowing gdal to load the dll) and allow coordinate conversion in osgearth using gdal, but a patch to gdal would be much better. I used a osg port with a newer osg version and a osgearth port based on the osg port. If a get a little time, I'll put in a PR request if someone doesn't beat me to it. I seemed to also remember an issue with the osg plugins folder not getting copied to the executable's path (have to check on that).

[battleguard]

@treigilbert You can also temporarily get around the problem by using the PROJSO environment variable and setting it to your proj dll name.

Also yes I have ran into the plugins not being in the bin folder problem also. There is a problem with vcpkg not allowing the plugins to go into the bin on install due to them not being essential to the cmake project, so this caused osg and my osgearth port to have to copy them into the tools folder, but this is pretty much useless since you cannot use them if there in the tools folder and they need to be in the bin folder. I am also having the same problem with the applications for osgearth such as osgearth_viewer which I feel should definitely be in the bin folder also because it is essential to osgearth.

Currently I am abandoning hope of using vpkg until these 2 problems are addressed and along with the GDAL problem I have come to believe I do not have enough control on how my dependencies are built to see this project as viable option.

[JackBoosY]

Hi @battleguard @treigilbert, thanks for reporting this issue! When GDAL is exported, the headers and library of proj4 will also be exported. So, the only problem is that the library for proj4 needs to be renamed to proj.dll?

[Neumann-A]

GDAL portfile.cmake should probably be rewritten to use find_package & porbably get_property to find the libraries and include directories instead of using hardcoded library names/paths.

[JackBoosY]

Hi @battleguard, thanks for reporting this issue. I've fixed this issue now, please update vcpkg and rebuild gdal.

Thanks.

[lakinwecker]

I'm still having this problem with the most recent version of gdal. Should I open a new ticket or post the details here?

[JackBoosY]

@lakinwecker Please open a new issue.

Thanks.