I am trying to use OpenBabel and am experiencing great difficulty with setting up a global search path for include files. I have successfully linked to the libraries with $LD_LIBRARY_PATH, but when compiling with the GNU C++ compiler, it cannot find the include files. Is there a global include environment variable on Linux, and if so, what is it?
You could give the include path to GCC using the option -I:
g++ -I/path/to/the/include/dir blabla
Please note that also the library dir may be bassed via -L option -L/path/to/lib/dir. LD_LIBRARY_PATH is usually considered a dirty hack.
You can have multiple -I (and -L) options:
g++ -I/dir/include1 -I/dir/include2
If you check the manpage for cpp (the C Preprocessor), it state that it will treat the following environment variables like the -I option mentioned above:
CPATH
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
Now, I believe that current g++ and gcc use an inbuilt cpp, but I would expect that it would function like the stand alone cpp, and respect these environment variables.
Related
I know this one way of adding include paths to clang:-
clang++ -I <dir> a.cpp
but with this, that path is only added for that particular file, and u have to write that every time linting, so how can I add some include paths globally to clint.
There are also some environment variables which Clang looks at for include paths. For c++, they would be CPATH (both C and C++) and CPLUS_INCLUDE_PATH (C++ only) (And LIBRARY_PATH for the linker). So you can add something like this to your shell startup file if you are using bash or similar:
export CPLUS_INCLUDE_PATH="${CPLUS_INCLUDE_PATH:+${CPLUS_INCLUDE_PATH}:}<dir>"
And you could also just alias clang++ with clang++ -I<dir>.
i just started with c++ programming.
For my new work, i have to download, install and take use of an external library. It is called ICE.
It was composed as a .tar file, so i decomposed it inside my home-directory "/home/foo/ice".
Now, there is the directory: "/home/foo/ice/src", within all the .h headers, i need for the program.
But can i tell the compiler, where he can find all these new headers?
I mean only with #include, he obviously doesn't know.
What i need:
#include <image.h>
"image.h" is inside "/home/foo/ice/src"
Greetings
If you have gcc compiler you can use -I option.
From the manual :
-I dir: Add the directory dir to the list of directories to be searched for header files.
So for you it should be something like this:
g++ myprog.cpp -I /home/foo/ice/src -o myprog
But it is better to install the library, you should have some readme.txt or INSTALL file about how to do this..
You asked about linking a library, but your description shows that you have problems with the include path, which klm123 answered already.
The library paths for linking is another option, usually -Llibpath
It may help to check the options of you compiler, here for example the Directory Options of GCC
Let us assume that in first.h we have #include "aaa/second.h" and in the aaa/second.h we have #include "bbb/third.h". I think that in the "default settings" the compiler will complain if "third.h" is not located in "aaa/bbb".
Is it possible to change this behavior in such a way that the directory, in which the first.cpp is located is used to construct the full names in all includes?
For example, if "first.h" is located in '/home/bucky/' then #include "bbb/third.h" (from "aaa/second.h") should be interpreted as /home/bucky/bbb/third.h and not as /home/bucky/aaa/bbb/third.h.
EDITS
I cannot change the whole source code. In the code quotation marks are used instead of angle brackets.
I compile using g++ -std=c++0x name.cpp -o name in the command line. I do it in two different terminals. It looks like in the first terminal the working directory is used to construct the full names and in the second terminal it is not the case. I am almost sure that it happens because of the environment variables but I do not know which ones. So, my question is, to larger extent, what environment variables can force the compiler to construct full names using the working directory.
EDIT 2
In my test.cpp file I include "first.h". This inclusion does not cause any problem (complier sees "first.h"). The "first.h" file includes "ppp/second.h". It also causes no problems. But "ppp/second.h" includes "ppp/third.h" and this is the place where the problem appears. I think that the reason of the problem is that "second.h" tries to find "third.h" in the "ppp" subdirectory of the directory where second.h is located. In other words, second.h tries to find the third.h in the "ppp/ppp" subdirectory (because second.h is located in the ppp subdirectory).
In another terminal, the same compilation command, in the same directory does not cause any problem. The reason, is obviously in the values of the environment varibales.
Yes. The exact mechanics depend on the compiler but the short and the long of it is that you need to configure your compiler to include the project path in the search path. For GCC and clang that’s done via the -I command line flag (-I path/of/first.cpp). This configuration would usually be done in the project settings (if you’re working with an IDE), a Makefile or similar.
Since you’re talking about environment variables: the flags that are passed to the g++ and c++ compiler are controlled by the CXXFLAGS and CFLAGS variables.
You should set up include paths for your project globally. In your example, you would pass some option like -I /home/bucky to your compiler (if it is GCC or Clang). MSVC has analogous options.
(All #includes are searched relative to the include paths. The difference between <...> and "..." is that the latter also searches the current directory.)
I have a linux system at my workplace with pretty old packages and no root access. I'm compiling packages that I need from source with --prefix=[somewhere in homedir]. My problem is that I just can't find out how to convince configure to look for header files in a specific directory. The source is cpp. I tried with environment variables related to g++ and looking up flags and googling but I had no success. Can someone help me solve this?
Usually you can pass additional compiler flags inside CXXFLAGS. For gcc you can specify more include directories with -I/some/dir, e.g.
$ ./configure CXXFLAGS="-I/some/dir/"
where /some/dir/ contains your headers.
The normal way to do this is --with-<feature>=<header directory>.
CPPFLAGS = C Preprocessor Flags, these flags will be used for C and C++ compilation.
CFLAGS = C Flags, these flags will be used when compiling C.
CXXFLAGS = C++ Flags, these flags will be used when compiling C++.
The -I flag specifies an additional include directory to be used during compilation.
Generally it's a good idea to use CPPFLAGS when specifying include directories, that way you know it will be used even if the project has some source that is compiled as C.
Of course, there might also be circumstances where you only want the include directory to be used by C or C++, but not both. In which case you would obviously be better served by using CFLAGS or CXXFLAGS instead.
It's better to use CPPFLAGS to specify include directories.
./configure CPPFLAGS="-I/your/whatever/includedir"
I am wondering how compilers on Mac OS X, Windows and Linux know where to find the C header files.
Specifically I am wondering how it knows where to find the #include with the <> brackets.
#include "/Users/Brock/Desktop/Myfile.h" // absolute reference
#include <stdio.h> // system relative reference?
I assume there is a text file on the system that it consults. How does it know where to look for the headers? Is it possible to modify this file, if so where does this file reside on the operating system?
When the compiler is built, it knows about a few standard locations to look for header file. Some of them are independent of where the compiler is installed (such as /usr/include, /usr/local/include, etc.) and some of the are based on where the compiler is installed (which for gcc, is controlled by the --prefix option when running configure).
Locations like /usr/include are well known and 'knowledge' of that location is built into gcc. Locations like /usr/local/include is not considered completely standard and can be set when gcc is built with the --with-local-prefix option of configure.
That said, you can add new directories for where to search for include files using the compiler -I command line option. When trying to include a file, it will look in the directories specified with the -I flag before the directories I talked about in the first paragraph.
The OS does not know where look for these files — the compiler does (or more accurately, the preprocessor). It has a set of search paths where it knows to look for headers, much like your command shell has a set of places where it will look for programs to execute when you type in a name. The GCC documentation explains how that compiler does it and how these search paths can be changed.
The location of the file is system dependent. Indeed, the file might be precompiled, or it may not even exist—the compiler may have it as a 'built-in'. On my macbook, I see that there's such a file in /usr/include/c++/4.2.1/iostream, but you shouldn't rely on it, and it's definitely a bad idea to edit it.
If you were using g++, you could do something like this to find out what include paths were searched:
touch empty.cpp
g++ -v empty.cpp
I don't know if there's an equivalent for Xcode. Maybe that will work since Xcode is based on GCC?
In Visual Studio, it's either in the project settings if you use the IDE, or in the %INCLUDE% environment variable if you use the command line.
You should avoid #include-ing files using absolute paths. The compiler searches for the include files in various directories and includes files, starting from each directory. For example;
#include <boost/tokenizer.hpp>
Works because the boost root directory contains a folder called 'boost' and that folder is either in your default include path or you did something like.
g++ -I$BOOST_ROOT {blah, blah}
It is C and C++ standard that the UNIX separator '/' will work the same way for all systems, regardless of what the host system actually uses to denote directories. As others of mentioned, occasionally #include doesn't actually include a real file at all.