Lidar modules broken in 64bit WinGRASS

[wenzeslaus]

lasinfo, r.in.lidar and v.in.lidar are broken in 64bit version of 7.0.4svn (r68280) and 7.1.svn (r68287). The modules are present, show GUI and show help but will fail to work with any file (tried two, one is ​here). lasinfo fails as well. Possible commands:

lasinfo 0793_016.las
r.in.lidar -e input=0793_016.las output=n method=n resolution=5 -o

System Info
GRASS version: 7.1.svn
GRASS SVN revision: r68287  
Build date: 2016-04-20
Build platform: x86_64-w64-mingw32
GDAL: 2.0.2
PROJ.4: 4.9.2 
GEOS: 3.5.0
SQLite: 3.7.17
Python: 2.7.5 
wxPython: 2.8.12.1 
Platform: Windows-8-6.2.9200  

Running them with --help works as well as e.g. r.in.gdal works in the 64bit version.

In 32bit version (7.0.4RC1 and 7.1.svn), lasinfo and r.in.lidar work:

GRASS version: 7.1.svn
GRASS SVN revision: r68287  
Build date: 2016-04-20
Build platform: i386-w64-mingw32  
GDAL: 2.0.2
PROJ.4: 4.9.2 
GEOS: 3.5.0
SQLite: 3.7.17
Python: 2.7.4 
wxPython: 2.8.12.1 
Platform: Windows-8-6.2.9200

[martinl]

I can confirm this bug. I just wonder whether it's problem of GRASS or liblas OSGeo4W package.

[martinl]

I tried to install fresh OSGeo4W64 just with liblas cmd package. lasinfo fails with the same error as described. So it's appearently bug in liblas osgeo4w packaging. I suggest to report this issue in osgeo4w trac and close this bugreport.

[wenzeslaus]

Replying to martinl:

I suggest to report this issue in osgeo4w trac

Done in:

​https://trac.osgeo.org/osgeo4w/ticket/493

close this bugreport.

I'm not sure. We should not release without the OSGeo4W 493 issue fixed.

[martinl]

Replying to wenzeslaus:

I'm not sure. We should not release without the OSGeo4W 493 issue fixed.

well, it depends when it will be fixed. In my eyes it's not blocker whole GRASS release. We can always build fixed Windows package with updated liblas.

[wenzeslaus]

Replying to martinl:

well, it depends when it will be fixed. In my eyes it's not blocker whole GRASS release.

Well, the question is what

We can always build fixed Windows package with updated liblas.

We've already tried that for 7.0.3 by mistake. libLAS modules and C++ were broken. It created a lot of questions. There was no way of downloading installer of a stable version which does what the previous one did (libLAS and C++ modules). Now, we would have to provide 7.0.3 alongside with 7.0.4 unless we don't want users to download 6.4. We would also have to tell users before download that they should not download 7.0.4 if they want to use these and these modules.

[martinl]

Replying to wenzeslaus:

Replying to martinl:

well, it depends when it will be fixed. In my eyes it's not blocker whole GRASS release.

Well, the question is what

liblas package in osgeo4w. It's not our deal.

We can always build fixed Windows package with updated liblas.

We've already tried that for 7.0.3 by mistake. libLAS modules and C++ were broken. It created a lot of questions. There was no way of downloading installer of a stable version which does

C++ modules are now fixed, so? Another reason why to not wait with 7.0.4 release.

[martinl]

Please consider downgrading priority or even closing this ticket. ASAIU this ticket is not related to GRASS but liblas itself.

[wenzeslaus]

Downgraded but how to communicate to users that they should install install 32bit version if they want these modules to work?

[martinl]

The issue seems to be gone with all (64bit) builds (7.0.5/7.2/7.3) starting on 10/7. Testing welcome.

[annakrat]

Tested 32 and 64bit 7.0.5, 7.2, standalone and OSGeo4W and las tools and v/r.in.lidar are not working. Several people here reported the same, it worked for one colleague for some reason. How did it get broken again?

[hellik]

Replying to annakrat:

