Trying to move a MSVC2008 project to MSVC2017 - c++

I'm trying to move this project form VisualStudio 2008 to VisualStudio 2017. This project is a C++ project and when I try to compile it there are a lot of errors:
Errors are:
the source file can not be opened (E1696).
the global scope does not have... (E0282).
the identifier ... is not defined (E0020).
The solution file of the project is in the folder kex3_anubis/msvc/
The project is open source.
# EDIT
I have lowered the number of errors to 17, but there are 126 warnings. What I have done is to select Project -> redirect projects (2nd option of project menu) and select Windows SDK version to 10.0.15063.0. I don't know if this is a good step or is not part of the solution, because it's the first time that I'm trying to move a project from different versions of VS.
The new errors are:
The declaration of ... hides the previous local statement (C4456)
Warning treated as error; no generated 'object' file (C2220)
The other errors have disappeared.
# EDIT 2
For the moment I applied this solution found on other question:
Go to project properties -> configurations properties -> C/C++ ->
treats warning as error -> No (/WX-).
Now I only have one error.
can not open the file '...\openal\lib\ eaxguid.lib' from anubis project

instead of
#include "math.h"
use
#include <math.h>
In all the standard includes

Related

How to set the correct Intellisense configuration for include path in VS Code?

I am trying to work with Emscripten. I have the compiler set up and working and now I'd like to write some code.
However, the include for emscripten remains underlined in red and I can see this error:
#include <emscripten/emscripten.h>
#include errors detected. Please update your includePath. Squiggles are disabled for this translation unit (D:\MYPROJECT\cpp\main.cpp).C/C++(1696)
cannot open source file "emscripten/emscripten.h"C/C++(1696)
A "Quick fix" (quotes intended) takes me to the Microsoft C/C++ Extension - IntelliSense Configurations. And there I can edit include paths. I have created a new configuration named EMSCRIPTEN and set these paths:
${workspaceFolder}/cpp/**
D:\lib\emsdk\upstream\emscripten\system\include
But this has no effect. Now if I do add this to the default configuration that was there from the start (Win32), it works. But I don't want to use that one for my emscripten project! I was kinda hoping to convince to IDE to compile my programs as well.
So how do I set per-workspace C++ compiler settings to a given configuration?
Ok, I found it, it's to the right bottom of the screen next to language type selection:

error C2855: command-line option '-Zc:__cplusplus' and '-Zc:referenceBinding' inconsistent with precompiled header

We have a Qt project on VS. We are using PCH files. From October 11 compilator started to show errors:
c:\work\repos\... : error C2855: command-line option '/Zc:__cplusplus' inconsistent with precompiled header
1>c:\work\repos\... : error C2855: command-line option '/Zc:referenceBinding' inconsistent with precompiled header
Removing '/Zc:__cplusplus' and /Zc:referenceBinding options from project configuration solve the issue, but I wanna keep them. Did anybody face such a problem?
Pushed the code back a year, can observe the same error (so it's not an impact) Why it stopped working?
OS Win10, Qt 5.14.1, VS 2017 (last updated version)
P.S. Did a small and simple test VS console projects, putting this '/Zc:__cplusplus' and /Zc:referenceBinding params and everything works fine

Error in VS 2017 for C language

I am trying to set up a project in visual studios for C but every time i do, i first get this error message
fatal error C1010: unexpected end of file while looking for precompiled header. Did you forget to add '#include "stdafx.h"' to your source?
then when i fix it by going into the "Properties->Precompiled header" i get this message
error LNK2005: _main already defined in clang.obj
. This has been going on for days now and i watched a bunch of videos and read a bunch of articles on this and I can't seem to find a fix. I just want to run my C program and have it execute without dealing with errors like those above. Here is what i do to set it up,
Create new project -> Select "Windows console application" -> change the "Location" to a file directory on my desktop -> then go to "Project" and "Add new item" -> i name that item "name.c" and when I am done, I insert my code and run it then i receive the same errors. Can someone please help me.
I think the problem is that when you choose Windows console application template, VS 2017 already generated a file which has a int main() function defined in it.
Then you added another file name.c which also has a main() function. Thus you got that error.

C++ Error RC2104 trying to compile PuTTY-PSCP (for Windows) on Visual Studio 6.0

I was about to use PuTTY Development source code for Windows to create my own client application (found here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) but as I tried to compile the PSCP project (SCP Client), I got the following error :
C:\work\2015\Putty\windows\version.rc2 (18): error RC2104 : undefined
keyword or key name: BINARY_VERSION
I've been going through the various posts involving this error but didn't find anything working :
error RC2104: undefined keyword or key name: DS_SETFONT :
On this post I noticed that the version of MSVC was brought up so I figured maybe something has to be done to get PuTTY to work on VC 6.0 ?
Also I tried to add #include <windows.h> in both version.rc2 (version.rc2 is used for inclusion in all .rc files) and pscp.rc, none worked.
I'll be quick to answer if you need any information (project properties, source code...)
USING Visual Studio 6.0 with SP6 on Windows 8.1
Probably, wrong version.h is seen.
Correctly, the file version.h in the project folder should be seen.
Please try to modify version.rc2:
#include "version.h"
to
#include "..\\..\\..\\version.h"
At least, resource compiler will end successfully.
If you search through the PuTTY source files, you'll notice that BINARY_VERSION is defined in version.h and used in windows/version.rc2, which #includes version.h.
Since your version.rc2 isn't seeing version.h, try to figure out why: Is version.h still present and does it still contain BINARY_VERSION? Are your include paths correct? Is there another version.h somewhere else in your include path that's getting picked up by mistake?
Which source code are you using ?
I tested latest(0.64) "Release source code for Windows".
direct link is
http://the.earth.li/~sgtatham/putty/latest/putty-src.zip
I had tried to compile using VC++ 6.0 Professional with SP6, on my PC,
running Windows XP SP3.
After extracting putty-src.zip to somewhere with keeping folder
structures, did you correctly opened 'putty.dsw' in "putty-src\windows\MSVC" folder?
You should be find in 7 projects in 'FileView' tab of the workspace
in Visual Studio 6.0.
You can switch active project to 'pscp' with context menu via
right button click on 'pscp' project.
With modified version.rc2, resource compiler finished successful.
But two (sshshare.c, winsftp.c) C source files failed compiling
with 20 errors. in 'pscp' project.
Errors while compiling 'winsftp.c' is caused 'TIME_POSIX_TO_WIN'
and 'TIME_WIN_TO_POSIX' macros.
'ull(unsigned long long)' is a 64-bit integer-suffix, newly defined in C99. Since C99 standard is not support on VC6, then caused errors.
I had temporally modified
11644473600ull ------> ((ULONGLONG)11644473600)
10000000ull ---------> ((ULONGLONG)10000000)
and confirmed errors are cleared. (Sorry, no validation the code is correctly generated)
3 errors while compiling 'sshshare.c' is also caused another macro.
I cannot understand why you got 116 errors.

Can not find mpirxx.h after building the mpir-2.6.0 library in vc++

I need to use mpir-2.6.0 library with visual c++ 2010. My code is going to be in c++.
I extracted both folders (mpir-2.6.0 and vsyasm-1.2.0-win32). Then, I copied the content of the folder vsyasm-1.2.0-win32 (including vsyasm.exe after renaming it to yasm.exe and placing it in: C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\. Then, I opened the project: mpir.sln which is placed in: \mpir-2.6.0\build.vc10. Then, I changed the Project configuration to: Release.
When I try to build the whole solution, I get a lot of errors such as:
error C1020: unexpected #endif c:\proj\mpir-2.6.0\mpir-2.6.0\mpir.h 4 1 lib_mpir_gc
error C1020: unexpected #endif c:\proj\mpir-2.6.0\mpir-2.6.0\mpir.h 4 1 lib_mpir_gc
error C1020: unexpected #endif c:\proj\mpir-2.6.0\mpir-2.6.0\mpir.h 4 1 lib_mpir_gc
But when I build every library separately, it is successful.
After the build, I went to: \mpir-2.6.0\build.vc10\Win32\Release
and find the files:
mpir.lib
mpirxx.lib
mpir.pdb
mpirxx.pdb
But I can not find the files:
mpir.h
mpirxx.h
Which I need to copy them the visual studio include file.
My main source for these configuration is: http://www.exploringbinary.com/how-to-install-and-run-gmp-on-windows-using-mpir/ (but this was for old versions for the library and the ysam). I do not understand the reasons for these errors. I was able to configure the library with old version. But I need to upgrade as there are improvements in the library and mine is very old one.
The output files are now located in mpir\lib\Win32\Release or mpir\dll\Win32\Release.
The recommended way to build MPIR specifcally for your CPU is to first run mpir_config.py which is located in the build.vc10 directory. mpir_config.py will prompt you with a list of CPU options. Then when you open mpir.sln, you should only compile code for the specific CPU. And then you compile the C++ wrapper (i.e. compile lib_mpir_p3 first, and then lib_mpir_cxx).
Edit: I just noticed another error from your original post. You need to rename the directory "mpir-2.6.0" to "mpir". The directory layout needs to be "<>\mpir\build.vc10"
I had the same problem with MPIR 2.6.0 and VS 2012. What I did to make MPIR work was to build lib_gc and lib_cxx, both with win32 and release mode. Because my c++ application is win32 console, this way it worked perfectly.
Becuase my windows is 64, I thought I had to build 64 versions, but turned out that I was wrong.