I use 2 different GCC versions on the same CentOS machine (included in OS one and custom one), and I don't want to replace system GCC with my custom one, I use custom one to build some software only.
The problem is that Qt Creator adds /usr/include to include folders automatically, so custom GCC starts to use system C++ includes and crashes with strange error messages like error: '::memchr' has not been declared. I don't have /usr/include anywhere in my *.pro file, so it looks like Qt Creator adds them itself.
How to prohibit Qt Creator project to use some specific include patches to allow compilation on machine with 2 GCC versions? When I use Eclipse CDT on the same machine, it works excellently, because Eclipse doesn't add anything itself and only uses include directories specified by me.
You can use CXXFLAGS += -nostdinc.
This should do the following (excerpt from the manual):
Do not search the standard system directories for header files. Only the directories you have specified
with -I options (and the directory of the current file, if appropriate) are searched.
It is not elegant answer, if someone has better ideas, you are still welcome to post your answer and I'll accept it.
So, I added custom build step between qmake and make commands, and I use sed command in this custom build step to edit Makefile on the fly and remove extra includes. This solution works, however, it is ugly.
Related
I'm learning to use OpenCV (and C++) in Codeblocks. What confuses me, however, is that when I start to include header files from OpenCV in my main.cpp file, Codeblocks automatically suggests to me the files as shown in the image below.
I have not included any search paths to project build options, so how is this possible that Codeblocks can find the files? Is there some other variable working here that I'm unaware of?
Note that I'm a beginner with both Codeblocks and OpenCV and that I only have a little experience with C++.
Thank you
Of course when you install an IDE like code::blocks by default, it knows about standard path for library on your OS.
On my OS -> Ubuntu that is /usr/include
It only searches on a standard path, except you add one. If you install your library by command-line, it goes to the standard place, if you installed manually, then it depends on your option you added to installation. I can not see you screen-shot but it has access to /usr/include by default.
For more detail on Linux and OpenCV
And here is a screen-shot of codeblock on Ubuntu that I added some 3rd-party library
NOTE:
if you install any libraries by command-line, just use it.
But if you have installed them manually, you need to add 2 things to codeblock.
1. First is your path for header file
2. Second is your path for linker
And you see it in screen-shot that say: Search Directory
First is for header and second is for linker
I am trying to get Xcode 5.1.1 to find the headers of GSL. My ideal solution would be one that would allow me to access these headers on all future projects with no extra work (automagically if you will). Most instructions seem to say to add the library path under the project's Build Setting -> Search Path section, however, my project does not seem to have a library or header option there. I have also tried to use the Link Binary with Libraries under the Build Phases tab, but /usr/local/include is "invisible" and I am reluctant to move these headers from their install location (unless this is normal/acceptable). Lastly I have tried to edit the Source Trees preference to add the library path, but this does not seem to work either. I wouldn't be surprised if I was doing that last part incorrectly as I am rather confused about the proper way of doing it.
This solution works on Xcode 5.1
In the side view click on your project, there should be a tab that can either be set to "Basic" or "All," select "All." Under the subsection labeled "Linking" there should be a field called "Other Linkers" enter these flags:
-I/usr/local/include
-L/usr/local/lib
-lgsl
-lgslcblas
I have a project which is built using cmake.
This project is uses avr-gcc to compile the binaries and I use boost mpl for some parts of it.
As avr-gcc does not have /usr/include as a default include path but boost is installed there, I need to add it as an include path such that boost is found.
Unfortunately, adding -I/usr/include to the command line pulls in all other files and directories in /usr/include which seems to introduce collisions with the avr includes and thereby compiler errors.
My initial solution involved a softlink to /usr/include/boost in one of my user defined include directories to resolve the
#include <boost/mpl/*>
However, I thought this to be not very platform independent and decided for cmake to add the include path for boost. This again led to "-I/usr/include" being present on the compiler command.
How do I solve this in a platform agnostic manner?
A solution would be to let cmake create the link for me to get the right include directory.
However, I consider the whole symbolic link solution ugly.
Is there something better that I can do?
For example: Is there some option that adds an include path under an alias like:
-I/usr/include/boost:boost
Which would add only the boost subfolder under the name boost to be includable by the #include <boost/...> directive?
I see at least two options for you:
Where does avr-gcc include files from by default? Let's say it is /opt/avr-gcc/include for concreteness. Then what may work for you is -I/opt/avr-gcc/include -I/usr/include.
Another option is to install Boost in a different directory and use that instead of the Boost in /usr/include. For example, you might create /opt/boost and then use -I/opt/boost (or a sub-directory under that) on the command line.
I am trying to use Eclipse on an existing collection of folders with C++ and recursive Makefile files in Linux. The make files use gcc and ar, and the user specifies the path to the gcc he wants to use in the Makefile. The make files that I will be working with were typed by hand.
In Eclipse, there is an option to create a new project that looks appropriate for what I need: "Create a new Makefile project from existing code in that same directory".
* <none>
* cross GCC
* GNU Autotools Toolchain
* Linux GCC
Here I have two questions:
Which toolchain should I choose? and how does Eclipse use this information?
I would like Eclipse to infer as much as it can from the top-level Makefile (e.g. include paths, make targets, etc) . How can I do this?
Your question is very similar to what I have setup for my project.
If the target platform that the application is expected to run on is the machine you are compiling on, the you ought to select Linux GCC.
If the target platform that application will run on is eg an ARM processor, you need to specify cross GCC.
The GNU Autotools Toolchain is designed to build source-code packages on different linux systems.
By selecting "Create a new Makefile project from existing code in that same directory" eclipse will assume that the user's makefiles will manage the build itself.
For eclipse to infer include paths, have the discovery options enabled in the project settings. Admittedly, your top-level make needs to specify include path, source-code paths etc.
You really can only eiter allow Eclipse to create the makefile for you based on what you have in your project or tell it which command to run when you select 'build'. Mixing these options I have found doesn't really work. If you are specifying the Makefile then the compiler used doesn't really matter either since the Makefile will define that. Just pick an 'empty c++ project' when you create a new project, make sure you specify not to use the 'default workspace' location and point this input box to your code base instead. In the project c++/build settings make sure that the "automatically generate makefile" is unchecked and specify what command should be executed to make your project. (usually this is 'make all' but it might be different for you)
I am running into a problem I have not been able to avoid. Redhat 6 (or most linux packages) comes with a default QT package installed with headers/etc in the /usr/lib and /usr/include folders.
Now, I am wanting to link against a newer version of QT without removing the older version. Unfortunately, since the headers are in the /include/ folder, gcc automatically finds them, and then uses the wrong include files (instead of those which I have elsewhere).
I cannot seem to stop the compiler from automatically doing this. I have gotten around it previously by simply manually removing the old libraries/headers but this is a terrible solution long term.
I do not think this problem is specific to QT either, it just happens to be my current instance of it.
Any suggestions?
Many thanks :)
If you give the include directories of the newer Qt installation through -I option, it should be searched before the standard include directories (i.e. /usr/include, etc.) Removing the standard include directories from the search path completely is likely not a good idea because standard headers will also be found there (note that the Qt headers themselves most likely include standard headers and will not work if those are not found).
However if you really don't want the standard include directories to be searched, the option -nostdinc should do what you want.
My issue turned out to be related to an incorrect version of qmake being used. It was finding a previous version of qmake, and even though it was from qt4, it was linking to the wrong includes.
Updating the qmake paths worked to fix this issue.