WinGRASS 6.4.1 fails to start after installation

[dhastings]

When one tries to start recently downloaded WinGRASS6.4.1 immediately after installation, it fails. Messages complain that files msvcr71.dll and msvcp71.dll are missing. Finding those files in my WinGRASS6.4, and copying them to the 6.4.1 installation, solved the problem for me.

Suggestion - confirm that these two files are missing from the 6.4.1 WinGRASS installation. If so, add them. If not, why did they not get properly placed in my installation (tried twice)?

This should not await a new version, but should be easy to rectify, so should be fixed now in the current installation of WinGRASS6.4.1

[dhastings]

more detailed description of problem

[hamish]

Hi,

this is a FAQ, typically only seen on a rather new machine. The C runtime libraries you are missing come from Microsoft, you have to download them from them.

do the files actually exist on you system? if so does the fix in #1354 fix things for you?

if not you can download it from Microsoft's site (do a web search for it) or from  http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71

see also  http://pcsupport.about.com/od/findbyerrormessage/a/msvcp71-dll-not-found-missing-error.htm

Hamish

[hamish]

see also #1450 and http://grass.osgeo.org/wiki/WinGRASS_Current_Status#XP.2F2000

[majgis]

I had this issue on Windows 7 64bit

This page has an excellent explanation:  http://stackoverflow.com/questions/1596167/where-to-download-microsoft-visual-c-2003-redistributable

Based on that information, I installed the three packages associated with .NET Framework 1.1:  http://msdn.microsoft.com/en-us/netframework/aa569264 (install from bottom up)

Grass 6.4.1 immediately started without the issue, no restart required.

I'm guessing a Python version earlier than 2.6 is being used. If you upgrade the version of Python you are using, you might change the dependency to a newer dll which is more likely to already be included on a newer machine...but then XP users might require a newer service pack.

It is unfortunate you can't distribute the dll. A random thought...if you accept the license agreement for visual C++ express, which is free, would you be able to distribute it? I'm assuming you need a licensed copy of Visual Studio (or free express version!) to redistribute.

[hamish]

Replying to majgis:

It is unfortunate you can't distribute the dll. A random thought...if you accept the license agreement for visual C++ express, which is free, would you be able to distribute it? I'm assuming you need a licensed copy of Visual Studio (or free express version!) to redistribute.

see  http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

The GPLv2 states:

The source code for a work means the preferred form of the work for
making modifications to it.  For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.  However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

The GPLv3 is more explicit about this, and the above FAQ doesn't make it clear which version it is talking about (but in general gnu.org defaults to talking about v3); we use GPL version 2.

summary: we can distribute binaries that need the library, but we can't distribute the library, and the best we can do is have the installer test for it and offer installation suggestions. (and/or easy to follow wiki instructions on where to get it and how to install it)

add to that the fact that I'm really not sure which of the many support libraries requires the dll. (it seems to change as osgeo4w evolves)

Hamish

[hamish]

Replying to majgis:

Based on that information, I installed the three packages associated with .NET Framework 1.1:  http://msdn.microsoft.com/en-us/netframework/aa569264 (install from bottom up)

that's version 1 of the installer, there are also more recent versions 2, 3, 3.5, and 4. Which one should we recommend?

Hamish

[majgis]

I suspect .NET 1.1 is the only version to include the msvcr71.dll.

From that stackoverflow link: "The Visual C++ 2003 runtime was not available as a seperate download because it was included with the .NET 1.1 runtime."

The dependency for msvcr71.dll is coming from the Python version being used. I had this same issue when I used py2exe with a Python/Qt? project.

When you upgrade the version of Python you are using, you will change your dependency to a newer version of the VC++ runtime and then it will start asking for msvcr90.dll or the like. Keep focus on version of runtime, the version you are currently using just happened to be packaged with .net 1.1, in the future you might depend on one of the following:  http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=29  http://www.microsoft.com/download/en/details.aspx?id=5555

