So a few hours ago I started learning c++ in codelite but I was getting frustated with, so I just got codeblocks and imported the project. But now whenever I try to compile it returns:
fatal error: imports.h: No such file or directory
This is my project hierarchy in codeblocks:
And this is what the project folder looks like:
What am I doing wrong?
I know this is years later, but I've recently seen students following what I deem is frankly bad advice such as what is given above. For those learning c++ this functionality is NOT for you. To add headers you should simply check that you are using double quotes, instead of angled brackets i.e.
#include "myheader.h"
and NOT
#include <myheader.h>
Angled brackets are meant for libraries (informally) and adding a simple header file for you basic classes does not require you to change default search directories. The problem comes when someone else tries to run your code (assuming you're doing this for uni) and their IDE isn't setup to search for a "library" (your header) where it shouldn't be. Double quotes tells the compiler the files exist in your current relative directory. This way you can keep your main, headers and header implementation in one directory. Fiddling with your IDE should only be done when necessary. KISS
You have to tell Codeblocks where to find the header files that you include. Try adding the full path to your '/Headers' in the include directories of codeblocks
Goto 'Codeblocks menu > Settings > Compiler > Search directories > Add'.
EDIT: Since your issue, however, is quite irrelevant to learning the C++ language itself, I suggest that you start with simpler programs, then move on to more complex ones. That, of course, unless you have previous experience with other programming languages
Since I haven't found any Makro for
#define 'hostname of device where compiler is located' // which is unique and not to be copied !
I have now successfully used and included
#include "myCompileEnv.h"
as a workaround with the comments above, which is located more central - above the project directories in CodeBlocks.
I have a project that uses a shared library from another project.
In project settings I put the correct include paths and library for the GCC and G++ compiler (-L and -l option). It all compiles well, no problems here.
But the source code is not analyzed correctly.
My included headerfile (that is located in the other project) is marked as "Unresolved inclusion and everywhere I use something from it, the source is highlighted as well.
#include "myHeader.h"
Any ideas? thanks!
The one that you are missing here (probably) is, telling the indexer where to look for those headers.
I normally manage my own Makefile, so I do not know how to make it work for both the eclipse managed makefile and for the Indexer. Probably you will find that the solution below will fix both.
On the solution; right click on the project in the Project explorer ( or resource explorer ), and select Properties. Now under "C/C++ General" > "Paths and Symbols", click on Includes tab and select "GNU C++". Then on the right side, you can add various include paths ( similar to the -I option on gcc/g++ ) by clicking on "Add..." button.
Once you apply and click OK, the indexer will take a while to clear those unresolved object.
A header should be included like this
#include "myHeader.h"
or if it's a standard lib header:
#include <string>
everything else is invalid.
Remember to enable the Providers in the "Preprocessor Include Paths, Macros, etc.".
I'm a newbie so be easy.
I'm "trying" to build a LCD test program which was given to me by an instructor that uses the XLCD.h and Delays.h headers. Problem is that the headers don't seem to be linked during the build process as the compiler keeps tossing me an error about a function not being defined.
MPLINK 4.42, Linker
Device Database Version 1.7
Copyright (c) 1998-2011 Microchip Technology Inc.
Error - could not find definition of symbol 'SetDDRamAddr' in file './LCD_Main.o'.
Errors : 1
I used the Project Wizard and selected my chip...added the .lnk file for my chip, added the .h files for xlcd and delays, added the p18cxxx.h file.
The test code is tried and true. I've done the #include at the top and I've even put the file in the same directory and then used #include "xlcd.h" but nothing seems to work for me.
Yes, I've double tripple checked the syntax for errors and eventually just copied and pasted from the header file to the main.c so it's not that.
Looking at the error it seems to me that only the prototype might be being seen and not the defined function. I thought that was all done with magic in the background so I have no idea how to check for paths or even if it is happening.
As the whole thing is a bit of a walkthru I figured it should be straight forward but it's not.
I'm sure it must just be a simple fix but I've been working on it for hours now and I'm getting ready to drop kick the stupid protoboard and PIC across the room.
Anybody have an idea what I could be doing wrong?
Thanks
You need to point the linker to the proper library.
Go to Project->Build Options. Select the Directories tab. On the Show Directories For combobox, select Library Search Path. Click New.
Then, select the directory that has your libraries. For C18 it's likely (on Windows 7):
C:\Program Files (x86)\Microchip\mplabc18\v3.41\lib
You should then be able to link without problem.
I'm a real beginner and I'm programming in C++ using Visual Studio.
I've a simple cpp code that recalls some functions written in a .c and .h file. I included that file by means of #include directive and the IDE "sees" the function.
When I compile, I get this
Error 7 error LNK2019: unresolved external symbol _IMUsendAccelToFIFO referenced in function _main D:\Cprojects\Pencil\Pencil\Pencil.obj Pencil
What am I missing here?
Thank you all!
It is a linker error, not a compiler error. The compiler is happy, it saw the declaration of function in the .h file. The linker isn't, it cannot find the definition of the function.
Add the .c file to your project.
If you get an error in Visual Studio you can actually google for the error code and you will get pretty extensive information for that. In this case, googling LNK2019 gives this MSDN page as first hit, which also provides some examples on how you get the error.
Your vendor should have provided some .lib files for you (usually found in a folder named lib?). Make sure that these are added in the project via:
Project > Properties > Configuration Properties > Linker > Input > Additional Dependencies
You could also see if there is any "get started" information for you from your vendor, which explains which dependencies you have to include in your project.
If you feel unsure of what a compiler and what a linker does, pick up a book that explains it, or browse some free alternatives.
Are you using ghettopilot? that's the only reference I can find on the web to the function you're missing. If you are, then you need to include the .lib file for that library in your link options.
Visual Studio will compile .c files as C and .cpp files as C++ by default, and this can cause trouble because if you want to call functions defined in a .c file from a .cpp file, then you must wrap the header in extern "C" { }, as the compiler will expect all functions not declared extern "C" to be from C++. This is because of an implementation detail called name mangling. Alternatively, you could force all files to be compiled as C or as C++ in the project settings.
Solved! Thank you very much!
The libraries I was using needed to be built. I tried but I couldn't build them as I used to get "heap space" error!
I installed Visual Studio 2005 (with which the code was produced by the vendor) and it worked at first attempt! There are probably some back-compatibility issues..
I am getting this linker error.
mfcs80.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRT.lib(dllmain.obj)
Please tell me the correct way of eliminating this bug. I read solution on microsoft support site about this bug but it didnt helped much.
I am using VS 2005 with Platform SDK
I had the same error message, but none of the answers here solved it for me.
So if you Encounter that Problem when creating a DLL Project that uses MFC, it can be resolved by entering the following line:
extern "C" { int _afxForceUSRDLL; }
to the cpp file where DllMain is defined. Then your own DllMain implementation is used, rather than the one from dllmain.obj.
When we try to use MFC library, we surely will include afx.h directly
or indirectly, then MFC(afx.h) tell the linker to find the symbol of
__afxForceUSRDLL and put that object which contains __afxForceUSRDLL into the program, so linker searches and puts dllmodule.obj into our
program, because __afxForceUSRDLL is defined in dllmodule.cpp.
That’s the common scenario. When we want to use our own DllMain in a
mfc dll project, linker complains that there are two DllMain, one in
our code, one in Dllmodule.obj.
So we need to tell the linker to add our dllmain.obj for
__afxForceUSRDLL. So we need to define __afxForceUSRDLL in our own cpp file where our own DllMain is defined, then the linker will ignore
mfc’s dllmodule.obj and see only one DllMain and never complains.
Source: http://social.msdn.microsoft.com/Forums/en-US/0d78aa6b-1e87-4c01-a4a7-691335b7351a/how-to-build-mfc-application-dll-in-visual-c-2010
If you read the linker error thoroughly, and apply some knowledge, you may get there yourself:
The linker links a number of compiled objects and libraries together to get a binary.
Each object/library describes
what symbols it expects to be present in other objects
what symbols it defines
If two objects define the same symbol, you get exactly this linker error. In your case, both mfcs80.lib and MSVCRT.lib define the _DllMain#12 symbol.
Getting rid of the error:
find out which of both libraries you actually need
find out how to tell the linker not to use the other one (using e.g. the tip from James Hopkin)
If you're defining your own DllMain, in your project settings you need to set 'Use of MFC' in the 'Configuration Properties/General' to 'Use Standard Windows Libraries'.
You should do a clean rebuild after changing it.
In my project I was able to solve this problem by adding mfcs80.lib and msvcrt.lib as additional dependencies in the project settings. The 'additional dependencies' can be found under Linker -> Input.
In the debug configuration that would have to be mfcs80d.lib and msvcrtd.lib respectively.
By the way, I am working with Visual Studio 2010, so in my case the MFC lib is called mfc100.lib.
I am not sure why this worked. It is not necessary to add these lib files as additional dependencies because I already set 'Use of MFC' to 'Use MFC in a shared dll'. I guess that by specifying these libraries as additional dependencies they are linked in a different order.
This solution is more or less the same as the one suggested on the Microsoft site: http://support.microsoft.com/kb/148652, except I did not need to type anything in the 'Ignore specific default libraries' box.
For me the direct cause was indeed a missing _afxForceUSRDLL symbol reference, but the indirect cause was a missing _USRDLL macro definition. It is defined by default by the VC wizard, but occasionally devs erase it erroneously.
Here it is in more words.
MSDN knowledge base ID Q148652.
http://support.microsoft.com/kb/148652
Cause:
Visual C++ compiles the source files in alphabetical order, and passes the compiled object files to the linker in alphabetical order.
If the linker processes DLLDATAX.OBJ first, the source code references DllMain, which the linker loads from MSVCRTD.LIB(dllmain.obj).
The linker then processes an object file compiled from a C++ file that contains #include "stdafx.h", which references the symbol
__afxForceUSRDLL, which the linker loads from MFC42D.LIB(dllmodul.obj). This object module also contains an implementation for DllMain,
causing the conflict.
I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)] and the solution was add mfcs110d.lib to Additional Dependencies
For all those who are experiencing this error in ATL projects (mostly when trying to add MFC support), here's the solution I found after days of frustration!
First of all, this link was more helpful to me than all the others. It pointed me into the right direction. The problem occurs, if the "generated files" (containing the proxy and stub code, just as the type guids) for some reason have been removed and readded to the project. This causes Visual Studio to add them in the wrong order!
Usually you first come up with the "ATL requires C++ compilation" error, but you may have fixed this by turning out the Yc/Yu (precompiled headers) setting for that file.
What you should do next is unloading your project and edit it. Search for the item groups that define the build and include order (ClCompile and ClInclude). Check their order and settings.
The compiles should appear in this order:
dllmain.cpp (with CompileAsManaged set to false and PrecompiledHeader left empty).
Library source (MyLib.cpp, containing DllCanUnloadNow and so on)
Proxy/Stub code (MyLib_i.c; with same settings as dllmain.cpp)
stdafx.cpp (with PrecompiledHeader set to Create)
All the other library source files (your actual libraries content)
xdlldata.c (with the same settings as dllmain.cpp)
The includes should then be ordered like this:
dllmain.h
MyLib_i.h
Resource.h
stdafx.h
targetver.h
... (actual library headers)
xdlldata.h
Fixing the build order fixed my project and I was able to create a new clean build.
I have personally got rid of this error this way: right-clicked project in the Solution Explorer, selected Properties from pop-up menu, clicked Linker tab and added mfcs71ud.lib into Additional Dependencies. If you're using Visual Studio 2005, it should be "80" instead of "71" and so on.
In my case I had a problem with the preprocessor directives.
For some reason _USRDLL was defined, when it should not have been.
To check this, go to the menu Project , select Project Properties , then select the snippet Configuration Properties --> Preprocessor .
The preprocessor directives will be found there.
Declare the mfc80ud.lib and mfcs80ud.lib in the Additional Dependancies field in the Project Properties -> Linker Tab -> Input of Visual Studio to fix the issue.
Just #undef the _USRDLL before including afx.h, or even better, edit your project configuration and remove the macro.
This is the usual configuration for a MFC extension DLL: Build Settings for an MFC DLL
Make sure you include "Stdafx.h" at the top of each .cpp file. I was getting the exact same error and had a single .cpp file that did not include this header at all. Adding the #include solved the problem.
I found solution Here
Visual Studio 2010 library linking order
this is: /FORCE:MULTIPLE
in linker options
I had to mix ATL and MFC together , to use
[module(name = "mymodule")]; construction in MFC application together with "__hook" keyword
I found this which helped me:
http://support.microsoft.com/kb/148652
Basically the linker order was incorrect. the CRT libs were getting linked before the MFC libs. Turns out, the MFC libs had to get linked FIRST, and then the CRT libs could be linked.
Yucko Microsoft!!
There is a common theme running through some of the answers here.
Avishek Bose:-
Declare the mfc80ud.lib and mfcs80ud.lib in the Additional
Dependancies field in the Project Properties -> Linker Tab -> Input of
Visual Studio to fix the issue.
vmb100:-
I am working with Visual Studio 2010, so in my case the MFC lib is
called mfc100.lib.
joseAndresGomezTovar:-
I have a very similar problem. [mfcs110d.lib(dllmodul.obj) : error
LNK2005: _DllMain#12 already defined in MSVCRTD.lib(dllmain.obj)] and
the solution was add mfcs110d.lib to Additional Dependencies
So the general case seems to be to first find the name of the library to add ...
and then to add it ....
Note that there seem to be some prerequisites and/or alternative solutions.
This can also occur if your solution has multiple projects that export the same symbols. For example if you have sub-project that builds foo.dll with a foo.def file that exports DoFoo and a sub-project for bar.dll with a bar.def file that exports DoFoo, a collision will occur and this is the error you will see when you link.