[Bug] winGRASS is missing: libgomp-1.dll, libgfortran-5.dll, libquadmath-0.dll

[hellik]

Describe the bug
as mentioned in #2013

I tested [WinGRASS-8.0.0-1-Setup.exe](https://grass.osgeo.org/grass80/binary/mswindows/native/WinGRASS-8.0.0-1-Setup.exe) 
and bug still persist. When I want launch v.surf.rst module from CMD I get error message libgomp-1.dll, libgfortran-5.dll was not found.

To Reproduce

launch v.surf.rst module from CMD

Expected behavior

v.surf.rst works

System info

System Info                                                                     
GRASS Version: 8.0.0                                                            
Code revision: 65675c832                                                        
Build date: 2022-02-09                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 3.4.1                                                                     
PROJ: 8.2.1                                                                     
GEOS: 3.10.2                                                                    
SQLite: 3.37.2                                                                  
Python: 3.9.5                                                                   
wxPython: 4.1.1                                                                 
Platform: Windows-10-10.0.19044-SP0 

[hellik]

solution:

libgomp-1.dll, libgfortran-5.dll, libquadmath-0.dll have to be copied to GRASS GIS 8.0\bin

it is needed for winGRASS standalone as well for OSGeo4W winGRASS

[hellik]

these DLLs are living in:

C:\msys64\mingw64\bin

of the winGRASS compilation environment MSYS2

[hellik]

AFAIU these DLLs should be added here package.sh

DLLS="
	/mingw64/bin/zlib1.dll
	/mingw64/bin/libbz2-1.dll
	/mingw64/bin/libiconv-2.dll
	/mingw64/bin/libexpat-1.dll
	/mingw64/bin/libfontconfig-1.dll
	/mingw64/bin/libbrotlidec.dll
	/mingw64/bin/libbrotlicommon.dll
	/mingw64/bin/libintl-8.dll
	/mingw64/bin/libsystre-0.dll
	/mingw64/bin/libtre-5.dll
	/mingw64/bin/libwinpthread-1.dll
	/mingw64/bin/libcairo-2.dll
	/mingw64/bin/libpixman-1-0.dll
	/mingw64/bin/libpng16-16.dll
	/mingw64/bin/libfreetype-6.dll
	/mingw64/bin/libharfbuzz-0.dll
	/mingw64/bin/libglib-2.0-0.dll
	/mingw64/bin/libgraphite2.dll
	/mingw64/bin/libpcre-1.dll
	/mingw64/bin/libstdc++-6.dll
	/mingw64/bin/libgcc_s_seh-1.dll
	/mingw64/bin/libfftw3-3.dll
	/mingw64/bin/libblas.dll
	/mingw64/bin/liblapack.dll
	/mingw64/bin/libomp.dll
"

[ninsbl]

Thanks @hellik for catching this. Yes, this seems to be the right place to fix it. Would be great if you could open a PR. Unfortunately, these kind of issues are not caught properly by CI / unittests...

[hellik]

Thanks @hellik for catching this. Yes, this seems to be the right place to fix it. Would be great if you could open a PR. Unfortunately, these kind of issues are not caught properly by CI / unittests...

I don't have my dev environment here with me in the next days. It would be fine if anyone could tackle this.

[wenzeslaus]

...these kind of issues are not caught properly by CI / unittests...

The grass.gunittest runner now takes --config filename.cfg as a parameter, so we can have a Windows-specific config file for the tests (for different excluded files and timeout combined with requiring 100% of tests to pass in the command line).

[ninsbl]

Reopening as backport is needed after successful test outside Github actions...

[ninsbl]

...these kind of issues are not caught properly by CI / unittests...

The grass.gunittest runner now takes --config filename.cfg as a parameter, so we can have a Windows-specific config file for the tests (for different excluded files and timeout combined with requiring 100% of tests to pass in the command line).

Nice. I see you added this with #2182
Do you have a pointer to an example config file that could be adjusted for MS Windows related tests?
I think however the problem here has been that dlls needed to be packaged for modules to run on other systems, while those dlls are available through msys on the test system (so we in a way have a lack of test failures), cause user systems do not have MSYS.