I have created a stackoverflow question to get a handle on these dependencies:  http://stackoverflow.com/questions/9047072/windows-python-version-and-vc-redistributable-version

Another random thought...what if the installer looked for required redistributable-version on system, notified the user if it is missing, and gave the option to trigger remote download and install from Microsoft ...then everything is done after launching a single executable, making wingrass more accessible for noobs. I'm assuming facilitating download and install of dependent package hosted by microsoft would not break gnu license.

I'd love to help out: majgis <at> gmail <dot> com

[majgis]

Here is the result of the question asked on stackoverflow.com:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1. Windows Python Version 2. DLL Name 3. VC++ Redistributable 4. Link to installer

xxxxxxxxxxxxxxx

1. 2.4, 2.5, 2. msvcr71.dll, msvcp71.dll 3. Microsoft Visual C++ 2003 (7.1), included with .net 1.1 4.  http://msdn.microsoft.com/en-us/netframework/aa569264

xxxxxxxxxxxxxxxx

1. 2.6, 2.7, 3.0, 3.1, 3.2 3. msvcr90.dll, msvcp90.dll 4. Microsoft Visual C++ 2008 Redistibutable Package 5.  http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=29

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[majgis]

Same as previous response with WikiFormatting:

Windows Python Version	DLL Name	VC++ Redistributable
2.4, 2.5	msvcr71.dll, msvcp71.dll	MS VC++ 2003 (.net 1.1)
2.6, 2.7, 3.0, 3.1, 3.2	msvcr90.dll, msvcp90.dll	MS VC++ 2008

[hamish]

Replying to majgis:

I suspect .NET 1.1 is the only version to include the msvcr71.dll.

fwiw,  http://msdn.microsoft.com/library/ms171868.aspx "The .NET Framework 4 is highly compatible with applications that are built with earlier .NET Framework versions, except for some changes that were made to improve security, standards compliance, correctness, reliability, and performance."

(shrug)

The dependency for msvcr71.dll is coming from the Python version being used.

AFAIK that is currently being migrated to python 2.7 (I think it has already happened since the nightly build installer size jumped by ~8mb in the last week), so we'll wait a few days and see what it complains about.

Another random thought...what if the installer looked for required redistributable-version on system,

the best test is to have the installer run a little test program and catch & present any error along with advice.

notified the user if it is missing,

even if a test program caught the error, sometimes it is not very specific about the cause (e.g. when it quits with just [Error 14001]) and you just have to "know" that installing the extra dlls fixes it. Since osgeo4w is a moving target, if we hard-code in the missing dll and its download URL we could always be one step behind.. (shrug)

and gave the option to trigger remote download and install from Microsoft ...then everything is done after launching a single executable, making wingrass more accessible for noobs. I'm assuming facilitating download and install of dependent package hosted by microsoft would not break gnu license.

or at least open up a web browser to the appropriate MS page with the "install now" button on it.

thanks, Hamish

[majgis]

fwiw,  http://msdn.microsoft.com/library/ms171868.aspx "The .NET Framework 4 is highly compatible with applications that are built with earlier .NET Framework versions, except for some changes that were made to improve security, standards compliance, correctness, reliability, and performance."

From what I remember, .net 1.x and 2.x-beyond was a fundamental shift, but I'm shooting from the hip here. Also, these dlls are not part of the .Net framework, so it makes sense that microsoft would make a change to provide them as part of a separate redistributable package, another guess.

even if a test program caught the error, sometimes it is not very specific about the cause (e.g. when it quits with just [Error 14001]) and you just have to "know" that installing the extra dlls fixes it. Since osgeo4w is a moving target, if we hard-code in the missing dll and its download URL we could always be one step behind.. (shrug)

There should never be an error. We now know what redistributable package is required, during installation you can peek at the registry, if it isn't there, you provide messages or option to download.

[jef]

Do you include (and install) the osgo4w msvcrt package?

It contains the runtime libraries for VC 6.0, 7.0/2002, 7.1/2003 and the installers for the DLLs and assemblies for 8/2005, 9/2008 and 10.0/2010.

