I have a workspace with multiple projects, which all compile with no problems. However, some of the projects are giving a lot of warnings in the editor about unresolved symbols, due to unresolved includes. Most are headers from other projects in the workspace, or third party libraries.
Googling suggests this is a problem with the indexer, but I haven't found any coherent explanations of how to fix it - I assume I need to add the paths to these libraries to the indexer's PATH, but I can't see any option to do that (I am using Juno).
Can anyone please explain to me how to configure CDT's indexer?
I am also getting unresolved include warnings for STL headers in two projects. Some STL headers are resolved but others aren't, and the list doesn't seem to be the same between the two projects (one finds things like vector and iostream, but not sstream or string, the other doesn't find iostream either).
Possibly relevant: these are C++ projects, but all the file extensions are .c. I changed the GCC C Compiler command to 'g++' to compile them, but I guess I also need to do something to the indexer settings to cope with it?
I had a similar problem where my project would build but showed unresolved includes in Eclipse Kepler.
In my case I had taken an existing ARM project and created a custom build configuration that used a different tool chain. The new build configuration had all the correct includes, so the project built correctly but the indexer wasn't picking it up.
I fixed it by setting the indexer to use the active build configuration. In Window->Preferences->C/C++->Indexer, under the section labeled "Build configuration for the indexer" I selected "Use active build configuration" and it cleared it up.
Ok, so I've now fixed this issue.
Unresolved includes from other projects in the workspace and third-party libraries was solved by adding the other projects as references. I guess the compiler knew where to look because I'd added the locations to the Includes list, but the indexer didn't (possibly due to eclipse only processing headers once?)
Unresolved includes from STL I fixed by changing all my .c files that were actually C++ to .cpp. Just changing the compile command to 'g++' obviously wasn't enough to tell the indexer to treat the project as C++.
In the case of 1), I needed to clean/rebuild index of the referenced projects first to remove the unresolved include errors.
Right click your project in the workspace, choose Properties -> C++ General -> Paths and Symbols, then add includes and symbols for your specific compiler, add libraries, and other stuff you need on the tabs available. After that hit Apply - it should start re-indexing, and your problems should be gone.
All answers are helpful but there was another trick that solved my problem.
I found out that in contrast to the compiler the indexer does not process subdirectories of included paths. Therefor you need to be more specific when including header files.
Example
#include "subdirectory\include_2.h"
Additional hints :
Right-click your project -> Index -> Search for unresolved includes.
In the search results open the folders and files and see which unresolved inclusions they have.
Find their directories and add them to the Paths and Symbols.
Related
When I compiled my project in Release configuration, it worked fine. However when I compiled it in another configuration it failed with link errors, such as:
unresolved external symbol, tbsi_context_create,PROJECTNAME(FILENAME.obj)
Since it is a link error, I compared the 'additional include directories' and "additional library dependencies', but both are exactly the same. After I tried many other things including a clean rebuild, then I realized that in the configuration that has issues, there is an additional preProcessor in Project Properties->Configuration Properties->c/c++->preProcessors. Removing the preprocessor solves the issue. It is not the first time I came across this link error, but I believe this is the first time that it is caused by an additional preprocessor.
I have a very strange error/bug here:
From one hour to the next, Eclipse isn't able to resolve any of the symbol. E.g.:
std, list, [own objects], or functions like: size(), append(), cout and so on ...
I already rebuild and /refreshed the indexer over the whole project and tried to clean it too. But without any effort. The only thing new I did was yesterday: I added Doxygen support to my project.
I have no idea where this comes from. I think sending all the source code is way too big, it has to be a general Eclips-Error, since I was working like this for weeks.
Eclipse version: Kepler Service Release 2
Has anyone an idea?
UPDATE
Thank you for your Support and pardon me I have switched my whole system, thus I can't reproduce your suggestions anymore.
there are two ways:
use system's default lib: when you create the project using "New Project", you can select the "Toolchain for Indexer Setting". For example, I am using Eclipse in Linux so I just choose "Linux GCC". And after the project is created, all the headers will be automatically included for you.
use you own version of the lib: you need to tell Eclipse the paths to search for the include. Right click the project name, select "C/C++ General" -> "Paths and Symbols" -> "GNU C++". And you can add your paths there.
Most likely you have some system-specific include directories missing in your settings which makes it impossible for indexer to correctly parse iostream, thus the errors. Selecting Index -> Search For Unresolved Includes in the context menu of the project will give you the list of unresolved includes which you can search in /usr/include and add containing directories to C++ Include Paths and Symbols in Project Properties.
On my system I had to add /usr/include/c++/4.6/x86_64-linux-gnu for bits/c++config.h to be resolved and a few more directories.
Don't forget to rebuild the index (Index -> Rebuild) after adding include directories.
I have an object file library that exists as a standalone VC++ project. I have a number of other completely separate VC++ solutions, and I would like some of them to utilise the classes included in this library.
I have added the project to a solution as detailed here: (See docs). I have followed all of the instructions but am still getting "unresolved external symbol" errors when trying to use the class.
Can anyone help?
Specifics:
The class library in question is an SQL access library. Inside there are two files, sql.h and sql.cpp. Pretty simple. That project compiles itself absolutely fine, so I know there is nothing wrong with that project. I was under the impression that to get the project included in an existing solution I had to:
Add the project to add the project to the solution
Add a reference to the project
Add the include directory
Add #include "sql.h" to the project
That is what I have done, to no success.
Please make sure the external library is linked into your project. It usually comes in a form of a .lib file (for example, sql.lib)
Go to Configuration Properties ->Linker and add your library to the "Additional Dependencies" list.
I know this is a common problem and I can see quite a few questions about LNK2019 but I can't for the life of me find what I'm missing.
I am working on a C++ DirectX project and I want to use the DirectXTK library (Direct X Tool Kit). I have included the project in my solution and it builds fine.
I've also included the ScreenGrab.h header I want to use in my own project. Intellisense picks up the function definitions from ScreenGrab.h fine and so I have called SaveDDSTextureToFile().
But when I go to build the project I get the LNK2019 error on SaveDDSTextureToFile(). I'm assuming this means it knows where the definition is (in the header) but can't find the implementation of the function in the .obj or .lib, is this correct?
I assume I need to tell the linker where these files are? I tried doing that in Properties->Configuration Settings->Linker->General->Additional Library Directories but I still get the LNK2019 error.
Does anyone know what I'm still missing?
Thanks for your time.
Stupidly, I didn't add the lib to the Linker oops.
Basically for anyone else that forgets this step - after you've added the directory to Linker->General, go over to Linker->Input and add the name of the .lib to "Additional Dependencies" - so for me I typed "DirectXTK.lib" here (without the quotes).
If I hadn't added the directory to Linker->General I also could have typed "../folder1/folder2/folder-etc/DirectXTK.lib" here depending on the relative path from where my project is.
Sorry for wasting people's time and I hope this helps others.
Make sure your linker->general->additional library directories configuration is for all configurations, and not just "release" or "debug". Try adding the static library file (depending on the Direct3D version you're using) to your project from the SDK directories - if it compiles then you've definitely done something wrong with the linker configurations.
We have a large project using VS2008 and boost 1_42. I'm trying to upgrade to VS2010 and boost 1_44. I installed VS2010 and boost 1_44 and converted the project. Now I am trying to build, and everything compiles, but fails when linking:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-1_42.lib'
I have changed the include and lib directories to point to the new boost 1_44 files and I have renamed the old boost 1_42 directory.
Why is the linker still looking for a vc90-1_42 file, when it is only using 1_44 headers? Is there a way that I can determine WHY the linker wants this file? The linker obviously thinks it needs the file, but why?
I have cleaned the project and I am re-building to ensure any old build files are erased.
I've run into exactly this problem a couple of times too. It's usually been some old temporary files but like in your case cleaning didn't always do the trick straight away. Does your project include any static libs that might have been built with 1.42?
Something you can try which may or may not be helpful in tracking down your issue:
Rename the old boost directory back to it's original name
Clean the solution
Under C/C++->Command Line->Additional Options add "/showIncludes"
Under Linker->Command Line->Additional Options add "/verbose:lib"
Rebuild all
Then when you build you'll be able to see at which point 1.42 headers are included, etc. in the output window. Somehow doing this helped me in tracking down where the problem was.
Along with changing the lib directory, you need to change the name of the boost library. That's in the Linker | Input section of the project settings.
Your added comment makes it clear that the dependency on the Boost 1.42 library was being created indirectly by another library that hadn't been rebuilt.
For this you basically have two choices: either add that library as a project to your main solution, and make sure it has enough dependency information that it'll be re-built when you upgrade Boost, or use the /Zl compiler switch when you build your library. This tells the compiler you're building a library so you do not want to embed library dependencies like this.
Boost uses
#pragma comment(lib)
command to inform the linker of libraries it needs to link with. It is not an error. If Boost says you need it, it's likely you do.
On How can I find out why the linker wants this file?
There are programs which will go through your app and dlls/libs and report the content of manifests and what the binaries report they depend on. You could then scan the report for the unexpected libraries being included. We used this mainly to find libs including the previous version of the VC runtime.
Have not used the one we had in about 5 years though, now if only I could remember the name of the app!
DependancyWalker (depends.exe) will allow you to see dependancies of dll/exe but not static libs.
You could open each binary as a 'file' in MSVS and look at the manifest content by hand, but I imaging this would be a bit painful. I've not tried this with a static lib.