Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.netwrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
On Thu, Aug 6, 2009 at 2:07 PM, Clinton Stimpsonclin...@elemtech.com wrote:
Bill Hoffman wrote:
James Bigler wrote:
I've just been bitten hard by this issue (many hours of frustration while
attempting to run a demo application that should have Just Worked (TM) ).
According to this page:
http://support.microsoft.com/kb/326922
You should install these versions of the CRT on target computers by
running the Vcredist_x86.exe application that is included with Visual
Studio. This is for the VS 2005 and 2008 versions of the C run-time
libraries except for Windows 2000 in which case you need to install them in
the system32 directory.
I was dropping Msvcr80.dll and friends as per
InstallRequiredSystemLibraries next to the binaries with ineffectual
results. It was really strange, because programs like Dependency Walker
seemed to find them just fine. It was only after running vcredist_x86.exe
that I was able to run my programs properly.
I though I should tell everyone that this method of distributing
Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to work.
You must install them into the Windows Side by Side location (WinSxS) using
the CRT.msm merge module or the vcredist_x86.exe that comes with Visual
Studio.
Now to try and get CPack to tell NSIS run the vcredist_x86.exe program
during installation.
Note, that many people might get lucky and have already installed a
product that installed the right vcredist_x86.exe before installing your
software.
No this works fine However you may be running into this issue:
Visual Studio 9 SP 1 has a bug that will cause trouble with cpack.
You can read about it here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682
Basically, when you compile an executable or dll with VS9 SP1 it embeds
manifest information into the the exe or dll that does not match the
version information in the manifest files that SP 1 provides for
redistribution.
We use the InstallRequiredSystemLibraries all the time without requiring
vcredist_x86.exe to be run.
There are some cases it doesn't work (3rd party libraries you can't compile
yourself).
I don't have two installs of the same Visual Studio versions with different
service packs, so, here's what I do.
IF(MSVC80)
FIND_PROGRAM(MSVC_REDIST NAMES
vcredist_${CMAKE_MSVC_ARCH}/vcredist_${CMAKE_MSVC_ARCH}.exe
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../SDK/v2.0/BootStrapper/Packages/
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../SDK/v2.0/BootStrapper/Packages/
)
GET_FILENAME_COMPONENT(vcredist_name ${MSVC_REDIST} NAME)
INSTALL(PROGRAMS ${MSVC_REDIST} COMPONENT Runtime DESTINATION bin)
SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ExecWait
'\\\$INSTDIRbin${vcredist_name}\\\')
ENDIF(MSVC80)
This worked for me after adding these lines before the above solution:
IF(CMAKE_CL_64)
SET(CMAKE_MSVC_ARCH amd64)
ELSE(CMAKE_CL_64)
SET(CMAKE_MSVC_ARCH x86)
ENDIF(CMAKE_CL_64)
John
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James thanks for the links. Now my head is really spinning. I have VC2008 Express installed on WinXP SP3 and evidently the vcredist.exe is NOT included with that version? At least I can not find it. So I guess I have to download it from MSDN (duh) and then manually set all the paths and all that in oder to have cmake/NSIS find and include it in the installer. And I thought deploying on OS X was a bit obtuse... Mike ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
Hold on there... The Express editions are not meant to build redistributable binaries. They're meant for personal use: i.e. -- each user compiles his own code. I'm pretty sure it's a violation of the Express edition license agreement to build binaries for other people. You need at least the Standard edition of VS to get that capability. HTH, David On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson mike.jack...@bluequartz.netwrote: On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James thanks for the links. Now my head is really spinning. I have VC2008 Express installed on WinXP SP3 and evidently the vcredist.exe is NOT included with that version? At least I can not find it. So I guess I have to download it from MSDN (duh) and then manually set all the paths and all that in oder to have cmake/NSIS find and include it in the installer. And I thought deploying on OS X was a bit obtuse... Mike ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
I don't believe that to be the case with Visual Express 2008. I don't know how previous editions work. ** *Can I use Express Editions for commercial use?* 1. Yes, there are no licensing restrictions for applications built using Visual Studio Express Editions. http://www.microsoft.com/express/support/faq/ Juan On Thu, Aug 20, 2009 at 4:33 PM, David Cole david.c...@kitware.com wrote: Hold on there... The Express editions are not meant to build redistributable binaries. They're meant for personal use: i.e. -- each user compiles his own code. I'm pretty sure it's a violation of the Express edition license agreement to build binaries for other people. You need at least the Standard edition of VS to get that capability. HTH, David On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James thanks for the links. Now my head is really spinning. I have VC2008 Express installed on WinXP SP3 and evidently the vcredist.exe is NOT included with that version? At least I can not find it. So I guess I have to download it from MSDN (duh) and then manually set all the paths and all that in oder to have cmake/NSIS find and include it in the installer. And I thought deploying on OS X was a bit obtuse... Mike ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
Thanks for the info That's what I get for expressing what I think are facts from my flawed human memory. (Perhaps it was a fact with Express 2005 editions when I first read the licenses long ago...) Sorry for the blip, David On Thu, Aug 20, 2009 at 5:40 PM, j s j.s4...@gmail.com wrote: I don't believe that to be the case with Visual Express 2008. I don't know how previous editions work. ** *Can I use Express Editions for commercial use?* 1. Yes, there are no licensing restrictions for applications built using Visual Studio Express Editions. http://www.microsoft.com/express/support/faq/ Juan On Thu, Aug 20, 2009 at 4:33 PM, David Cole david.c...@kitware.comwrote: Hold on there... The Express editions are not meant to build redistributable binaries. They're meant for personal use: i.e. -- each user compiles his own code. I'm pretty sure it's a violation of the Express edition license agreement to build binaries for other people. You need at least the Standard edition of VS to get that capability. HTH, David On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James thanks for the links. Now my head is really spinning. I have VC2008 Express installed on WinXP SP3 and evidently the vcredist.exe is NOT included with that version? At least I can not find it. So I guess I have to download it from MSDN (duh) and then manually set all the paths and all that in oder to have cmake/NSIS find and include it in the installer. And I thought deploying on OS X was a bit obtuse... Mike ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
So I created the proper paths within the VCExpress installation and placed the downloaded vcredist_x86.exe file in there. CMake found it. NSIS found it and included it. I ran my new installer on a clean XP SP3 machine. Verified the vcredist.exe actually ran also. Tried to launch an application and I still get an error that says the application is not configured correctly. Still lost and Confused. Mike On Thu, Aug 20, 2009 at 5:40 PM, j sj.s4...@gmail.com wrote: I don't believe that to be the case with Visual Express 2008. I don't know how previous editions work. Can I use Express Editions for commercial use? Yes, there are no licensing restrictions for applications built using Visual Studio Express Editions. http://www.microsoft.com/express/support/faq/ Juan On Thu, Aug 20, 2009 at 4:33 PM, David Cole david.c...@kitware.com wrote: Hold on there... The Express editions are not meant to build redistributable binaries. They're meant for personal use: i.e. -- each user compiles his own code. I'm pretty sure it's a violation of the Express edition license agreement to build binaries for other people. You need at least the Standard edition of VS to get that capability. HTH, David On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James thanks for the links. Now my head is really spinning. I have VC2008 Express installed on WinXP SP3 and evidently the vcredist.exe is NOT included with that version? At least I can not find it. So I guess I have to download it from MSDN (duh) and then manually set all the paths and all that in oder to have cmake/NSIS find and include it in the installer. And I thought deploying on OS X was a bit obtuse... Mike ___ ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe:
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
Did you try the dependency walker (available via google) to see if there may be any dll's you need to have in the same directory as the binary? Regards, Juan On Thu, Aug 20, 2009 at 5:03 PM, Mike Jackson mike.jack...@bluequartz.netwrote: So I created the proper paths within the VCExpress installation and placed the downloaded vcredist_x86.exe file in there. CMake found it. NSIS found it and included it. I ran my new installer on a clean XP SP3 machine. Verified the vcredist.exe actually ran also. Tried to launch an application and I still get an error that says the application is not configured correctly. Still lost and Confused. Mike On Thu, Aug 20, 2009 at 5:40 PM, j sj.s4...@gmail.com wrote: I don't believe that to be the case with Visual Express 2008. I don't know how previous editions work. Can I use Express Editions for commercial use? Yes, there are no licensing restrictions for applications built using Visual Studio Express Editions. http://www.microsoft.com/express/support/faq/ Juan On Thu, Aug 20, 2009 at 4:33 PM, David Cole david.c...@kitware.com wrote: Hold on there... The Express editions are not meant to build redistributable binaries. They're meant for personal use: i.e. -- each user compiles his own code. I'm pretty sure it's a violation of the Express edition license agreement to build binaries for other people. You need at least the Standard edition of VS to get that capability. HTH, David On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to get around this issue? I would really like a solution that did NOT involve editing anything from VC++ install as I would have to pass those instructions on to the next Developer. Clinton's posting about including the VCRedist.exe in the NSIS installer is OK by me. Is that what everyone else is doing? Thanks -- Mike Jackson I ended up linking against the static CRT library (/MT), but that's not for everyone. http://msdn.microsoft.com/en-us/library/ms235460.aspx My next choice was going to be including the VCRedist.exe in the installer. For some of the other projects at my company, this is what they do. Here are some links I've been consulting on the subject of CRT library (conflicts with multiple CRTs). http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/ http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest James thanks for the links. Now my head is really spinning. I have VC2008 Express installed on WinXP SP3 and evidently the vcredist.exe is NOT included with that version? At least I can not find it. So I guess I have to download it from MSDN (duh) and then manually set all the paths and all that in oder to have cmake/NSIS find and include it in the installer. And I thought deploying on OS X was a bit
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
Yep. First thing I have tried, and have been using all day. I think I may have tracked part of the problem down to a few things. 1: vcredist_x86.exe - There are multiple versions of this (all with the same file name). You have to make sure you download the correct version. I have VCExpress 2008 SP1. I was downloading the one for VCExpress 2008. 2: I think I have ITK built as Debug and I am trying a Release build of my main application suite. We all know that Debug and Release builds in Windows-Land do not get along. Boost may be another unknown (bjam.. yeech..). Far as I know I told bjam to use a dynamically linked c runtime. Expat, HDF5, Tiff all are built as static libraries using CMake so the default there is to use a dynamic linked c runtime. So I think those libraries are OK. My own intermediate library (MXADataModel) is also built as a static library and using CMake. So should be the same as Expat, HDF5 and Tif from above. Does not seem to be a redistributable package for the Debug versions of the C/C++ runtime libs. Bummer. Qt 4.5.1 is built as DLL's so I am hoping that will not hinder me as everything else is built as Static libraries (to try and avoid DLL hell .. ) ITK is currently rebuilding which will take another hour or so. I'll report back when that is complete maybe with some good _ Mike Jackson mike.jack...@bluequartz.net On Thu, Aug 20, 2009 at 6:57 PM, j sj.s4...@gmail.com wrote: Did you try the dependency walker (available via google) to see if there may be any dll's you need to have in the same directory as the binary? Regards, Juan On Thu, Aug 20, 2009 at 5:03 PM, Mike Jackson mike.jack...@bluequartz.net wrote: So I created the proper paths within the VCExpress installation and placed the downloaded vcredist_x86.exe file in there. CMake found it. NSIS found it and included it. I ran my new installer on a clean XP SP3 machine. Verified the vcredist.exe actually ran also. Tried to launch an application and I still get an error that says the application is not configured correctly. Still lost and Confused. Mike On Thu, Aug 20, 2009 at 5:40 PM, j sj.s4...@gmail.com wrote: I don't believe that to be the case with Visual Express 2008. I don't know how previous editions work. Can I use Express Editions for commercial use? Yes, there are no licensing restrictions for applications built using Visual Studio Express Editions. http://www.microsoft.com/express/support/faq/ Juan On Thu, Aug 20, 2009 at 4:33 PM, David Cole david.c...@kitware.com wrote: Hold on there... The Express editions are not meant to build redistributable binaries. They're meant for personal use: i.e. -- each user compiles his own code. I'm pretty sure it's a violation of the Express edition license agreement to build binaries for other people. You need at least the Standard edition of VS to get that capability. HTH, David On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 20, 2009 at 4:06 PM, James Biglerjamesbig...@gmail.com wrote: On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson mike.jack...@bluequartz.net wrote: On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwellmar...@cryos.org wrote: James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus Ok, so I too have run into this problem. What is anyone doing to
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
OK. Turns out it was ITK being compiled in Debug mode and then trying
to link against it with a Release build.
On to some comments that might help others:
VCExpress 2008 SP1 does NOT come with VCRedist_x86.exe. You will need
to download the correct version.
VCExpress 2008:
http://www.microsoft.com/downloads/details.aspx?FamilyID=D5692CE4-ADAD-4000-ABFE-64628A267EF0displaylang=en
VCExpress 2008 SP1:
http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2displaylang=en
Double and Triple check that all your projects and sub projects have
all been compiled the same way (Debug vs Release) and all with the
same settings for the c/c++ runtime libraries.
In order to re-use Clinton's code I had to create a few directories:
C:\Program Files\Microsoft Visual Studio
9.0\SDK\v3.5\BootStrapper\Packages\vcredist_x86
needs to be created (so that it matches the VS2005 paths).
Next I created a Macro:
macro(_FIND_MSVC_REDIST VCVERS)
message(STATUS Looking for MSVC Redistributable Executable for MSVC
Version ${VCVERS})
set(SDKVERS 2.0)
if(${VCVERS} EQUAL 8)
set(SDKVERS 2.0)
endif()
if(${VCVERS} EQUAL 9)
set(SDKVERS 3.5)
endif()
IF(MSVC${VCVERS}0)
FIND_PROGRAM(MSVC_REDIST NAMES
vcredist_${CMAKE_MSVC_ARCH}/vcredist_${CMAKE_MSVC_ARCH}.exe
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VCExpress\\${VCVERS}.0;InstallDir]/../../SDK/v${SDKVERS}/BootStrapper/Packages/
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\${VCVERS}.0;InstallDir]/../../SDK/v${SDKVERS}/BootStrapper/Packages/
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\${VCVERS}.0;InstallDir]/../../SDK/v${SDKVERS}/BootStrapper/Packages/
)
GET_FILENAME_COMPONENT(vcredist_name ${MSVC_REDIST} NAME)
INSTALL(PROGRAMS ${MSVC_REDIST} COMPONENT SupportFiles DESTINATION bin)
SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ExecWait
'\\\$INSTDIRbin${vcredist_name}\\\')
message(STATUS MSVC_REDIST: ${MSVC_REDIST})
ENDIF(MSVC${VCVERS}0)
endmacro()
The have the following:
if(MSVC80)
_FIND_MSVC_REDIST(8)
endif()
if(MSVC90)
_FIND_MSVC_REDIST(9)
endif()
I would like to add sometime in the future the correct command to run
the vcredist silently during the installation.
I think that is all. I would also like to thank everyone here for
their patience with me today. Also like to put in a word to the
VirtualBox guys at Sun. The make really nice FREE virtual machine
which allowed the quick testing of the installer on a Clean Windows
XP SP3 install. Thanks
_
Mike Jackson mike.jack...@bluequartz.net
On Thu, Aug 20, 2009 at 7:05 PM, Mike
Jacksonmike.jack...@bluequartz.net wrote:
Yep. First thing I have tried, and have been using all day. I think I
may have tracked part of the problem down to a few things.
1: vcredist_x86.exe - There are multiple versions of this (all with
the same file name). You have to make sure you download the correct
version. I have VCExpress 2008 SP1. I was downloading the one for
VCExpress 2008.
2: I think I have ITK built as Debug and I am trying a Release build
of my main application suite. We all know that Debug and Release
builds in Windows-Land do not get along.
Boost may be another unknown (bjam.. yeech..). Far as I know I told
bjam to use a dynamically linked c runtime.
Expat, HDF5, Tiff all are built as static libraries using CMake so the
default there is to use a dynamic linked c runtime. So I think those
libraries are OK.
My own intermediate library (MXADataModel) is also built as a static
library and using CMake. So should be the same as Expat, HDF5 and Tif
from above.
Does not seem to be a redistributable package for the Debug versions
of the C/C++ runtime libs. Bummer.
Qt 4.5.1 is built as DLL's so I am hoping that will not hinder me as
everything else is built as Static libraries (to try and avoid DLL
hell .. )
ITK is currently rebuilding which will take another hour or so. I'll
report back when that is complete maybe with some good
_
Mike Jackson mike.jack...@bluequartz.net
On Thu, Aug 20, 2009 at 6:57 PM, j sj.s4...@gmail.com wrote:
Did you try the dependency walker (available via google) to see if there may
be any dll's you need to have in the same directory as the binary?
Regards,
Juan
On Thu, Aug 20, 2009 at 5:03 PM, Mike Jackson mike.jack...@bluequartz.net
wrote:
So I created the proper paths within the VCExpress installation and
placed the downloaded vcredist_x86.exe file in there. CMake found it.
NSIS found it and included it. I ran my new installer on a clean XP
SP3 machine. Verified the vcredist.exe actually ran also. Tried to
launch an application and I still get an error that says the
application is not configured correctly.
Still lost and Confused.
Mike
On Thu, Aug 20, 2009 at 5:40 PM, j
[CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
I've just been bitten hard by this issue (many hours of frustration while attempting to run a demo application that should have Just Worked (TM) ). According to this page: http://support.microsoft.com/kb/326922 You should install these versions of the CRT on target computers by running the Vcredist_x86.exe application that is included with Visual Studio. This is for the VS 2005 and 2008 versions of the C run-time libraries except for Windows 2000 in which case you need to install them in the system32 directory. I was dropping Msvcr80.dll and friends as per InstallRequiredSystemLibraries next to the binaries with ineffectual results. It was really strange, because programs like Dependency Walker seemed to find them just fine. It was only after running vcredist_x86.exe that I was able to run my programs properly. I though I should tell everyone that this method of distributing Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to work. You must install them into the Windows Side by Side location (WinSxS) using the CRT.msm merge module or the vcredist_x86.exe that comes with Visual Studio. Now to try and get CPack to tell NSIS run the vcredist_x86.exe program during installation. Note, that many people might get lucky and have already installed a product that installed the right vcredist_x86.exe before installing your software. James ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
James Bigler wrote: I've just been bitten hard by this issue (many hours of frustration while attempting to run a demo application that should have Just Worked (TM) ). According to this page: http://support.microsoft.com/kb/326922 You should install these versions of the CRT on target computers by running the Vcredist_x86.exe application that is included with Visual Studio. This is for the VS 2005 and 2008 versions of the C run-time libraries except for Windows 2000 in which case you need to install them in the system32 directory. I was dropping Msvcr80.dll and friends as per InstallRequiredSystemLibraries next to the binaries with ineffectual results. It was really strange, because programs like Dependency Walker seemed to find them just fine. It was only after running vcredist_x86.exe that I was able to run my programs properly. I though I should tell everyone that this method of distributing Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to work. You must install them into the Windows Side by Side location (WinSxS) using the CRT.msm merge module or the vcredist_x86.exe that comes with Visual Studio. Now to try and get CPack to tell NSIS run the vcredist_x86.exe program during installation. Note, that many people might get lucky and have already installed a product that installed the right vcredist_x86.exe before installing your software. No this works fine However you may be running into this issue: Visual Studio 9 SP 1 has a bug that will cause trouble with cpack. You can read about it here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682 Basically, when you compile an executable or dll with VS9 SP1 it embeds manifest information into the the exe or dll that does not match the version information in the manifest files that SP 1 provides for redistribution. We use the InstallRequiredSystemLibraries all the time without requiring vcredist_x86.exe to be run. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
On Thu, Aug 6, 2009 at 11:55 AM, Bill Hoffman bill.hoff...@kitware.comwrote: James Bigler wrote: I've just been bitten hard by this issue (many hours of frustration while attempting to run a demo application that should have Just Worked (TM) ). According to this page: http://support.microsoft.com/kb/326922 You should install these versions of the CRT on target computers by running the Vcredist_x86.exe application that is included with Visual Studio. This is for the VS 2005 and 2008 versions of the C run-time libraries except for Windows 2000 in which case you need to install them in the system32 directory. I was dropping Msvcr80.dll and friends as per InstallRequiredSystemLibraries next to the binaries with ineffectual results. It was really strange, because programs like Dependency Walker seemed to find them just fine. It was only after running vcredist_x86.exe that I was able to run my programs properly. I though I should tell everyone that this method of distributing Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to work. You must install them into the Windows Side by Side location (WinSxS) using the CRT.msm merge module or the vcredist_x86.exe that comes with Visual Studio. Now to try and get CPack to tell NSIS run the vcredist_x86.exe program during installation. Note, that many people might get lucky and have already installed a product that installed the right vcredist_x86.exe before installing your software. No this works fine However you may be running into this issue: Visual Studio 9 SP 1 has a bug that will cause trouble with cpack. You can read about it here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682 Basically, when you compile an executable or dll with VS9 SP1 it embeds manifest information into the the exe or dll that does not match the version information in the manifest files that SP 1 provides for redistribution. We use the InstallRequiredSystemLibraries all the time without requiring vcredist_x86.exe to be run. -Bill Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. James ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
Bill Hoffman wrote:
James Bigler wrote:
I've just been bitten hard by this issue (many hours of frustration
while attempting to run a demo application that should have Just
Worked (TM) ).
According to this page:
http://support.microsoft.com/kb/326922
You should install these versions of the CRT on target computers by
running the Vcredist_x86.exe application that is included with Visual
Studio. This is for the VS 2005 and 2008 versions of the C run-time
libraries except for Windows 2000 in which case you need to install
them in the system32 directory.
I was dropping Msvcr80.dll and friends as per
InstallRequiredSystemLibraries next to the binaries with ineffectual
results. It was really strange, because programs like Dependency
Walker seemed to find them just fine. It was only after running
vcredist_x86.exe that I was able to run my programs properly.
I though I should tell everyone that this method of distributing
Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to
work. You must install them into the Windows Side by Side location
(WinSxS) using the CRT.msm merge module or the vcredist_x86.exe that
comes with Visual Studio.
Now to try and get CPack to tell NSIS run the vcredist_x86.exe
program during installation.
Note, that many people might get lucky and have already installed a
product that installed the right vcredist_x86.exe before installing
your software.
No this works fine However you may be running into this issue:
Visual Studio 9 SP 1 has a bug that will cause trouble with cpack.
You can read about it here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682
Basically, when you compile an executable or dll with VS9 SP1 it embeds
manifest information into the the exe or dll that does not match the
version information in the manifest files that SP 1 provides for
redistribution.
We use the InstallRequiredSystemLibraries all the time without
requiring vcredist_x86.exe to be run.
There are some cases it doesn't work (3rd party libraries you can't
compile yourself).
I don't have two installs of the same Visual Studio versions with
different service packs, so, here's what I do.
IF(MSVC80)
FIND_PROGRAM(MSVC_REDIST NAMES
vcredist_${CMAKE_MSVC_ARCH}/vcredist_${CMAKE_MSVC_ARCH}.exe
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../SDK/v2.0/BootStrapper/Packages/
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../SDK/v2.0/BootStrapper/Packages/
)
GET_FILENAME_COMPONENT(vcredist_name ${MSVC_REDIST} NAME)
INSTALL(PROGRAMS ${MSVC_REDIST} COMPONENT Runtime DESTINATION bin)
SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS ExecWait
'\\\$INSTDIRbin${vcredist_name}\\\')
ENDIF(MSVC80)
Clint
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
James Bigler wrote: I've just been bitten hard by this issue (many hours of frustration while attempting to run a demo application that should have Just Worked (TM) ). According to this page: http://support.microsoft.com/kb/326922 You should install these versions of the CRT on target computers by running the Vcredist_x86.exe application that is included with Visual Studio. This is for the VS 2005 and 2008 versions of the C run-time libraries except for Windows 2000 in which case you need to install them in the system32 directory. I hit this with Avogadro development, and at the time from my searching it appeared that this is due to the version numbers being incorrect in the manifest that MS distributes with the DLLs in question. By editing the manifest for the DLLs they would load as expected on XP and Vista hosts. This seems to work, and so I edited the manifest in the redistributable folder and we have been using that ever since. I was dropping Msvcr80.dll and friends as per InstallRequiredSystemLibraries next to the binaries with ineffectual results. It was really strange, because programs like Dependency Walker seemed to find them just fine. It was only after running vcredist_x86.exe that I was able to run my programs properly. I am sure there are people on this list who know better than I, but I think this is because the version number in the manifest MS supplies with the redistributable DLLs is incorrect. Changing this version fixed it for me, but did feel a little hackish. I would be interested in what the best practice is. Currently we can run our application from a flash drive without installing on a clean system, which is a feature I would also like to retain. I though I should tell everyone that this method of distributing Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to work. You must install them into the Windows Side by Side location (WinSxS) using the CRT.msm merge module or the vcredist_x86.exe that comes with Visual Studio. Now to try and get CPack to tell NSIS run the vcredist_x86.exe program during installation. Note, that many people might get lucky and have already installed a product that installed the right vcredist_x86.exe before installing your software. I would be interested in how others have solved this issue. I like our current solution and I think several Kitware projects use a similar mechanism. Marcus ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.comwrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. Thanks, James ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++
James Bigler wrote: On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman bill.hoff...@kitware.com mailto:bill.hoff...@kitware.com wrote: James Bigler wrote: Well, I was using VS 2005 64 bit with SP 1. I wonder if there is a similar bug or if there is something else going wrong such as what Marcus Hanwall described. I am not sure what your issue is, but I know I have done this many times... -Bill I checked the version numbers of the DLLs, and even checked the md5sum and everything was the same between the dlls in the WinSxS folder and the ones I'm distributing. It failed on two clean systems without the vcredist install. I guess I'll run vcredist as Microsoft suggests and see if I can trouble shoot later. It is a rather perplexing problem. The link Bill supplied has all of the relevant information. In the Community Discussion section the second comment provides three possible workarounds. We are using the third of those when distributing Avogadro packages for Windows. The version mismatch in the manifests of the compiled executables and the manifest with the redistributable DLLs is what causes the issue. It seems that MS has no intention of fixing this issue. We have a clean VM where we test new installers, as occasionally this change was lost and the DLLs failed to load. Marcus ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