[hamish]

Replying to jef:

Do you include (and install) the osgo4w msvcrt package? It contains the runtime libraries for VC 6.0, 7.0/2002, 7.1/2003 and the installers for the DLLs and assemblies for 8/2005, 9/2008 and 10.0/2010.

No GPL software can bundle that, but it is another good option to point users to so that they can install it on their own.

GPL2:

However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source
or binary form) with the major components (compiler, kernel, and so
on) of the operating system on which the executable runs, unless
that component itself accompanies the executable.

GNU GPL faq:

the GPL says that libraries can only qualify as System Libraries as
long as they're not distributed with the program itself. If you
distribute the DLLs with the program, they won't be eligible for
this exception anymore; then the only way to comply with the GPL
would be to provide their source code, which you are unable to do.

Replying to majgis:

We now know what redistributable package is required,

msvcr90.dll since the move to python 2.7? (has that happened yet?)

during installation you can peek at the registry, if it isn't there, you provide messages or option to download.

sounds reasonable.

Hamish

[hellik]

Replying to hamish:

during installation you can peek at the registry, if it isn't there, you provide messages or option to download.

sounds reasonable.

here in my winvista-box the related (?) registry entry seems to be:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.218_none_34f1b3a4277681aa]
"S256H"=hex:cd,77,e2,c0,37,42,54,cc,63,81,ac,81,04,b3,3d,e7,e4,57,d9,c8,e1,df,\
  20,d8,51,f8,d5,6c,a9,27,c1,d3
"identity"=hex:4d,69,63,72,6f,73,6f,66,74,2e,56,43,39,30,2e,43,52,54,2c,20,43,\
  75,6c,74,75,72,65,3d,6e,65,75,74,72,61,6c,2c,20,54,79,70,65,3d,77,69,6e,33,\
  32,2c,20,56,65,72,73,69,6f,6e,3d,39,2e,30,2e,32,31,30,32,32,2e,32,31,38,2c,\
  20,50,75,62,6c,69,63,4b,65,79,54,6f,6b,65,6e,3d,31,66,63,38,62,33,62,39,61,\
  31,65,31,38,65,33,62,2c,20,50,72,6f,63,65,73,73,6f,72,41,72,63,68,69,74,65,\
  63,74,75,72,65,3d,78,38,36
"f!msvcr90.dll"=hex:6d,00,73,00,76,00,63,00,72,00,39,00,30,00,2e,00,64,00,6c,\
  00,6c,00
"f!msvcp90.dll"=hex:6d,00,73,00,76,00,63,00,70,00,39,00,30,00,2e,00,64,00,6c,\
  00,6c,00
"f!msvcm90.dll"=hex:6d,00,73,00,76,00,63,00,6d,00,39,00,30,00,2e,00,64,00,6c,\
  00,6c,00
"ClosureFlags"=dword:00000003
"c!microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.21022.218_34f1b3a4277681aa"=hex:

any idea which of these entries should be checked best by the wingrass-installer?

Helmut

[hamish]

