Native dependencies bugs

Problem

While using prebuilt gdal from gisinternals (and nuget packages by @szekerest), I’ve noticed some issues, which I’ve explained in details in gdal repo:

• Using wildcard breaks gdalbuildvrt osgeo/gdal - issue1749
• Bad support for cyrillic paths osgeo/gdal - issue 1245

These issues also appears in this library. Recently I’ve located a new problem, related to this nuget package: my antivirus deletes the package instantly because of libgeos_c.dll.

Solution

Not so long ago I’ve found some time to sort out how gdal builds and managed to find a solution for these issues.

First two I are fixed by changing gdal’s nmake.opt. It requires a new dependency – iconv (I’ve got it through vcpkg) and adding those paths to nmake.opt:

LIBICONV_INCLUDE = -IC:\vcpkg\installed\x64-windows\include
LIBICONV_LIBRARY = C:\vcpkg\installed\x64-windows\lib\libiconv.lib
LIBICONV_CFLAGS = -DICONV_CONST=const

I’ve also specified wsetargv.obj in nmake.opt, so it can be a part of solution too:

SETARGV = "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\lib\x64\wsetargv.obj"

I’ve tested the fixes above on latest gdal 3.1.2 with PROJ 7.1.0 (installed it’s deps through vcpkg, built with cmake+vs using sqlite3 and libtiff) built on win-x64. Even though I’ve tested it on gdal apps, not the library, I think that might be also a solution for resolving the same issue in library.

Regarding the geos issue, I’ve tried to build geos with your win/getgeos.bat script, but antivirus still deleted the libgeos_c.dll. Building the newer commit (e.g. 3.8.1 release, not 3.8.0) fixes the issue. I suppose there were some kind of vulnerability in 3.8.0, idk.

I’m not sure how your binaries are built and don’t want to break anything, so I’ve decided to open an issue instead of PR to convey this information to you.

[MaxRev-Dev]

Already finished VCPKG integration. Now, everything is controlled by makefiles. So native dependencies should not conflict with statically linked libraries. Now we can configure libraries those would have a static or dynamic link with GDAL. Soon, I will build v3.2.1 of GDAL and update docs.

https://github.com/MaxRev-Dev/gdal.netcore/blob/f53f3bc3454f04eb18a0b3879d0487ebc94c9888/shared/GdalCore.opt#L28-L41

[MaxRev-Dev]

@Gigas002 Good news. After a long break, I’m continuing to implement this feature. We have already a working windows build and tests are passing!

But currently there is a problem with building PROJ on linux.
All previous configurations were using a system curl library, and I want to link gdal against a version built by vcpkg. There is a missing curl-config on linux in vcpkg, so I don’t know how to make it work.

How it’s going - we have an open issue for now: https://github.com/microsoft/vcpkg/issues/14459

https://github.com/MaxRev-Dev/gdal.netcore/blob/19757e11dc0835b8bf631fea7e4e530fb559fc4b/unix/gdal-makefile#L131-L142