i've read several topics on this issue... but i'm not still able to figure out.
I've matlab 2013 and "MS Visual C++ 2012 Redistributable" both x86/x64 installed in Windows 8.
When i run "mex -setup" in matlab the following message appear:
Please choose your compiler for building MEX-files:
Would you like mex to locate installed compilers [y]/n? y
No supported SDK or compiler was found on this computer.
For a list of supported compilers, see
http://www.mathworks.com/support/compilers/R2013a/win64.html
but the suggested file is for installing .NET 4 for windows 7, and i've windows 8. However, although i install this framework the mex -setup command still doesn't works.
It seems to still be an issue with no straightforward solution. It took me a lot of searching, reading and trial and error to get a compiler to be recognized by mex.
In a nutshell, matlab 2013 doesn't support windows 8 SDK, but windows 7 SDK does not (easily) install on windows 8.
What worked for me:
The win7 SDK doesn't install on windows 8 because more recent versions of the Visual C++ 2010 Redistributable are already installed by default on Windows 8. You have to manually (from the control panel/programs/uninstal ...) uninstall all flavors of VC++2010 redistributable (x86 and x64).
See this Microsoft article for details on how to do that.
After that I could install the SDK for win7 and got the compiler to be recognized by mex.
Note:
I run on win8 32 bits, so what worked for me may not be perfect for everybody. During my searches on the subject i also noticed that many people often stumbled on 2 other setbacks:
During the setup of win 7 SDK, .NET 4 doesn't install. => This is because .net4.5 is already shipped in windows 8. Again, uninstall .net4.5, then reinstall win7 SDK. (you can even reinstall .net4.5 if necessary after everything is done).
Once everything is installed and mex happily found the compiler, error are raised during compilation tentative about a missing ammintrin.h. You may have to install MS Visual Studio C++ 2010 express then upgrade it to SP1. In this case follow the nicely detailed instructions in this Matlab central article.
This last article linked seem to offer a complete solution, i didn't refer to it first in my answer because in some case (my case for example), only part of the setup described was necessary, so there was no point uninstalling/reinstalling a bunch of stuff. But be prepared that you may have to go though all of it ...
Related
I downloaded driver which targets Windows 7 (has option "TargetVersion" == "Windows 7" in ".vcxproj"). Also I installed Visual Studio 2022 Community, the latest SDK and DDK (for Windows 11) to compile it.
When I press "Build solution", I get error:
Windows7 is not a supported OS Version
I'm going to open file:
C:\Program Files (x86)\Windows Kits\10\build\10.0.22621.0\WindowsDriver.Common.targets
and comment the following line:
<Error Text=" '$(TargetVersion)' is not a supported OS Version"
Condition="'$(WindowsTargetPlatformVersion)' > '$(TargetPlatformVersion_CO)' and '$(TargetVersion)' !='$(LatestTargetVersion)' " />
Then trying to compile again.. and voila - everything works. Meaning driver works well for all operation systems up to Windows 10.
I do understand I'm doing wrong. So, my questions are:
Why don't Visual Studio developers let us build drivers for Windows 7 if everything works?
What is the correct way to build drivers for all operating systems, starting with Windows 7?
Added later:
I think maybe, for example, latest WDK has more API functions which are missing in Windows 7. It turns out that if we code carefully, checking all calls for compatibility, then there should be no problems with compilation.
Per this page:
To target Windows 8.1, Windows 8, and Windows 7, you will need to
install an older WDK and an older version of Visual Studio either on
the same machine or on a separate machine. For links to older kits,
see Other WDK downloads.
Question #1 - you better ask Microsoft.
Question #2 - you can install multiple SDK and WDK versions side by side. To target Windows 7, install Windows 8.1 SDK and WDK.
Preamble: I found a solution in the midst of writing this, and this problem was a PITA and had a convoluted solution. Thus, I feel compelled leave this here to help any poor soul who has this problem.
I'm new to MatLab, and I don't usually use Visual C++ either, so forgive me if this should be painfully obvious.
Short version: I have Visual C++ 2013 installed on my computer, but mex can't find it when I run mex -setup c++. I get the following:
>>mex -setup cxx
Error using mex
No supported compiler or SDK was found. You can install the freely available
MinGW-w64 C/C++ compiler; see Install MinGW-w64 Compiler. For more options, see
http://www.mathworks.com/support/compilers/R2015b/win64.html.
Here's the full situation.
OS: Windows 10 Home
Compiler: Visual Studio 2013 (v120, up-to-date)
I confirmed that I can compile and run a program using this toolset.
MatLab version: 2015b
I was originally running Visual Studio 2015, and mex found the compiler just fine. However, I soon found out that Simulink is not compatible with VS 2015, so I had to roll back to VS 2013, and this is when my problem started.
I've tried, among many others, the following sites to find a solution:
The MatLab mex documentation - No help, only shows basic mex usage.
The MatLab supported compiler list - Confirmed that VC++ 2013 is compatable.
Then I went down a rabbit hole.
A very protracted mathworks.com answer that suggested other links. This led me to...
Another mathworks.com answer which sounds like my problem, and suggests patching my setup. Turns out that I don't have SDK 7.1 installed. So, I went to install, and got this error:
Some components could not be installed. Some Windows SDK components require the RTM .NET Framework 4...
This Stack Overflow question asks about this issue, and I hit the exact same issue Danilo Gadêlha had in regards to the .NET Framework already being installed.
I tried the top answer, and after removing every single reference to .NET framework of any version I could find, including those under "Windows Features", I still couldn't install.
I tried the next option, and even in safe mode, RegEdit wouldn't let me change the values suggested by the next answer, so that was a bust.
Lastly, I tried MandM's solution, which finally solved my chain of problems.
I think this was the root of my problem: when I uninstalled Visual Studio 2015 and installed Visual Studio 2013, an installation or registry setting was left in an incorrect state, and mex was unable to find Visual Studio 2013 as a result.
The solution that worked for me:
Leave Visual Studio 2013 installed.
As MandM answered:
Uninstall the following:
"Microsoft Visual C++ 2010 x64 Redistributable"
"Microsoft Visual C++ 2010 x86 Redistributable"
Before installing the Windows 7.1 SDK, and the install package reinstalls those two during installation.
As Robert Važan points out in the comments:
If error message persists despite this workaround, just click OK and proceed with installation. The installation will succeed this time..
I did get this error, but the install worked fine.
Install the SDK 7.1 Patch, which fixes the issue highlighted on this mathworks.com answer.
I have ran into this problem trying to install several different python packages, and I can no longer work around this with alternate packages. I read through the other solutions, but none seem to be specific to my particular Python version and operating system.
I am running Python 3.4.3 64 bit on Windows 8.1 laptop. While install packages such as esutil and fitsio, I get the error: Unable to find vcvarsall.bat. This indicates it can't find Visual Studio 2010 C++ compiler. However I know Visual Studio Express does not have a 64 bit C++ compiler, so that solution does not work. With Visual Studio Express installed I then get ValueError: ['path']
Also, since this is a Windows 8 laptop I can't download the additional Visual Studio SDK 7.1 which is also suggested to alleviate the problem. What Microsoft Visual Studio 2010 software can I download for Windows 8 in order get a 64 bit C++ compiler?
Alternatively is there a work around using a different C++ compiler, such as mingw32. I tried mingw32 from a Cygwin installation, but that also fails, so I suspect I need a 64-bit mingw c++ compiler as well.
I have created an application using Qt 4.8.4, and now I have to distribute it on Windows 2000 machines, among the others. I have already tried searching over the Internet for a clear explanation about it, but I can't find a confirmation on what's the older Windows version actually supported by Qt.
The application runs fine on Windows XP (both 32 and 64 bit) and Windows 7 but, when I try to launch it on Windows 2000 I receive the well-known error "[Application name].exe is not a valid win32 application.", and I guess that the error relies on the unsupported Windows version.
The application is a "simple" one, it just need QtCore4.dll and QtGui4.dll as dependencies.
If it can help, I am developing on a Windows 7 64 bit machine, using Qt 4.8.4 and Qt Creator 2.7.1. If I go under Tools->Options->Build&Run->Kits->Manual->Desktop, I have "Microsoft Visual C++ Compiler 10.0 (x86)" as the compiler in use. Do I have to select a different one, maybe?
Thanks for any answer.
EDIT: What I've done after reading #vahancho's answer:
"Move" the project from Qt Creator to Visual Studio 2010, using CMake;
Install Visual Studio Express 2008 (enabling the V90 Platform Toolset, this way)
Open the project from VS2010, and go under Project Properties->Configuration Properties->General and change Platform Toolset to V90;
Recompile the project;
Now, I've tried to run the application compiled this way on a virtual machine, mounting Windows 2000, but I get another error, this time: "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll".
Well, after some investigations I found that running MSVC10 applications on Windows 2000 is not possible. You have to build it with at most MSVC9 (Visual Studio 2008), or use the VS2010 Multi Targetting feature to let VC++2010 use the VC++2008 compilers and libraries. Please also refer to this Microsoft Connect discussion.
OK, some time has passed, but I'd like to give a definitive answer to this question of mine. Unfortunately, what I was asking for it's not possible. #vahancho's answer is right, and the solution he pointed out is correct for the majority of situations. However, DecodePointer is "included" in Windows XP SP 2 kernel, and it's not possible to compile an application using it for an older Microsoft OS, even by choosing the VC++2008 compiler.
An additional reference is given by this post on CodeProject.
Fortunately for me, my application was simple enough to let me rewrite it using the good old VB6 :)
I installed VS 2012 Professional and the XP update as well. I built my project with v110_xp as the platform toolset on VS 2012. My project's .msi package is installing fine on Win 7 but failing on Win XP SP3. The error reported on XP SP3 is -
"The procedure entry point FlushProcessWriteBuffers could not be
located in the dynamic link library Kernel32.dll".
While the same project built from VS 2005 is installing fine on XP SP3. I am not sure what is going on VS 2012. _WIN32_WINNT is set to 0x0501. Can some one please guide as how to resolve the problem ?
Any help is highly appreciated,
Mahesh.
Yes, the C Runtime has a dependency on FlushProcessWriteBuffers(). The updated version of msvcrt110.dll and libcmtl.lib, the ones you got along with the update, no longer directly link to the function, they use GetProcAddress() to find it and limp along if it is missng. So you should never get this error.
So very high odds that you deployed the wrong version of msvcrt110.dll, an old one instead of the updated one. You can find it back in c:\windows\system32, look at the properties. Mine is version 11.00.51106.1, dated 11/5/2012. A separate installer is available for it here.
The VS2012 runtime that you are installing uses functions that are not present available in XP. See this MS article: Targeting Windows XP with C++ in Visual Studio 2012 which explains more and provides some workarounds.
Update 1 for VS2012 resolve the problem.
But Update 1 isn’t just about new Windows platforms. It also enables you to target Windows XP with native C++ applications in Visual Studio 2012.
If you are building with update 1 and still encountering problems then I suspect that you are installing an out of date runtime. You need to deploy the runtime delivered with update 1.
You can solve this by including the VC11 merge modules from your development machine(program files\common files\merge modules) in your installer. It's easier than having to run the redist exe in your installer.
If you use WIX: merge module addition
I've tested on server 03, xp64 and xp32.