Tested 32 and 64bit 7.0.5, 7.2, standalone and OSGeo4W and las tools and v/r.in.lidar are not working. Several people here reported the same, it worked for one colleague for some reason. How did it get broken again?

tested here with

System Info                                                                     
GRASS version: 7.3.svn                                                          
GRASS SVN revision: r69714                                                      
Build date: 2016-10-24                                                          
Build platform: i386-w64-mingw32                                                
GDAL: 2.1.1                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.14.1                                                                  
Python: 2.7.4                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)                                  

and

lasinfo (libLAS 1.7.0 with GeoTIFF 1.3.0 GDAL 1.8.1 LASzip 2.1.0)

v.in.lidar fails with the data from the ​wiki example.

also lasinfo itself fails on this sample data set.

[hellik]

Replying to hellik:

also lasinfo itself fails on this sample data set.

but e.g. las2txt of the same osgeo4w environment works without failing.

[hellik]

Replying to hellik:

tested here with

System Info                                                                     
GRASS version: 7.3.svn                                                          
GRASS SVN revision: r69714                                                      
Build date: 2016-10-24                                                          
Build platform: i386-w64-mingw32                                                
GDAL: 2.1.1                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.14.1                                                                  
Python: 2.7.4                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)                                  

now tested with

System Info                                                                     
GRASS Version: 7.3.svn                                                          
GRASS SVN revision: r69714                                                      
Build date: 2016-10-24                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 2.1.1                                                                     
PROJ.4: 4.9.3                                                                   
GEOS: 3.5.0                                                                     
SQLite: 3.14.1                                                                  
Python: 2.7.5                                                                   
wxPython: 2.8.12.1                                                              
Platform: Windows-8-6.2.9200 (OSGeo4W) 

lasinfo Serpent_Mound_Model_LAS_Data.las
---------------------------------------------------------
  Header Summary
---------------------------------------------------------

  Version:                     1.0
  Source ID:                   0
  Reserved:                    0
  Project ID/GUID:             '00000000-0000-0000-0000-000000000000'
  System ID:                   ''
  Generating Software:         'TerraScan'
  File Creation Day/Year:      0/0
  Header Byte Size             227
  Data Offset:                 759
  Header Padding:              2
[...]

v.in.lidar -p input=D:\temp\lidartest\Serpent_Mound_Model_LAS_Data.las          
Using LAS Library Version 'libLAS 1.8.0 with GeoTIFF 1.4.0 GDAL 1.11.3 LASzip 2.2.0'
LAS File Version:                  1.0
System ID:                         ''
Generating Software:               'TerraScan'
File Creation Day/Year:            0/0
Point Data Format:                 1
Number of Point Records:           3265110
Number of Points by Return:        0 0 0 0 0
Scale Factor X Y Z:                0.01 0.01 0.01
Offset X Y Z:                      -0 -0 -0
Min X Y Z:                         289021 4.32094e+006 166.78
Max X Y Z:                         290106 4.32364e+006 215.48
Spatial Reference:
+proj=utm +zone=17 +datum=WGS84 +units=m +no_defs 
Data Fields:
  'X'
  'Y'
  'Z'
  'Intensity'
  'Return Number'
  'Number of Returns'
  'Scan Direction'
  'Flighline Edge'
  'Classification'
  'Scan Angle Rank'
  'User Data'
  'Point Source ID'
  'GPS Time'
[...]

v.in.lidar -e -t -b input=D:\temp\lidartest\Serpent_Mound_Model_LAS_Data.las output=Serpent_Mound_Model_pts
Die Projektionsinformationen des Eingabedatensatzes und der aktuellen Location scheinen übereinzustimmen.
Scanning 3265110 points...
16416272 points imported (limit was 1024)
219 input points were skipped by count-based decimation
The rest of points was ignored

on this win10 64bit box it works.

[martinl]

I tested v.in.lidar (64bit) with results below:

OSGeo4W: works (g73,g705); broken (g72rc)

Standalone: works (g705, g72rc, g72svn-n96)

[annakrat]

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

Then I tested an older computer. Here nothing works, but it behaves differently. r.in.lidar starts, but then it says GRASS7 has stopped working. Copying those dlls does not help. I tested different grass versions, nothing works.

