I upgraded my Windows RT 8.0 project to target Windows RT 8.1 project in Visual Studio 2013, and now it gives me following linking error:
error LNK2038: mismatch detected for 'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value '1' doesn't match value '0' in MSVCRT.lib(appinit.obj)
Any ideas what's this error about?
I solved this problem after upgrade to 8.1
My project structure was (example):
project.vcxproj (Consume Windows Runtime Extension: No)
file1.cpp
file2.cpp
application.cpp (Individual file settings: Consume Windows Runtime Extension: Yes)
So after upgrade from 8.0 to 8.1 in VS2013 I got such error LNK2038
And my solved project structure is:
project.vcxproj (Consume Windows Runtime Extension: Yes)
application.cpp
static_lib.vcxproj (Consume Windows Runtime Extension: No)
file1.cpp
file2.cpp
So project with global enabled runtime extension and static library without runtime extension links without such errors.
Related
I'm using Visual Studio 2019 and trying to compile a program that was compatible with Windows XP 32-bit.
When I first ran my .exe on my VM it said that it wasn't compatible with Win32.
I've then changed the Platform Toolset to Visual Studio 2017 - Windows XP (v141_xp).
Now it says I'm missing a VCRUNTIME140d.dll, and following instructions that said to change my Runtime Library to /MT I get the error stated in the title.
Any suggestions would be very much appreciated.
VCRUNTIME140d.dll is Visual C++ Redistributable for Visual Studio 2015.You need to download and install. And this is Debug versions of DLL. You must compile in Release mode.
I have a c++ application built in Visual studio 2015, It seems c++ apps have need visual c++ 2015 (In my case) to be installed (on targeted windows version). Then i decided to convert my c++ source to c and use CLion 2018 for build this project. It has no error but the output executable has visual c++ 2015 (It says: vcruntime140.dll is missing) dependency again. Here is my questions:
Does C written executable's have any external dependencies ? What are those dependencies ?
Im new to CLion2018, How to build c projects to work without dependency on all windows versions and architectures ?
Is still any way to use VS2015 to create and build c projects ? (Already tried changing compile as: option to /TC and changing extensions to .c. Build was successful but Output has VCRUNTIME140.dll error).
Note1: Both output files (In CLion and VS) are working on windows 7,8.1,10 with visual c++ 2015 installed. And both have "VCRUNTIME140.dll is missing" error on raw windows 7,8.1,10 without visual c++ 2015 installed.
Note2: Don't want to pack those dll's with my file, Or installing vc++ 2015.
I was wondering if anyone was able to successfully create Installer Project for a 64-bit WinForms application on VS2015.
When I try to compile the installer project for simple 64-bit WinForms project that only displays a message box, I get the following:
ERROR: File 'WindowsFormsApplication2.exe' of project output 'Primary
output from WindowsFormsApplication2 (Debug x64)' targeting 'AMD64' is
not compatible with the project's target platform 'x86'
And when opening the installer project properties I don't find any option for changing the installer project to x64.
Edit:
I already tried the project properties:
However while the link provided in Cody Gray's comment is for VS2010, it suggests that "Creating 64-bit MSI packages is not available in Visual Studio Express Edition.
"
And I'm using VS2015 community which is free. Could that be the problem?
I was working with visual studio 2012 beta and my desktop (win32) program compiled fine in ARM architecture.
After upgrading to visual studio 2012 RC, the compiler would not work and spews out the following error:
"Compiling Desktop applications for the ARM platform is not supported"
I found a forum post on this
http://connect.microsoft.com/VisualStudio/feedback/details/745580/arm-configuration-doesnt-work
Is it correct that Microsoft is really cutting off win32 development on ARM?
And that compiling in VS2012 beta was just a fluke?
You can edit the file:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\ARM\Microsoft.Cpp.ARM.Common.props
In the <PropertyGroup> section add the line:
<WindowsSDKDesktopARMSupport>true</WindowsSDKDesktopARMSupport>
before </PropertyGroup>
And that's all, you can build ARM desktop apps with VS2012.
I was able to get around that error and compile a little "hello world" cpp file for ARM by adding the "/D _ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE" command-line argument to the ARM version of cl at C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm. I found that #define from sn0w's answer on this question in the crtdefs.h file, without having to modify that file. Now, I can't guarantee that anything more complex will actually work, or that Microsoft hasn't instituted some sort of whitelisting or digital signature verification for Windows RT desktop apps, so even though it may compile, it may not be allowed to run when Windows RT is finally available.
Note that before you can run the ARM version of cl.exe from the command line, you must set the environment variables using this batch file: "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm\vcvarsx86_arm.bat"
Even if you compile the app, you won't be able to run it on Windows 8 RT as unsigned apps will not start.
I just tested this, and unfortunately it is the case.
You receive the following message:
Windows cannot verify the digital signature of this file
I imagine there is probably a work around for this, but it will never be officially supported.
yes of course. i practised with VS2012 RC.
now i'll explain how to avoid "Compiling Desktop applications for the ARM platform is not supported" and build win32 application.
1st way: fix build tools - the goal is to patch (or try to substitute it with beta's one) MSBuild's lib: Microsoft.Build.CPPTasks.Common.v110.dll
2nd way: run the "VS2012 ARM Cross Tools Command Prompt" from Visual Studio Tools start menu, then execute cl [cl params] myfile1.cpp myfile2.cpp myres.res ... /link [linkparams]
for both this cases you also need to commentout an #error directive in crtdefs.h on line 332. (Microsoft Visual Studio 11.0\VC\include)
Error message:
fatal error: sal.h: No such file or directory cstudy line 11, external
location: C:\Program Files\Microsoft
SDKs\Windows\v7.0A\Include\specstrings.h C/C++ Problem.
But when I add VC/include to this project,I received a ton of error messages. It seems VC/include/sal.h is not a standard header file for GCC.
The source code is very simple:
#include "windows.h"
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
return 0;
}
Environment:
Windows 7.0A SDK
VC 2010
MINGW
CDT/ECLIPSE.
Thanks.
No, the sal.h header is not part of GCC / MinGW, however you can add your VC/include/ as an include directory to eclipse.
alternative: move all (!) requried headers to your mingw or project include directory. The one from MinGw is: <mingw path>/include).
Anyway. sal.h, if you install the Windows SDK then it isn't going to
be in the SDK directory, but you should find that if you select to
install the compiler and tools it will get installed along with that.
This is because sal.h is needed in the CRT headers as well as the
Windows headers. So you NEED to install the VS compilers and tools
along with the SDK. You will then find that the compiler will be
installed by default under %ProgramFiles%\Microsoft Visual Studio
2010\VC and sal.h will be in include under that path. On 64 bit
systems it will be under %ProgramFiles(x86)% by default.
source: http://social.msdn.microsoft.com/Forums/eu/windowssdk/thread/0e166050-99f1-436b-bd94-b39e2910f43d
See:
can't find sal.h (!)
Windows SDK header files question
I just ran into this problem. I can't seem to get the sal.h header file through the MS Windows version of mingw, but "yum whatprovides \*/sal.h" on my Fedora Core 18 machine brought up the mingw-headers package. I downloaded the source package (i.e. yumdownloader --source mingw-headers), opened up the .tar.gz file in file-roller, grabbed the sal.h file, and put it in /c/MinGW/include on my MS Windows machine.
The same package had dsound.h, which was the next missing header file.
I've never tried to use mingw under Fedora Core to cross-compile MS Windows apps, but maybe it's time... :-)