Details are saying I have two different tools of the same compiler. I'm not sure where to go from here to fix this so I can build my project. Any ideas?
This is the detailed message:
Errors occurred during the build.
Errors running builder 'CDT Builder' on project '263_Hw'.
Internal error building project 263_Hw configuration Debug
Generated resource conflict:
two resources of the same name: /263_Hw/Debug/main.o
generated by different tools
tool1: GCC C++ Compiler
tool2: GCC C++ Compiler
Generated resource conflict:
two resources of the same name: /263_Hw/Debug/main.o
generated by different tools
tool1: GCC C++ Compiler
tool2: GCC C++ Compiler
Internal error building project 263_Hw configuration Debug
Generated resource conflict:
two resources of the same name: /263_Hw/Debug/main.o
generated by different tools
tool1: GCC C++ Compiler
tool2: GCC C++ Compiler
Generated resource conflict:
two resources of the same name: /263_Hw/Debug/main.o
generated by different tools
tool1: GCC C++ Compiler
tool2: GCC C++ Compiler
The most likely situation: you have two source files with the same name but different file extensions. In your case, that would likely indicate you have something like
main.c
main.cpp
in your project tree. Could be tricky to see, especially if you have a lot of nested folders. I'd go to your source root and do a search for main.*
In Ecplise, right Click on project -> Properties -> C\C++ Build -> Tool Chain Editor. In the 'Current Builder' select box, select 'Gnu make builder' -> Apply (or Ok).
Try building the project again.
If you've exhausted all other options try using the gcc make tool directly:
1) Open the command line
2) cd to the folder containing the Make files (i.e. # cd 'C:\Path\To\MakeFile')
3) Assuming you have a typical MINGW windows install, run the command # C:\MinGW\bin\mingw32-make.exe all
4) the above command can be shorter if you have the MinGW folder set as a path variable.
5) The output binaries should be found in the bin folder in the same location.
Hope this helps anyone.
I have seen this same problem before but i don't remember what i did about it! For starters one way to try to solve it is by checking if you have more than one MinGW folder installed on your computer (I am assuming you use MinGW)! Also Check your project properties->c/c++ General->Paths and symbols->Includes and making sure that there are links to only one minGW folder! (It may look something like this (except for you they may start with "c:/mingw/...":
My solution was to delete the project (not the source code, just remove the project from Eclipse) and recreate it from scratch and setting up the include paths and linker paths again. Then it compiled properly.
This happened to me after I deleted a project from the workspace. I reimported the project with the same name to the same workspace, and when I tried to rebuild I got this error.
What I did was to delete the project from the workspace again, and then check my local directory where the workspace folder is. Voila, the deleted project is still in the workspace folder. So I deleted that project folder, then reimported the project again. It worked for me this way ;)
Related
I'm modifying a simple example project (blinky) from the nRF SDK. I added a header file and a .c file in a new folder inside the project directory then added that path ./lib to the common preprocessor user include directories. I then included the header to main.c.
I can compile the new library on its own but when I build the whole project, I get Build failed error with no stated reason to follow up.
Here is an image of that:
Does anyone here know how to beat this?
I haven't used Segger Studio specifically, but it seems to be the CrossWorks IDE underneath.
In CrossWorks, you have to do the following:
Download & install all relevant libs from inside the IDE, under Tools -> Packages -> Install packages. Grab your specific target MCU as well as any specific boards or libraries you'll be using. In case some needed lib is missing here, you will get very weird errors.
In the project, click on the project name itself in "project explorer". Then in the properties window, check settings (this is a bit different in different versions of CrossWorks, might have to right click and pick properties in older versions). Under "user include directories" you should have something like this:
$(DeviceIncludePath)
$(TargetsDir)/NameOfMCU/Include
$(PackagesDir)/CMSIS_4/CMSIS/Include
$(ProjectDir)/NameOfDirectory
Where "NameOfMCU" is the name of the MCU family used, CMSIS should be there in case you are using any ARM, "NameOfDirectory" is the name of your custom directory (you can add several).
Also, get the debug build working first, before switching to release build.
I'm building some custom Qt components as a static library, but I can't get past the compilation phase.
My project is structured as follows:
Root:
- .h and . cpp files of the custom Qt components
- GeneratedFiles/Debug/ <-- here the MOC compiler puts the generated moc_*.cpp files ("Debug" is automatically deducted from the build configuration, so it's Release for release builds)
That's a pretty standard folder setup, but for whatever reason the compiler can't find only the moc files. Anything that is in the root folder builds just fine, but the moc files are not found. Please note, the moc_ files are generated just fine and exist where they're supposed to be, with the correct content. The problem seems to be in the evaluation of the path GeneratedFiles\Debug\moc_whatever.cpp.
Interestingly enough, if I move a moc file (say, moc_example.cpp) in the root folder and manually adapt the call to CL.exe to compile moc_example.cpp instead of GeneratedFiles\Debug\moc_example.cpp, the file gets built.
I'm using VS 2017 version 15.7.1, CL is version 19.00.24215.1 for x64 and I'll update the question with any other detail might be useful, just add ask in a comment.
So... Why is the compiler telling me those files do not exist?
I finally solved this rebuilding the directory structure in a new directory. Apparently, using WSL's git to check out repositories under Windows breaks something in the filesystem in a way that is invisible from Explorer or Ubuntu's command line, but that breaks the compiler (and Visual Studio's intellisense).
Checking out the repository with Git for Windows seems to avoid causing the same problem.
I am using CDT in Eclipse 3.5.2 Galileo in Ubuntu.
My eclipse's indexer doesn't work at times. By that I mean when I ctrl click a function it says Could not find symbol in index. Also, F3 button click results in the same error message. Actually most of the places it is not working and works in very few places.
I have seen some other versions of Eclipse where under File menu a menu item listed for Indexing. Like File->Indexer->Rebuild.... But in my File menu there is no such menu item for the Indexer.
Will the only way be to use some other release of Eclipse or am missing something? Any pointers regarding this would be helpful.
In my case nothing has worked and at last I did the following:
1) Close the project
2) Delete the project(do not check from disk option)
3) create new project with existing code(use the deleted project path)
4) Successfully indexed my c++ code
To add paths containing code to parse, follow these steps :
1. Right click on the project
2. Select Properties
3. Go to C/C++ General
4. Go to Path and Symbols
5. If the paths are missing, add paths.
To re-parse the code follow these steps :
1. Right click on the project
2. Select Index
3. Rebuild
If this doesn't work, then you are out of luck. c++ is very difficult language to parse.
If your indexer is stuck and it hangs for infinite time, you can delete the indexer related files of your project from .metadata. Make sure eclipse is not running in the meanwhile.
The .metadata directory is located as a hidden folder in the path of your workspace.
There you can navigate to:
<workspace_path>/.metadata/.plugins/org.eclipse.core.runtime/.settings/
Inside the .settings/ directory there are .prefs files which store the preferences of each project individually.
For example: org.eclipse.cdt.core.prj-test-project.prefs stores the preferences of the project test-project
Open this file with the text editor and remove all the lines starting with indexer. This will reset the indexer settings for this specific project to the default.
Alternatively, you can remove all the lines starting with indexer from org.eclipse.cdt.core.prefs; doing this will reset the indexer settings for the whole workspace.
I believe you can clear the index by running:
rm .metadata/.plugins/org.eclipse.jdt.core/*.index
And then restarting Eclipse. It will then rebuild its index.
This worked for me in a Java project, but I imagine its the same index for all (most?) project types.
Right click on the project.
Select New->Convert to a C++ Project.
Select your configuration. And then Next
Indexer will start indexing all the files.
For me this worked:
Right click and close the project
Open the project again
Right click and select Index->Rebuild
I hope it helps anybody.
You can try rebuilding the index.
Right-click on the project in Project View. Then Index -> Rebuild.
Here is the solution I used after Project->C++ Index->Rebuild failed. This trick avoid deleting your current project :
1) Copy the current project (Right click->Copy from Project Explorer)
2) Paste it (Right click->Paste from Project Explorer) and give the copy another name
3) The indexer should now start and index both projects
4) When indexation is complete, you can delete the copy
PS: Make sure your original project is an actual C++ Project or this will obviously not work.
Convert a project to C or C++ nature:
Right click on project: New > Convert to C/C++ Project
In "Convert to C or C++": Choose C/C++ Project
In "Project options": Check "Specify Project Type"
...Project Type: Choose "Makefile project"
...Toolchains: Gross GCC
I was having the same problem and it turns out that the index folder was owned by root (I must have run Eclipse as a root once for some reason) I reclaimed the project folder using sudo chown -R username projectfolderpath and problem solved.
Execute eclipse.exe -clean -refresh where the eclipse is installed.
Create a new C/C++ Project in Eclipse with Given Source code folder path. (Not with New Project based on existing workspace)
Above steps worked for me.
For me it was issue that when creating a project indexer was chosen as none. Deleted the project and while creating the project again I chose the indexer options as per my need "LINUX_GCC", then it worked for me
Just came across the same problem in my C++ ARM Cross GCC project. I'm developing on Windows, using Makefile and an Ubuntu Docker image with GNU ARM Embedded Toolchain to build the project.
The solution to get rid of the unresolved symbols, in my case, could be divided into two parts:
The CDT Arm Cross GCC Built-in Compiler Settings didn't have the path to the compiler.
In the Project Properties -> C/C++ General -> Preprocessor Include Paths -> Providers(tab) the path to the compiler must be provided.
Using the GNU ARM Embedded Toolchain, the entry for the Command to get compiler specs: I currently use is:
C:\GNU_Arm_Embedded_Toolchain\9-2020-q2-update\bin\arm-none-eabi-g++.exe ${FLAGS} ${cross_toolchain_flags} -E -P -v -dD "${INPUTS}"
Note: Yes, I am having installed the same toolchain on my Windows machine as I'm using in the Docker image.
To verify, that the call is correct, you can tick the Allocate console in the Console View, which will provide hlepful output to the Console. Also, in the Entries tab, when you unroll the CDT Arm Cross GCC Built-in Compiler Settings you should see the includes and symbols included.
Missing symbol in the Project Properties -> C/C++ General -> Paths and Symbols menu.
As I have my defines in the Makefile, I forgot to add the define of my MCU also here.
Hope this helps to someone! :)
For the most part, the other answers tackle the situation wherein one "had" a working index earlier and things have gone astray for some reason.
On the other hand, I faced a problem wherein I needed to install everything from scratch (eclipse, workspace, c++ project etc.) and the indexing just wouldn't work. I finally found the solution here: https://www.eclipse.org/forums/index.php/t/1109004/
The key inputs from the above page are:
You need to setup include paths for the Indexer just as you would need
to for the compiler. The Indexer and compiler are completely independent.
The Indexer include paths are set by
Project -->Properties --> C/C++ General --> Preprocessor Include Paths, Macros etc. --> Entries tab --> CDT UserSettings Entries ...
and
You could try using
Project --> Properties --> C/C++ General --> Paths and Symbols
That's supposed to merge telling the compiler and Indexer
in one place.
However, this latter part of the suggestion did not work for me.
In my scenario I have a C++ project in CDT Eclipse. This projects however is rather a collection of individual (helper) programs than one complex application. Consequently I want to be able to build and run them individually.
My project structure is very simple and looks like:
src/app1.cpp
src/app2.cpp
src/...
Note that I do not have common header files or libraries. However I want to be able to add programs to this project just by creating e.g. src/appx.cpp
Ideally I want to have shortcuts for
"Build currently opened .cpp"
"Run binary of currently opened .cpp"
Any suggestions on how to achieve this behaviour, if possible without additional plugins?
The straightforward way to succeed what you aim is to create a Makefile project with CDT and add a new target rule for each of your applications inside your Makefile. You can even use SCons or other build systems with a CDT Makefile project and obtain the same effect.
You can also trick the managed build to create executables instead of object files. Remove -c option from Other flags of C++ compiler settings inside project properties. This will produce a separate application file for each of your source files.
Application files which are created inside the build directory will have the object file extension and they will not be executable. To solve this, you can add a post build script in your project directory such as:
postbuild.sh for Linux:
chmod +x *.o
rename -v 's/\.o$//' *.o
or postbuild.bat for Windows:
rename *.o *.exe
After adding ../postbuild.sh or ../postbuild.bat as a post build command in your build settings, you applications will be ready to run. Right click on any of these executable files and choose Debug As or Run As and a new Run configuration will be created.
Also you will have to stop the linker of the managed build to prevent errors. This can be achieved with changing the linker command to true (Linux) or true.exe (Windows, msys).
I have a program which consists of multiple projects in eclipse (working under ubuntu and the projects being in c++), these projects consist of a main executable file, and other shared objects files and static libs.
I want all these projects when built to output their files to one common binary folder, instead of their respective debug folders. This is to make linking easier with the main executable. If there are better solutions please also feel free to share.
Unfortunately, I have found that the C/C++ Build tab does not allow you to set the build location unless you are creating your own makefile.
You've likely found that the Builder Settings tab under Project Properties>C/C++ Build is all grayed out in a default C/C++ project. This is because CDT nominates the internal builder by default for new projects. To change this, you can go to Project Properties>C/C++ Build>Tool Chain Editor and change the Current Builder to Gnu Make Builder. Next, go to Project Properties>C/C++ Build and change the Builder Type to External Builder. You can now opt to create your own makefile for the project, if you like; though I'd recommend leaving CDT to build the makefile automatically for now.
I have the same project requirements of outputting to a /project_path/bin (though I still maintain separation between Debug and Release builds). To do this, I perform a copy operation on the output as a post-build step.
To do this, go to Project Properties>C/C++ Build>Settings and select the Build Steps tab. In the Post-build steps under Command:, enter:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "/path/to/bin/directory/";
Obviously replacing the "/path/to/bin/directory/" as required.
I personally prefer to maintain my project files in a workspace/build directory; copying binaries to a workspace/bin directory and libraries to a workspace/lib directory. At first I found this copy workaround to be an inconvenience, but have come to appreciate it because it isolates the interstitial build files from the final binary/library.
For binaries, I would use:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/bin/";
For libraries, I would use:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/lib/";
I include the variable "${BuildArtifactFilePrefix}" because CDT includes "lib" as a default prefix for static libraries, which I actually prefer.
You just need to ensure that the target directory exists before building; Eclipse/CDT will not create the directory for you.
Also, just remember that these copies will be left behind in the /bin or /lib directory on clean, but overwritten on any subsequent rebuild.
Try Project->Properties
Under C/C++ Build->Settings you have a tab called Build Artifact.
Under there you have Artifact name. This defaults as ${ProjName}.
Modify this to specify a relative directory path to where you actually want the final file to end up. So could be ../../lib/${ProjName}
The intermediate files (.o and .d) will still build to the sub-directory (Debug or Release) but I guess it's better off if they are there anyway and it is only the finally built library for which you want to change the build path.
If you find it inconvenient typing the relative path like this, I use Environment to create environment variables with relative paths taking me back to a "root". One of this I have is ${LIBDIR} and this is a relative path from where the project gets built. It is usually used for linking in other libraries, but can also be used as a target. Then you would set Artifact Name to ${LIBDIR}/${ProjName} which works well if you use different directories for debug and release builds.
Go to
Project Properties -> C/C++ Build -> Settings -> (tab) GCC C++ Linker
The command line pattern is shown on the right side
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${OUTPUT} ${INPUTS}
Put in front of ${OUTPUT}
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${ProjDirPath}/bin/${OUTPUT} ${INPUTS}
or
${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} MyMainProject/path/bin/ ${INPUTS}
From https://www.eclipse.org/forums/index.php?t=msg&th=207500&goto=665566&#msg_665566
In my project the build path defaults to the Build Configuration name, so I could use a ${ConfigName} macro to retrieve the build path in a post-build step:
${workspace_loc:/${ProjName}}/${ConfigName}/${BuildArtifactFileName}
Then you can copy target binaries to your common binary folder, or do something other in the build folder of that particular configuration.
If you open up the project's properties, there is a tab C/C++ Build. This has an option for build location, where you can specify the build directory. It seems you could change this for your multiple projects so that they share the same build directory.
Just happened to be working on something that led me down a similar path - so I'll offer it up as an alternate solution/reminder to myself:
In Eclipse (at least in Luna) the generated makefiles are actually rather decent and convenient. I personally like to create several build configurations (Release and Debug variants with 32 and 64 bit architectures), and supplement them with debug and run (F5 and Execute, respectively) configurations.
To continue: I have been toying with packaging on Debian and found - during the act of said toying - that I needed to create and test an install target. Eclipse neither generates for you, nor provides an interface to - a configuration - for customizing or adding an install target; Other than a place where you can specify that another target exists.
So technically Eclipse does provide an interface; kinda. Hence, I stumbled across the makefile.init, makefile.defs, and makefile.targets files.
Process/Workflow:
Create a file makefile.targets in the root directory of your eclipse project; In said file define an install target manually. This - of course - allows you to specify every little detail as you'd like, but with the added benefit of all of the configuration provided by Eclipse already complete and available to you for use with defining the rules for the specified target.
After defining the new target in the makefile.targets file, right click on your project's name or main cpp file in Eclipse's project explorer, and then select Make Targets->Build..., and finally Add to instantiate a pop-up. Alternatively, you could select 'create' in the last step instead of 'build' and it would provide the same pop-up required for the next part. Add the name of your new target and - leaving everything else at their default values - click ok
If you chose to add the new make target by right-clicking in Project Explorer and selecting Make Target->Build..., after adding the new make target you will be brought back to the first pop-up which resulted from selecting Build.... Otherwise, find your way to the Make Targets->Build.. pop-up now. Select the desired target and then click on Build.
Looking through Eclipse's auto-generated makefiles was an excellent way to learn the makefile syntax and overall structure, and get into some advanced usage of includes and conditionals.
Here are some portions of an example makefile, which - at least I hope - will demonstrate manually setting the output directory of a build:
prefix = /usr/local
bindir = $(prefix)/bin
sharedir = $(prefix)/share
mandir = $(sharedir)/man
man1dir = $(mandir)/man1
...
# Typical all target
all: <binaryname>
#Typical clean target
clean:
rm -f <binaryname> <objectname>.o
# Target invokes all, then installs to specified locations
install: all
install <binaryname> $(DESTDIR)$(bindir)
install -m 0644 <objectname>.1 $(DESTDIR)$(man1dir)