current nightly builds of 6.4svn and 6.5svn (didn't try 7svn) ship MS's redistributibles in $GISBASE/extralib. As noted in comment:12, that is not allowed; they must be installed separately.

Hamish

[hellik]

Replying to hamish:

current nightly builds of 6.4svn and 6.5svn (didn't try 7svn) ship MS's redistributibles in $GISBASE/extralib. As noted in comment:12, that is not allowed; they must be installed separately.

here on my winvista-box:

C:\Program Files\GRASS 7.0.svn\extralib
[...]
msvcp60.dll
msvcp70.dll
msvcp71.dll
msvcr71.dll
msvcrt.dll

these files should be dropped within standalone-wingrass ?

Helmut

[hamish]

Replying to hellik:

here on my winvista-box: {{{ C:\Program Files\GRASS 7.0.svn\extralib [...] msvcp60.dll msvcp70.dll msvcp71.dll msvcr71.dll msvcrt.dll }}} these files should be dropped within standalone-wingrass ?

Correct; we are not allowed to redistribute them as an embedded part of our installer.

thanks, Hamish

[hamish]

some observations after moving away $GISBASE/extrabase/ms*.dll:

startup complaint on XP is against just msvcr71.dll. (or msvcrp71.dll? off the top of my head can't recall exactly) Other complaints may happen later, but that's the only one I saw before it quit.

installing the .net framework 4 does not supply that dll afaict. installing the .net framework 3.5 does not supply that dll afaict. (as expected, see table by majgis in comment:8)

with 3.5 and 4 frameworks installed, earlier framework packages won't install claiming a newer version is already there. But maybe they help Windows7 users..? we can't predict if a user has already installed one of the newer frameworks packages independently or not, so we can only say to try one of the older ones and hope for the best, or try another source from a web search and put it into C:\Windows\system32\ manually.

the 3rd party websites offering direct downloads of the .dlls all seem a bit shady to me, trying to get you to install some of their software instead of just the dll you want. so I don't like to recommend any specific site that isn't MS's or osgeo4w for the dll download as official advice.

maybe there could be a standalone osgeo4w package supplying the redistributable dlls listed in comment:15 to somewhere in the PATH? (where does the osgo4w msvcrt package suggested by jef end up?)

any clues on how to implement the registry checks (see comment:13) in the installer?

How does qgis deal with it these days? I know this used to be an issue for them too.

I'm not calling this ticket a blocker as it isn't blocking the source code release of 6.4.2 or binary installers on the other platforms.

thanks, Hamish

[jef]

Replying to hamish:

startup complaint on XP is against just msvcr71.dll. (or msvcrp71.dll? off the top of my head can't recall exactly) Other complaints may happen later, but that's the only one I saw before it quit.

msvcr71.dll can be anywhere in PATH. The DLLs for 8.0 and 9.0 need to installed. The end up somewhere in %WINDIR%\winsxs with assembly entries in the registry.

installing the .net framework 4 does not supply that dll afaict. installing the .net framework 3.5 does not supply that dll afaict. (as expected, see table by majgis in comment:8)

The .net frameworks might contain the DLLs too, but msvcrt package just contains the C++ redistributable packages (just extract the tar and checkout the postinstall.bat).

maybe there could be a standalone osgeo4w package supplying the redistributable dlls listed in comment:15 to somewhere in the PATH? (where does the osgo4w msvcrt package suggested by jef end up?)

How does qgis deal with it these days? I know this used to be an issue for them too.

It just installs the msvcrt package - the QGIS standalone installer just extracts the OSGeo4W packages and runs the postinstall scripts on installation (see  http://hub.qgis.org/projects/quantum-gis/repository/revisions/master/changes/ms-windows/osgeo4w/creatensis.pl for details).

[jef]

Direct link:  http://hub.qgis.org/projects/quantum-gis/repository/revisions/master/entry/ms-windows/osgeo4w/creatensis.pl

The GRASS NSIS installer could also download the msvcrt package on installation, untar it and run the postinstall.bat.

[hellik]

Replying to hamish:

any clues on how to implement the registry checks (see comment:13) in the installer?

there is already a lot of registry logic in the wingrass-installer, see i.e.

 https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows/GRASS-Installer.nsi#L204

so if it's known for what to search in the registry (differences betweenwinvista and win 7 ?), it should be possible to check this during wingrass-installation.

Helmut

[hellik]

Replying to jef:

Direct link:  http://hub.qgis.org/projects/quantum-gis/repository/revisions/master/entry/ms-windows/osgeo4w/creatensis.pl The GRASS NSIS installer could also download the msvcrt package on installation, untar it and run the postinstall.bat.

the related osgeo4w-msvcrt-package is downloadable from here:  http://download.osgeo.org/osgeo4w/release/msvcrt/

Helmut

[hamish]

maybe this one helps:

 http://home.gdal.org/tmp/vcredist_x86.exe