GDAL 3.1.0 and PROJ 7.0.1 : link error for unresolved shgetfolderpathw

[chacha21]

Hello,

I just built GDAL 3.1.0 with PROJ 7.0.1 with Visual Studio 2019, 64 bits.
There is a link error similar to https://stackoverflow.com/questions/24619169/lnk2019-unresolved-external-symbol-shgetfolderpathw

To fix it , I can just edit the GDAL nmake.opt and replace
PROJ_LIBRARY = [some path]\proj.lib
by
PROJ_LIBRARY = [some path]\proj.lib shell32.lib

Such an error was not present in my previous build of GDAL 3.0.4 with PROJ 6.3.0.
I am not sure if it is a regression or intended behaviour, either from PROJ or GDAL.

Whatever, I report it here.

[rouault]

There was a similar report yesterday on the mailing list:
https://lists.osgeo.org/pipermail/gdal-dev/2020-May/052103.html
https://lists.osgeo.org/pipermail/gdal-dev/2020-May/052104.html

The use of SHGetFolderPathW() is new to PROJ 7
Is is a static or dynamic build of PROJ ? With dynamic builds, our continuation integration is happy with just proj.lib
Or is it just a GDAL build with PROJ as the only dependency (if so, our CI might have the shell32.lib dependency through something else)

[rouault]

And did you build PROJ with libtiff and libcurl support ?

[chacha21]

This is a static build of PROJ,
I have configured my PROJ CMakefile :
libTIFF is not enabled
then
libCURL is not enabled
then
PROJSYNC is not enabled
(and just for information SQLITE is enabled, with lib and exe and include paths)

[rouault]

This is a static build of PROJ,

That' s probably be the reason then. I'll modify the hints in nmake.opt, although I suspect there might be an issue in the build recipee of PROJ. Not completely sure

libTIFF is not enabled

that's defintely not recommended. You'll have issues with datum shifts and will be not able to use the grids in the proj-data package.

libCURL is not enabled

I believe the curl dependency brings the shell32.lib one normally. Not having libCURL support is less critical though

[chacha21]

Do you mean that GDAL behaviour is degraded if libtiff is not set in PROJ build ?
I intend to use GDAL just to read/write ENVI, FITS and GTIFF, but I do not process data with GDAL itself.
Since GTIFF was supported by my previous GDAL build with PROJ 6, that did not require that TIFF thing, I did not enabled libtiff in PROJ 7 either. (because GDAL already requires me to build PROJ, I would prefer avoiding a new build dependency !)

[rouault]

Do you mean that GDAL behaviour is degraded if libtiff is not set in PROJ build ?

Depends on what you do, but the CMake message is explicit enough

  message(WARNING
    "TIFF support is not enabled and will result in the inability to read "
    "some grids")

If you don't do any coordinate transformations involving datum transformations, this should be OK.

[rouault]

@chacha21

Would you mind applying the following patch to PROJ's src/lib_proj.cmake ?

diff --git a/src/lib_proj.cmake b/src/lib_proj.cmake
index 71561fc..2b6d802 100644
--- a/src/lib_proj.cmake
+++ b/src/lib_proj.cmake
@@ -417,6 +417,10 @@ if(CURL_ENABLED)
   target_link_libraries(${PROJ_CORE_TARGET} ${CURL_LIBRARY})
 endif()
 
+if(MSVC)
+  target_link_libraries(${PROJ_CORE_TARGET} PRIVATE Shell32)
+endif()
+
 if(MSVC AND BUILD_SHARED_LIBS)
   target_compile_definitions(${PROJ_CORE_TARGET}
     PRIVATE PROJ_MSVC_DLL_EXPORT=1)

and then re-link GDAL against that, without the explicit shell32.lib in PROJ_LIBRARY ?

[chacha21]

it raises an error :
CMake Error at src/lib_proj.cmake:420 (target_link_libraries):
The plain signature for target_link_libraries has already been used with
the target "proj". All uses of target_link_libraries with a target must be
either all-keyword or all-plain.

The uses of the plain signature are here:

• src/lib_proj.cmake:405 (target_link_libraries)

Call Stack (most recent call first):
src/CMakeLists.txt:3 (include)

[rouault]

ok, maybe just modify the line to target_link_libraries(${PROJ_CORE_TARGET} Shell32) (without PRIVATE)

[chacha21]

It does not work

I applied the patch
I removed the PRIVATE after applying the patch, so that CMake was happy
I have deleted the CMake cache before recompiling PROJ
I recompiled PROJ as a VS2019/x64 static lib with my usual options (no libtiff, no curl, no projsync, with sqlite)
I removed the shell32 reference that I had added in the GDAL nmake.opt
I cleanup the build before regenerating GDAL
I recompiled GDAL, and there was still the error regarding SHGetFolderPathW

I am really surprised that it does not work, I hope I did not forgot some other build cache.