I'm writing a C++ wxWidgets calculator application. I recently started getting some random IntelliSense errors that did not however stop compilation. I followed an advice online and performed Clean Solution after deleting the .suo file in my project directory. Now I'm getting 92 errors that do however interrupt compilation, and I have no idea what to do.
"Cannot open error code ".." of source file
Cannot open inclusion file: ".." no setup.h such file or directory
And lots of other erros of these kinds, along with random syntax errors.
I think that the problem might be that VS isn't finding wx/wx.h for some reason.
My setup (don't know if it has anything to do with the errors)
To start programming with wxWidgets, I followed a YT tutorial. I have my wxWidgets files in my D: disk. I have a WXWIN system variable pointing to that directory. In Project properties > C/C++ > General > Additional include directories I have $(WXWIN)\include; $(WXWIN)\include\msvc. Then, in Linker > General > Additional library directories I have $(WXWIN)\lib\vc_lib.
After Clean Solution these options were reset to default (along with _CRT_SECURE_NO_WARNINGS preprocessor) and I had to re-enter them. Now I'm getting all these errors and I don't know what to do.
It seems you simply didn't build wxWidgets itself in x64 release configuration that you use. You must do it before using it.
I also strongly recommend following the official installation instructions rather than tutorials that may be out of date.
Apparently I accidentally changed the combo box left of the "Local windows debugger" button from x86 to x64. I switched it back to x86 (even if I don't know what that means) and everything is back as it is.
Related
I am somewhat of a beginner when it comes to open source libraries. I have tried to compile from source and use the pre-built binaries, but in both cases I get a ton of errors when I try to run the simple 'Hello World' program on the tutorial section of the wxWidgets website. After playing around for quite some time, the closest I have got to compiling is by building the libraries from source, but I still have 2 errors remaining:
"_w64 can only be specified on int, long, and pointer types" file: defs.h
"cannot open file 'wxbase31ud.lib" - LINK
It seems strange to me that the header file provided by wx would have an error such as that one, so I imagine both errors are because of something I am doing. I am hoping that someone here can do one of the following for me:
Help me solve these errors
Provide instructions for building libraries from source and subsequently linking my program to the correct directories
Some additional info: I am working on x64 Windows 7, my target will also be x64 exclusively. I do not have admin privileges, so no editing the system PATH for me.
Thanks for your help!
The simplest way to start working with the library is this:
Grab the sources.
Unpack the sources.
Open VS IDE.
Open \build\msw\wx-vc14.sln (adjust as necessary.)
Go to "Build->Batch Build...", click "Select All", "Build".
Go drink some coffee or watch TV.
After the build finishes, open wxWidgets/samples/minimal/minimal_vc9.sln.
Let MSVC convert the solution to become an appropriate format.
Build and run the sample.
If you will acquire any issue during those steps, let us know.
The library build in step 5 should build without any issues and then all you will need is to build the minimal sample.
The next step is to copy the samples\minimal folder somewhere and start writing the code. All you will need to do is to change the Include and Lib search path.
[EDIT]
If you can build the 32-bit libraries (which are default in the provided solutions) all you will need is to convert them to be 64-bit and rebuild.
There is no changes to the $PATH or any environmental variable involved. Moreover you shouldn't build anything with the admin priviledges.
Also as Thomas pointed out you library build has to match whatever sample you are trying to build.
[/EDIT]
I was beginning to use Visual Studio 2013 to work with OpenCV.
I had completed a simple project that I need and was just doing some cleanup.
The compiler begin giving the message.
error C1083: Cannot open source file:
What I have tried so far:
Creating a new console application in a separate file and trying to compile it, just created . -> same error.
Repairing Visual Studio using the original installation disk. -> same result on new just created project "error c1083;
Uninstalling Visual Studio and then reinstalling it. -> same result on new just created project "error c1083"
Things I have noticed. My compiler is not creating a .pch file or at least I cannot find it. I have precompiled headers enabled. /Yc for stdafx.cpp and /Yu. for other files if I have any.
If I use a previously created project that was working the IDE will run it, but if I change anything in the source file I get the same error.
I have tried placing projects in very short paths and in the normal location for the compiler.
Solution explorer sees and will open the source file.
I am beginning to think something is corrupted in my operating system. (Windows 7).
I have been thinking I might format the disk and reinstall Windows, but thought I might ask for suggestions on this problem first.
"
What do you mean by 'doing some cleanup'? It is quite unlikely that your OS is corrupted. There is probably something wrong with your project properties, but I couldn't tell you what without better information"
This was just a simple project to place cross hairs on the input from a USB microscope which was spindle mounted on a CNC milling machine for centering purposes. I was just changing the on screen position and size of the cross hairs. Then when I recompiled the problem started. I thought it might be a corrupted file because of the fact that it persisted after uninstalling and reinstalling Visual Studio. The fact that a freshly generated project would not compile made me suspicious.
"
Looks like something in your Project/Properties is not right. It is looking for the files in the wrong directory"
You are probably correct, but I am a novice and have spent many hours trying to find what it may be any suggestions for what settings to change would be greatly appreciated.
"
Do your TMP and TEMP environment variables point to directories that (1) exist (2) you have write permission to and (3) have free space? "
Yes sir The environment variables are set and the directory has read write permission. There is > 1T of free disk space.
"
Also try (with VS closed) deleting the registry keys HKCU\Software\Microsoft\VisualStudio\12.0 and 12.0_Config and the directory %LOCALAPPDATA%\Microsoft\VisualStudio\12.0, then open VS and try again with a fresh project. This will cause VS to regenerate all caches and "transient" information (it will also reset all your settings, so beware)."
Sir: I deleted the keys and the directory you recommended, generated a fresh project and tried to compile it. The compiler generated the same error. I genuinely appreciate the suggestion.
"VS only allows closed source development"
Pointed, consider the source of VS.
I have mixed C++ / Java project in Eclipse. I've setup a build.mk file and Eclipse builds project successfully when all files in editor are closed. When I open a .h or a .cpp file Eclipse finds a lot of undefined symbols in them. I have references to 3rd party API and all the problems seem to be related to symbols from that API. Strangely, some types are considered defined in Eclipse, and some are considered undefined even though in some cases they are defined in the same .h file.
My colleague is not experiencing any of these problems, but we are clueless where to start solving this problem. We already made sure that our Eclipse include directories are the same. Is there some way to compare eclipse project settings?
Update: .cproject files and .project files and files in .settings directory know differ only by some paths. Did not help to solve my problem though.
I had the same problem. It could be resolved by flushing the Eclipse indexer.
I used the projects context menu and selected Index->Rebuild and Index->Freshen All Files. The last removed the error messages.
Turns out I needed to change Code Analysis settings that are on Launching tab, and I simply did not see that tab.
I had the same problem. It take place when in included file I'd used
namespace std
without using it in main file or vice versa. Do check using namespace equally.
You can compile and run the source code also by Right Click On Project>Run C/C++ Code Analysis. This will solve your problem.
I finally figured this out. Flushing the Eclipse Indexer as mentioned in the top voted answer didn't work for me. This is what I had to do:
I went to:
Project -> Properties -> C/C++ General -> Paths and Symbols -> Includes
Here I had the path for my include directory, but what I had to do was delete the directory path, and then re-add it making sure to check the box "Add to all configurations". I also checked the box "Add to all languages", but I don't think that is necessary.
After this, you may need to then click on Project -> C/C++ Index -> Rebuild. I didn't need to, but you might. Also, obviously instead of C/C++ in the paths above, it will be Java or whatever language you are dealing with.
I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1
Then the following problem occurs:
I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
The problem is that there are a bunch of include directories that are missing from the indexer's perspective.
Adding the following worked for me, but may depend on your particular setup where they actually exist:
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
They can be set in Project>Properties>C++ Include Paths
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.
Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
if set to "true", any cached data used by the OSGi framework and
eclipse runtime will be wiped clean. This will clean the caches used
to store bundle dependency resolution and eclipse extension registry
data. Using this option will force eclipse to reinitialize these
caches.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.
Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.
The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case).
After this 'Path and Symbols' will show the correct path to the include files of your compiler.
The bugs will disappear.
This setting was useful only during creating the project, setting it later did not help.
In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
compiled the project (obviously the compiler complains since it is missing user-defined headers)
reinserted the path to the header files I created
compiled the project again - worked perfectly
I can't explain the case :(
I am answering here because this is the closest question to my problem.
I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
function 'fprintf' could not be resolved
function 'memset' could not be resolved
even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.
If I went back to Helios, the problems went away.
I tried reindexing, to no avail. I checked my include paths, and they were:
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".
I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.
Now I knew that it wasn't just a Qt problem.
I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!
It was then that I took another look at the include paths. They had been updated by the compile step to the following:
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.
So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.
The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.