[martinl]

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

standalone or osgeo4w installer. If standalone did you installed Microsoft Runtime Libs? Ma

[annakrat]

Replying to martinl:

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

standalone or osgeo4w installer. If standalone did you installed Microsoft Runtime Libs? Ma

both, yes I did

[hellik]

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

Then I tested an older computer. Here nothing works, but it behaves differently. r.in.lidar starts, but then it says GRASS7 has stopped working. Copying those dlls does not help. I tested different grass versions, nothing works.

I've tested it on several windows boxes (7, 8,10); it works everywhere.

could it be some kind of security issue by windows defender / av sw.

[martinl]

Replying to martinl:

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

standalone or osgeo4w installer. If standalone did you installed Microsoft Runtime Libs? Ma

I tried to install fresh Windows 8.1 and install winGRASS720svn. I can confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.

[hellik]

Replying to martinl:

Replying to martinl:

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

standalone or osgeo4w installer. If standalone did you installed Microsoft Runtime Libs? Ma

I tried to install fresh Windows 8.1 and install winGRASS720svn. I can confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.

AFAIK it's Visual C++ 2013 Redistributable

[hellik]

Replying to hellik:

Replying to martinl:

Replying to martinl:

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

standalone or osgeo4w installer. If standalone did you installed Microsoft Runtime Libs? Ma

I tried to install fresh Windows 8.1 and install winGRASS720svn. I can confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.

AFAIK it's Visual C++ 2013 Redistributable

​Visual C++ Redistributable Packages for Visual Studio 2013

[hellik]

Replying to hellik:

Replying to hellik:

Replying to martinl:

Replying to martinl:

Replying to annakrat:

I tested on 2 machines. First one is freshly installed Windows 10 and r.in.lidar does not even start. Here it seems some of the needed dlls are missing. When running r.in.lidar from terminal, it says msvcp120.dll and msvcr120.dll are missing. So I found them in some obscure system directory and copied them to extrabin and then everything works.

standalone or osgeo4w installer. If standalone did you installed Microsoft Runtime Libs? Ma

I tried to install fresh Windows 8.1 and install winGRASS720svn. I can confirm this issue, it says msvcp120.dll and msvcr120.dll are missing.

AFAIK it's Visual C++ 2013 Redistributable

​Visual C++ Redistributable Packages for Visual Studio 2013

it's on the download server:

​/osgeo4w/x86_64/release/msvcrt/msvcrt2013

but it seems, it isn't downloaded by the standalone:

see ​https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi.tmpl#L843

843	Section "Important Microsoft Runtime DLLs" SecMSRuntime
844	
845	        ;Set the size (in KB)  of the archive file
846	        StrCpy $ARCHIVE_SIZE_KB 12521
847	       
848	        ;Set the size (in KB) of the unpacked archive file
849	        AddSize 13500
850	       
851	        StrCpy $HTTP_PATH "http://download.osgeo.org/osgeo4w/${PLATFORM}/release/msvcrt/"
852	        !if ${PLATFORM} == "x86_64"
853	            StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-8.tar.bz2"
854	        !else
855	            StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-12.tar.bz2"
856	        !endif
857	        StrCpy $EXTENDED_ARCHIVE_NAME "Microsoft Visual C++ Redistributable Packages"
858	        StrCpy $ORIGINAL_UNTAR_FOLDER "install_msruntime"
859	       
860	        Call DownloadInstallMSRuntime

[annakrat]

Replying to annakrat:

Then I tested an older computer. Here nothing works, but it behaves differently. r.in.lidar starts, but then it says GRASS7 has stopped working. Copying those dlls does not help. I tested different grass versions, nothing works.

Regarding this second problem I described (which seems to be unrelated to the first one), I tested a different Windows machine and it worked there. So it's not easily reproducible, but there is still some problem.

[hellik]

Replying to annakrat:

Regarding this second problem I described (which seems to be unrelated to the first one), I tested a different Windows machine and it worked there. So it's not easily reproducible,

