gdalbuildvrt doesn't process multiple files using wildcard

[Gigas002]

Expected behavior and actual behavior.

I want to create .vrt file from all .tifs in directory using wildcard in arguments, but I get errors:
ERROR 4: '../*.tif' does not exist in the file system, and is not recognized as a supported dataset name. Warning 1: Can't open ../*.tif. Skipping it

Steps to reproduce the problem.

Here's the string that I run: ./gdalbuildvrt ../test.vrt ../*.tif

Operating system

Windows 7 x64/Windows 10 x64

GDAL version and provenance

I've run several tests, and here's the list where that feature worked, and where it didn't:

2.1.3 - work
2.2.3 - work
2.3.0 - work
2.3.1 - work
2.3.2 - fail
2.3.3 - fail
2.4.0 - fail
2.4.1 - fail
2.4.2 - fail
3.0.0 - fail
Daily dev build - fail

All the binaries were taken from GISInternals.

Judging by gdalbuildvrt examples that should still work.

[rouault]

CC @szekerest @jef
Looking at https://docs.microsoft.com/en-us/cpp/c-language/expanding-wildcard-arguments?view=vs-2019 now that GDAL utilities use wmain() on Windows, GDAL should link against wsetargv.obj, and not setargv.obj

[jef-n]

Rings a bell: #568 (and qgis/QGIS#27021). OSGeo4W is using VC2015 for GDAL and setargv.obj and doesn't show the issue as far as I can tell.

[TimJMartin]

I have encountered this issue as well using the binaries from GISInternals, the only workaround is to create a file list and then pass that as a parameter to gdalbuildvrt.

Be great if this could be resolved

[jratike80]

I just noticed that unfortunately gdaltindex suffers from the same issue. Is this something that should be corrected on GDAL side or in the gisinternals build process?

[rouault]

I just noticed that unfortunately gdaltindex suffers from the same issue. Is this something that should be corrected on GDAL side or in the gisinternals build process?

Did you try with recent OSGeo4W ?

[jratike80]

Oh yes, GDAL 2.4.1, released 2019/03/15 from OSGeo4W works fine with *.tif.

[rouault]

So might be a gisinternals specific thing

[rafaleo]

It's my case as well. Is it really hard to fix that I could not install OSGeo4w?

[jef-n]

It's my case as well. Is it really hard to fix that I could not install OSGeo4w?

What do you mean?

C:\OSGEO4~1>ver

Microsoft Windows [Version 10.0.18362.592]

C:\OSGEO4~1>gdalbuildvrt --version
GDAL 3.0.4, released 2020/01/28

C:\OSGEO4~1>cd x\y

C:\OSGEO4~1\x\y>dir /b ..\*.tif
37886.tif
37888.tif
37890.tif
38086.tif
38088.tif
38090.tif
38282.tif
38284.tif
38286.tif
38288.tif
38290.tif
38482.tif
38484.tif
38486.tif
38488.tif
38490.tif
38492.tif
38682.tif
38684.tif
38686.tif
38688.tif
38690.tif
38692.tif
38882.tif
38884.tif
38886.tif

C:\OSGEO4~1\x\y>gdalbuildvrt ../test.vrt ../*.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

C:\OSGEO4~1\x\y>dir ..\test.vrt
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 36F4-E791

 Verzeichnis von C:\OSGEO4~1\x

05.02.2020  17:29            12.147 test.vrt
               1 Datei(en),         12.147 Bytes
               0 Verzeichnis(se), 19.957.157.888 Bytes frei

C:\OSGEO4~1\x\y>

[jratike80]

I believe that @rafaleo meant that for some reason he can't use GDAL from OSGeo4W.

The error seems to be in the buildsystem at gisinternals.com and therefore this GDAL ticket should perhaps be closed already. On the other hand, for Windows users the OSGeo4W.org and gisinternals.com are the places where GDAL is coming.

Because we are now chatting here, I wish that @jef-n and @szekerest could find some time to have a look at https://github.com/gisinternals/buildsystem/blob/master/Makefile, if that is where the issue should be fixex. I see this in the makefile

!IFDEF WIN64
SETARGV = "$(VCDIR)\lib\amd64\setargv.obj"
!ELSE
SETARGV = "$(VCDIR)\lib\setargv.obj"
!ENDIF

Should it be nowadays as in the commit by @rouault ?
SETARGV = "$(VCDIR)\lib\amd64\wsetargv.obj" or
SETARGV = "$(VCDIR)\lib\wsetargv.obj"

[jef-n]

!IFDEF WIN64
SETARGV = "$(VCDIR)\lib\amd64\setargv.obj"
!ELSE
SETARGV = "$(VCDIR)\lib\setargv.obj"
!ENDIF

OSGeo4W is apparently using the same settings (http://download.osgeo.org/osgeo4w/x86_64/release/gdal/gdal-3.0.4-2-src.tar.bz2 : osgeo4w/nmake{32,64}.opt)

[jratike80]

I tested all 4 versions from http://gisinternals.com/development.php

Both versions (32 and 64 bit) compiled with MSVC 2015 are OK.
Both versions compiled with MSVC 2017 fail with wildcards.

[rouault]

Closing. Seems to be a binary distribution issue, not a source one

[mukoki]

Has someone a solution to this problem ?
I tried with a OSGeo4W installation (GDAL 3.0.4, released 2020/01/28)
and one binary distribution from gisinternals which is said to be working in this thread (GDAL 3.1.0dev, released 2019/99/99)
But none support wildcard usage

[jratike80]

Asking questions through comments of a closed issue may not get much attraction always.

OSGeo4W is the build that has been working and still works for me.
Of the binary distributions from gisinternals those built with MSVC 2017 failed but MSVC 2015 builds did accept wildcards.

Please test OSGeo4W again and verify that you have MSVS 2015 build from gisinternals. If you still have problems report them as issues to corresponding projects. There should be already an open issue in gisinternals.com bug tracker and you can add your comments to it.

[mukoki]

Hey,
I just tested MSVS 2015 from gisinternal again and after I solved various path problems and I set PROJ_LIB environment variable, it works fine. Thanks ! (I tested it before, but your encouragment to do a second try had a magical effect ;-).
Sorry for the annoyance and the bad usage of the list.

[jratike80]

Our mailing list for both users and developers is gdal-dev https://lists.osgeo.org/mailman/listinfo/gdal-dev and that list has probably hundreds of readers. But users do not really need to know that the wildcard issue is not a bug in GDAL but elsewhere and what is most important is that you managed to install a version that accepts wildcards.

If you installed GDAL with the zip file from gisinternals then the sdkshell.bat batch file in the root directory should set paths for you.