I’m trying to build the source following the instructions from gplates.2.5.0 src. In the unzipped dir, I look at follopwing the DEPS.Windows file and follow the instructions.
I am building in the Visual Studio 14.0 (2015) as it seems the most cited version within the help docs.
Going through the instuctions of DEPS.Windows file - and got the part for GDAL - at step 6, where I execute this command in the VS205 x64 Native Tools Command Prompt:
nmake /f makefile.vc MSVC_VER=1900 WIN64=1 GDAL_HOME=C:\sdk\gdal-3.4.2\gdal\msvc2015_64 devinstall
Most of the commands are executed successfully but towards the end of the process I got lots of unresolved external symbol errors - here is a sample:
ogr.lib(ogr_proj_p.obj) : error LNK2019: unresolved external symbol __imp_proj_context_get_database_path referenced in function “struct pj_ctx * __cdecl OSRGetProjTLSContext(void)” (?OSRGetProjTLSContext@@YAPEAUpj_ctx@@XZ)
gdal304.dll : fatal error LNK1120: 169 unresolved externals.
And finally this error: NMAKE :
fatal error U1077: ‘“C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.EXE”’ : return code ‘0x460’
I seem to have everything set up fine - I just can’t understand why it cant find the files for Proj! Can anyone help.
Is your Proj library a DLL or a static library? And which Proj version is it?
If it’s a DLL, try adding it’s location to the PATH environment variable (you’ll need to restart the console before compiling GDAL again). In my case it’s C:\SDK\PROJ\proj-9.3.1\msvc2019_64\bin.
Thanks for your reply John. I’ll try and answer best I can as its a while since I did things like this.
I believe the Proj I have setup is a static library as opposed to a DLL as I can find no dlls.
I have made the “msvc2015_64” output directory as in the instructions. It has made four directories (bin, include, lib and share). Inside these are either exectutables, the proj.lib file which I believe is important for GDAL and lots of .h header files.
I’ve compiled version 8.2.1 - again as in the instructions.
PS - One thing I notices was the cmake folder in lib dir, is there something I should be doing with this?
It has a proj and proj4 directories in there full of cmake files - is there something I’ve missed?
At the moment I am trying the 9.4.0 version - and so far I found a difference - there is a dll that is made in the msc2015_64 folder of bin. That didn’t happen before. Not sure it will make a difference…
OK - I have run the build for GDAL and it worked with 9.4.0 of Proj! At least I think it did -as I have the msvc2015_64 folder and its got some folders and files in there. I wonder if the missing dll from the older version of Proj was the reason??? If so I find it strange why it was not created in the first place.
Great, glad you got it working!
That’s normal.
I think so. The __imp prefix in your error message tells me it was trying to link to a DLL. It would have done that via the proj.lib you had in the lib\ sub-directory, but it was probably a static lib (rather than a stub for a DLL that should’ve been in bin\).
It is odd that Proj8 didn’t work. I originally built using Proj8 but that was a while ago. I’m now using Proj9 (as are you now). Good that it’s working now though.
1 Like
Thanks John - thats good to know.
On a general note going forward - am I best to build the dependencies with the latest versions of everything or should I try and stick as closely as posssible to the versions that can be seen in the DEPS.Windows doc?
It can be hit and miss with the versions. Sometimes the latest version of a dependency library doesn’t work with GPlates, requiring the GPlates source code to be updated. So I usually give an example version of each dependency that I’ve tried and that I know works. And it’s usually the latest version at the time I tried it.
Also, Visual Studio 2019 and 2022 work too. And going forward are probably better than 2015 (since newer versions of dependencies tend to use more recent C++ standards requiring newer compilers). VS 2015 is fine for now though.
1 Like
Thanks John for your help and your time - you’ve been super helpful.