it seems to be related to an installed ​Visual C++ Redistributable Packages for Visual Studio 2013.

it may or may not be installed on some computers, thus maybe the difference.

[martinl]

Replying to hellik:

but it seems, it isn't downloaded by the standalone:

standalone installer seems to be right, it downloads the metapackage. Problem is that this metapackage depends only on 2008 and 2010, see ​http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/setup.hint

[martinl]

Replying to martinl:

standalone installer seems to be right, it downloads the metapackage. Problem is that this metapackage depends only on 2008 and 2010, see ​http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/setup.hint

report in upstream, ​https://trac.osgeo.org/osgeo4w/ticket/520

[martinl]

Replying to martinl:

report in upstream, ​https://trac.osgeo.org/osgeo4w/ticket/520

Update: las package (64bit) has now new dependency - msvcrt2013. It means that this issue is fixed in OSGeo4W installer. It also means that we need to modify standalone installer to download msvcrt2013 manually.

[martinl]

Replying to martinl:

Update: las package (64bit) has now new dependency - msvcrt2013. It means that this issue is fixed in OSGeo4W installer. It also means that we need to modify standalone installer to download msvcrt2013 manually.

What be nice to modify installer to download and install both packages together.

[hellik]

Replying to martinl:

Replying to hellik:

but it seems, it isn't downloaded by the standalone:

standalone installer seems to be right, it downloads the metapackage.

852	        !if ${PLATFORM} == "x86_64"
853	            StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-8.tar.bz2"
854	        !else
855	            StrCpy $ARCHIVE_NAME "msvcrt-1.0.1-12.tar.bz2"
856	        !endif

at least for x86 we should pump up the version, see:

http://download.osgeo.org/osgeo4w/x86/release/msvcrt/msvcrt-1.0.1-13.tar.bz2

[hellik]

Replying to martinl:

Replying to martinl:

Update: las package (64bit) has now new dependency - msvcrt2013. It means that this issue is fixed in OSGeo4W installer. It also means that we need to modify standalone installer to download msvcrt2013 manually.

What be nice to modify installer to download and install both packages together.

in ​https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi.tmpl#L826

826	        untar_ok:
827	        DetailPrint "Archive successfully unzipped."
828	        DetailPrint "Installing vcredist_2005_x86.exe ..."
829	        ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2005_x86.exe" /q'
830	        DetailPrint "Installing vcredist_2008_x86.exe ..."
831	        ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2008_x86.exe" /q' 
832	        DetailPrint "Installing vcredist_2010_x86.exe ..."
833	        ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2010_x86.exe" /q'
834	        DetailPrint "Copying runtime files ..."
835	        CopyFiles "$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\*.dll" "$INSTALL_DIR\extrabin"
836	        DetailPrint "MS runtime files installed."
837	        Goto end

does it mean that standalone installer should download

http://download.osgeo.org/osgeo4w/x86_64/release/msvcrt/msvcrt2013/msvcrt2013-1.0.0-1.tar.bz2	

unzip and untar it and then run

ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist-2013-x64.exe" /q'

?

[martinl]

I just wonder where these files come from

	DetailPrint "Installing vcredist_2005_x86.exe ..."
	ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2005_x86.exe" /q'
	DetailPrint "Installing vcredist_2008_x86.exe ..."
	ExecWait '"$TEMP\$ORIGINAL_UNTAR_FOLDER\bin\vcredist_2008_x86.exe" /q'	
	DetailPrint "Installing vcredist_2010_x86.exe ..."

They are not part of msvcrt, msvcrt2008 or msvcrt2010 packages (they contains similar files but with another name)

[martinl]

Replying to martinl:

They are not part of msvcrt, msvcrt2008 or msvcrt2010 packages (they contains similar files but with another name)

Ah, I see, they are hardcoded for 32bit platform. The 64bit packages contains another files. I wonder how it could work till now for 64bit platform.

[martinl]

Replying to martinl:

Ah, I see, they are hardcoded for 32bit platform. The 64bit packages contains another files. I wonder how it could work till now for 64bit platform.

Answer: msvcp100.dll is part of msvcrt package. Anyway executing of vcredist exe files need to silently fail also in 32bit platforms since these files are part of msvcrt2008 and msvcrt2010 packages which are not downloaded by the installer.

[martinl]

Replying to martinl:

Answer: msvcp100.dll is part of msvcrt package. Anyway executing of vcredist exe files need to silently fail also in 32bit platforms since these files are part of msvcrt2008 and msvcrt2010 packages which are not downloaded by the installer.

Ah, I see. It's because msvcrt-12 (32bit) package contained also these binaries which is wrong. We need to fix this issue in the installer.

[martinl]

Replying to martinl:

Answer: msvcp100.dll is part of msvcrt package. Anyway executing of vcredist exe files need to silently fail also in 32bit platforms since these files are part of msvcrt2008 and msvcrt2010 packages which are not downloaded by the installer.

Ah, I see. It's because msvcrt-12 (32bit) package contained also these binaries which is wrong. We need to fix this issue in the installer.

First attempt done in r70106. The question is if we really need all of vcredist exe files. Till now no such file has been launched by 64bit installer. We appearently need vcredist2013 for las issue but do we really need other (2008,2010)? And what about 32bit platform?

[hellik]

Replying to martinl:

Replying to martinl:

Answer: msvcp100.dll is part of msvcrt package. Anyway executing of vcredist exe files need to silently fail also in 32bit platforms since these files are part of msvcrt2008 and msvcrt2010 packages which are not downloaded by the installer.

Ah, I see. It's because msvcrt-12 (32bit) package contained also these binaries which is wrong. We need to fix this issue in the installer.

First attempt done in r70106. The question is if we really need all of vcredist exe files. Till now no such file has been launched by 64bit installer. We appearently need vcredist2013 for las issue but do we really need other (2008,2010)? And what about 32bit platform?

AFAIR some time ago there was a change by Microsoft how they distribute their runtimes. at some stage only the exe were available, thus the exec in the installer.

AFAIU we haven't sync'ed the nsis installer with the upstream osgeo4w changes regarding MS runtimes.

which vcredist.exe-versions are needed depends upon the dependencies built upon.

[martinl]

In 70110:

wingrass: attempt to fix standalone installer to download and execute vcredist exe files - add missing global vars (see #2996)

[martinl]

In 70113:

wingrass: attempt to fix standalone installer to download and execute vcredist - fix typo (see #2996)

[martinl]

Replying to hellik:

which vcredist.exe-versions are needed depends upon the dependencies built upon.

I did quick investigation:

32bit:

grep msvcrt2005 * --include='setup.hint' -R

-> no dep

grep msvcrt2008 * --include='setup.hint' -R

-> 1 dep

msvcrt/setup.hint:requires: msvcrt2008 msvcrt2010

grep msvcrt2010 * --include='setup.hint' -R

-> 5 deps (none of them are part of standalone installer)

gdal/gdal-dev/gdal-dev-sosi/setup.hint:requires: gdal-dev msvcrt2010
gdal/gdal-dev/gdal-dev-filegdb/setup.hint:requires: gdal-dev msvcrt2010
gdal/gdal-dev/gdal-dev-oracle/setup.hint:requires: gdal-dev oci msvcrt2010 libjpeg
icu/icu-libs/setup.hint:requires: msvcrt2010
msvcrt/setup.hint:requires: msvcrt2008 msvcrt2010

grep msvcrt2013 * --include='setup.hint' -R

-> 1 dep (part of standalone installer)

libpq/setup.hint:requires: shell msvcrt2013 libintl

grep msvcrt2015 * --include='setup.hint' -R

-> no dep

64bit:

grep msvcrt2008 * --include='setup.hint' -R

-> 1 dep

msvcrt/setup.hint:requires: msvcrt2008 msvcrt2010

grep msvcrt2010 * --include='setup.hint' -R

-> 5 deps (none of them part of standalone installer)

gdal/gdal-dev/gdal-dev-sosi/setup.hint:requires: gdal-dev msvcrt2010
gdal/gdal-dev/gdal-dev-filegdb/setup.hint:requires: gdal-dev msvcrt2010
gdal/gdal-dev/gdal-dev-oracle/setup.hint:requires: gdal-dev oci msvcrt2010 libjpeg
icu/icu-libs/setup.hint:requires: msvcrt2010
msvcrt/setup.hint:requires: msvcrt2008 msvcrt2010

grep msvcrt2012 * --include='setup.hint' -R

-> 4 deps (none of them part of standalone installer)

boost/boost-devel/setup.hint:requires: msvcrt2012
boost/boost-libs/setup.hint:requires: msvcrt2012
boost/setup.hint:requires: msvcrt2012
pcl/setup.hint:requires: flann eigen boost msvcrt2012

grep msvcrt2013 * --include='setup.hint' -R

-> 4 deps (liblas part of standalone installer)

hexer/setup.hint:requires: msvcrt gdal msvcrt2013
liblas/setup.hint:requires: shell libtiff libgeotiff gdal111dll proj proj-hpgn proj-datumgrid proj-vdatum laszip msvcrt2013
libspatialindex/setup.hint:requires: shell msvcrt2013
points2grid/setup.hint:requires: shell msvcrt2013

So it seems that we need (liblas, libpq) for standalone installer just msvcrt2013 (both on 32bit and 64bit). To be safe we could add msvcrt2008 and mscvrt2010 (which are dependencies of msvcrt package). On 32bit platform also msvcrt2012 (bacause of boost-libs). Then the result will be exactly same as with osgeo4w installer.

In summary:

32bit: msvcrt2008,msvcrt2010,msvcrt2012,msvcrt2013

64bit: msvcrt2008,msvcrt2010,msvcrt2013

Any comments?

[martinl]

Replying to martinl:

In summary:

32bit: msvcrt2008,msvcrt2010,msvcrt2012,msvcrt2013

64bit: msvcrt2008,msvcrt2010,msvcrt2013

Correct summary:

32bit: msvcrt2008,msvcrt2010,msvcrt2013

64bit: msvcrt2008,msvcrt2010,msvcrt2012,msvcrt2013

[martinl]

In 70114:

wingrass: attempt to fix standalone installer to download and execute vcredist - cleanup dependencies (see #2996)

[martinl]

Replying to martinl:

Correct summary:

32bit: msvcrt2008,msvcrt2010,msvcrt2013

64bit: msvcrt2008,msvcrt2010,msvcrt2012,msvcrt2013

Done r70114

[hellik]

Replying to martinl:

Replying to martinl:

In summary:

32bit: msvcrt2008,msvcrt2010,msvcrt2012,msvcrt2013

64bit: msvcrt2008,msvcrt2010,msvcrt2013

Correct summary:

32bit: msvcrt2008,msvcrt2010,msvcrt2013

64bit: msvcrt2008,msvcrt2010,msvcrt2012,msvcrt2013

Looks good.

[martinl]

In 70123:

winGRASS installer: define ARCHIVE_NAME2012 only for 64bit (see #2996)

[martinl]

In 70126:

wingrass: attempt to fix standalone installer to download and execute vcredist (see #2996)

(relbr72: merge 70106, 70110, 70113, 70114, 70123 from trunk)

[martinl]

I tested the latest G73 (1) on freshly installed Windows 8.1 64bit. The Lidar modules seems to work. Please could you confirm?

(1) ​https://wingrass.fsv.cvut.cz/grass73/x86_64/WinGRASS-7.3.svn-r70124-101-Setup-x86_64.exe

[annakrat]

Replying to martinl:

I tested the latest G73 (1) on freshly installed Windows 8.1 64bit. The Lidar modules seems to work. Please could you confirm?

(1) ​https://wingrass.fsv.cvut.cz/grass73/x86_64/WinGRASS-7.3.svn-r70124-101-Setup-x86_64.exe

Yes, it works. I suggest to close this for now. I am still experiencing crashing on one computer with older Windows installation, but it's hard to tell what the problem could be.

[martinl]

In 70128:

wingrass: attempt to fix standalone installer to download and execute vcredist (fix #2996)

(relbr70: merge 70106, 70110, 70113, 70114, 70123 from trunk)