Somehow this is the first time I've ever encountered this problem in many years of programming, and I'm not sure what the options are for handling it.
I am in the process of porting an application to Linux, and there is a header file in one of the directories that apparently has the same name as a header file in the standard C library, and when "cstdlib" is included from another file in that directory, it's trying to include the local file rather than the correct one from the standard library.
In particular, the file is named "endian.h", which is trying to be included from /usr/include/bits/waitstatus.h. So instead of including /usr/include/bits/endian.h it is trying to include ./endian.h. makes no difference
Is my only option to rename the endian.h in the project to something else, or is there a way that I can force the compiler to look in the same directory as the file that it's being included from first?
Edit:
Okay it was just a stupid mistake on my part. My Makefile was setting -I. , so it was looking in the current directory first. D'oh.
There is an important difference between:
#include "endian.h" // Look in current directory first.
And
#include <endian.h> // Look in the standard search paths.
If you want the one in the current directory, use the quotes. If you want the system one, then use the angle brackets. Note that if you have put the current directory in the include path via the "-I" flag, then both might resolve to the one in the current directory, in which case you shouldn't use "-I" with the current directory.
If you include the file with "" instead of <>, the header should be first looked in the same directory as the file including it.
But if possible, renaming the file is much better IMHO: it will avoid problems if files are moved, when you change your build system, etc... The "" vs <> is compiler dependent, also (it is NOT mandated by the C standard to behave as g++ does).
Maybe you can look at the "-I" and "-I-" options?
Related
I'm kind of new to programming so please go easy on me. Anyways, I know about including header files that you, yourself, have defined. For example:
#include "yourHeader.h"
I'm trying to use FLTK for its GUI options, however, many of its header files include other header files using an include like this:
#include <FL/Blah.h>
instead of this:
#include "FL/Blah.h"
I would have to go every header file that has the include in angle brackets and change them to quotation marks for them to work. I am currently working in CodeBlocks right now, if that matters. Is there any way to include the header files using angle brackets instead of quotation marks, or am I stuck with having to go into the header files themselves and manually swapping them all out?
Generally， the header file from
#include "headerfile"
will searched in the current source path. If the search fails, it is reprocessed as if
#include <header file>
does.
Your FLTK library is using include like the following?
#include <FL/Blah.h>
The FL's parent path should be in the predefined INCLUDE path. You may edit you Makefile or project settings.
You can add the folder which contains all your headers to your include path while compiling.
How to add a default include path for GCC in Linux?
Some background
Ok there are two set of include search path.
The user include path:
This is usually only the current directory (also known as ".").
Note: It may be others but for simplicity lets just use "." in the examples below.
Then there is the system include path:
This is usually a few places in your machines (could be /usr/include and /usr/local/include).
Note: It may be others but for simplicity lets just assume these in the examples below.
How it usually works.
There are caveats and not all compilers work exactly the same. But the following are a good rules of thumb.
When you include a file using quotes "".
#include "yourHeader.h"
It will search for this file in all the directories specified in the "user include path". If it fails to find them there it will then look in all the directories specified by the "system include path". So your compiler will search for the following files:
./yourHeader.h
/usr/include/yourHeader.h
/usr/local/include/yourHeader.h
It will use the first one it finds.
When you use the <> in the include:
#include <FL/Blah.h>
It will search for the files in the "system include path" first. Then depending on your compiler may optionally search the "user include path" (but lets assume not for now).
So in this case it will search for the files:
/usr/include/FL/Blah.h
/usr/local/include/FL/Blah.h
It will use the first one it finds.
Modifying the Default
So these are the default paths that will be searched for a file. But your compiler will allow you to add extra paths to both of these search paths (usually). It depends on your compiler how to add search paths.
For gcc (and probably clang) it uses -I and -isystem (and probably more)
Expectations.
When you see <> in the include header it usually means this is an already installed library that you are looking for. So your code assumes that the FLTK library has already been installed on your machine.
When you see "" in the include header you should assume that it is a local file that belongs to the project.
I use a code with different libraries, which use names like defines.h. This does not only cause conflicts for identical filenames, but also creates confusion. From which library is the defines.h include?
Including as #include <library/defines.h> would be a clean solution, but then the include path would need to be the parent directory of the library, which is rather unclean again.
Is there some way to alias the include path, so that -I/path/to/library makes the headers available under library/headername.h?
Is there some way to alias the include path, so that -I/path/to/library makes the headers available under library/headername.h?
There seems to be no need to in this case. You can simply use -I/path/to which makes /path/to/library/headername.h available under library/headername.h.
That said, while there is no such compilation option (that I know of), you can create such "aliases" to file paths in most file systems. These aliases are called symbolic links. In this case, you could make a link /path/to/library/mylibrary that points to . which would make /path/to/library/headername.h available under mylibrary/headername.h assuming you've used -I/path/to/library.
At least on unixy systems, when you compile and install a library, headers are installed for example to
/usr/lib/libraryname/*.h
Or maybe something like
/opt/libraryname-1.2/include/libraryname/*.h
And then if necesssry (not installing to compiler's default include search path), right dir is added with compiler option, for gcc for example option
-I/opt/libraryname-1.2/include
Then just always do this in source code, trusting build system to have included the right search paths:
#include <libraryname/includefile.h>
There are already many options listed of how to add a path to a C++ compiler so that the #include <...> command works on these paths. However, assume that I have a single file (not an entire project) and I want to add an include path just for this file alone. I'd like to do this via a line of code within the cpp-file (say, as very first line). How is this possible? Why? Because I need to include some header file from another directory which in turn depends also on other header files within that same directory (and I get error messages that these other files could not be found due to the fact that this path was not added to the include-list).
For example:
Let's assume I want to include file_a.h in directory
.../include/extra,
I can do that via
#include <extra/file_a.h>
However, if, e.g., I do not have the extra-directory directly as a sub-directory of include, or the file_a wants to include some other file from somewhere else (maybe even /extra, but it's not a sub directory of include e.g.), then I run into trouble, because then the tracking of directories/dependencies gets hard.
I thought it would be a bad habit to change those directories via compiler, so I thought better solution would be to integrate it into the program, so no matter which compiler I use, it would work anyway without even having to think about afterwards, once specified, which directories I have to add.
Per my understanding you did:
#include <absolute/path/to/header/header.h
or
#include <relative/path/to/header/header.h
But into the header.h some other include are included.
#include <header_1.h>
#include <header_2.h>
[...]
#include <header_n.h>
Those other headers haven't relative/absolute path, so compiler doesn't know how to find them.
To solve this you can use (using gcc) the -I compiler option:
-I dir
Add the directory dir to the list of directories to be searched for header files during preprocessing. [...]
Emphasis mine
So you can use
#include <header.h>
In your file and compile it using
gcc ... -I/path/to/headers ...
When you have to specify one or more include paths in the compile command, you can do it as follows:
g++ -I/path1/to/headers -I/path2/to/headers YourProgram.cpp
Include paths tell the compiler where it finds the files it actually shall include into other files. This is (usually) controlled via compiler options as LPs explained in this answer.
C++ standard does not provide any facilities to do this from within a C++ source file and I am not aware either of any compiler extension of any vendor that would allow doing so, so bad luck...
Now depending on the IDE you are using (hopefully you are using one...), though, you most likely can add include paths for files individually there (would be a strange IDE if it didn't allow...), e. g. with eclipse + GCC, right click the file, select "Properties" -> C/C++ Build -> Tool Settings -> GCC C++ Compiler -> Includes.
Alternatively you could use a make file instead (actually, eclipse in standard settings generates one for you automatically...), which again allows you to set compiler options for each file individually - either written directly by yourself or generated by some other tools facilitating this such as cmake.
I find #include "../app/thing.h" very ugly and I would like to be able to import from the main root of my project, like this:
#include <project/app/submodule/thing.h>
(I know <> is generally used for external but I find it very cleaner)
How can I do that, from anywhere in my project?
You simply need to ensure that your build process sets an option to specify the starting point of the search.
For example, if your header is in:
/work/username/src/project/app/submodule/thing.h
then you need to include (assuming a POSIX-compliant compiler; AFAICR, even MSVC uses /I as the analogue of -I):
-I/work/username/src
as one of the compiler options. You can use that path from anywhere in your project since it is absolute. You just need a defined way for your build system to know what the setting should be, so that when it is moved to /home/someone/src/, you have only one setting to change.
See this answer for a more complete explanation about how the differences between the two formats work. Honestly, though, I think you might want to consider restructuring your folder hierarchy if you need to jump up a folder then jump into another folder to get something. Generally speaking, it's pretty common practice to keep all files local to your program local to each other in the folder structure (i.e. in the same folder), and all files that aren't local, but may be needed (such as header files for libraries used) in a sub-folder within the main program folder, or to include them at compile time.
It is important to note that in the answer I linked above, it explains that "<>" includes are IMPLEMENTATION DEPENDENT, so we'd really need to know what compiler you're using to tell you if you could or couldn't do that.
You can simply use the include directories option of your current compiler (-I usually) to achieve this.
Also note using the "" double quotes will just add to fallback for the compiler standard headers. Files included using the <>, are only guaranteed to search files from the compiler standard headers.
This question already has answers here:
What is the difference between #include <filename> and #include "filename"?
(30 answers)
Closed 8 years ago.
I am new to C++.
What is the difference between including the c++ header files using "" and <>
I am trying to use some of the header files form an open source library. All header files in that library are included using <>. Now when I do the same in my header file, its failing at compile time.
<> looks firstly in the header path for the header file whereas "" looks firstly in the current directory of the file for the header.
The distinction is very largely implementation defined; the "..." form
should look first in the place where the file which includes it is
situated; the <...> no. Beyond that, both look in an implementation
defined list of places, with the additional requirement that if the
compiler doesn't find a "..." form in any of the expected places, it
reprocesses the include as if it were a <...> form.
In practice, all of the compilers I know build a list of places using
the -I or /I options, followed by a number of "standard" and
compiler defined places. This list is for <...>; "..." is searched
in the same directory as the including file, then treated as a <...>.
(Some compilers, at least, also have options to add to the list for
"...".)
I'm not sure what's happening with regards to the library. Normally,
when using a third party library, you have to add one or more -I or
/I options to tell the compiler where to find its headers. Once
you've done that, both your code and the library code should find all of
the necessary headers. The one case I can think of where an include
might work in a library header, and not in your own headers, is a
"..." style include in a library header which was included from
another library header, using a path specifier, e.g.:
LibraryFile1.hpp:
#include "Subdir/LibraryFile2.hpp"
LibraryFile2.hpp:
#include "LibraryFile3.hpp"
You will have told the compiler to look for the headers (using a -I
option) in something like LibraryRoot/include, which is where
LibraryFile1.hpp is located; LibraryFile2.hpp is relative to this
location, and in LibraryFile2.hpp, the compiler finds
LibraryFile3.hpp because it is in the same directory as the file which
includes it. If you try to include LibraryFile3.hpp directly,
however, the compiler won't find it.
File includes between <> are looked for in your compiler's path, whereas "" is looking relatively to your current directory (or absolute if you specify a path that starts with / or c:\ but this is not recommended)
On Unix systems, by default the path contains /usr/include. This path may be completed by adding -Isome_directory for it to search in it.
For example, if you have your file test.c and you want to include include/test.h, you have different choices:
Write #include "include/test.h", which will look relatively from the directory of the compiled file.
Write #include <test.h>, but this time you will need to specify -Iinclude to the compiler to add the ./include directory to the compiler's path.
Note, however, that some compilers accept the "" notation for lookups in the path, but that always confused me and is a bad thing to do.
The quotes mean include from local folder and the <> mean to include from another directory specified using a flag to g++ or MSVC or whatever compiler you are using or system headers.
<> looks in the default directory for include files, "" looks in the current directory and than in the default directory
This question is a duplicate of Question 21593. None of the above answers above are totally correct. Like many programmers, I have used the informal convention of using the "myApp.hpp" form for application specific files, and the form for library and compiler system files, i.e. files specified in /I and the INCLUDE environment variable. However, the C standard states that the search order is implementation specific.
Here's the msdn explanation copied here for your convenience).
Quoted form
The preprocessor searches for include files in this order:
1. In the same directory as the file that contains the #include statement.
2. In the directories of the currently opened include files, in the reverse order in which
they were opened. The search begins in the directory of the parent include file and
continues upward through the directories of any grandparent include files.
3. Along the path that's specified by each /I compiler option.
4. Along the paths that are specified by the INCLUDE environment variable.
Angle-bracket form
The preprocessor searches for include files in this order:
1. Along the path that's specified by each /I compiler option.
2. When compiling occurs on the command line, along the paths that are specified by the INCLUDE
environment variable.
Including a file using <> will tell the compiler to look for those files in environment-defined inclusion folders. Those folders can be standard system folders, or defined by your Makefile if you use one, etc. Using "", the compiler will look for inclusion files only in the source file's path.
So you can use "" and use absolute paths or the path which is relative to the source file you try to include in, or you can use <> after defining your inclusion folders, and just specify the name of the header file to include.
IMHO, the second option is better, especially if you use a lot of headers, or multiple libraries, etc...
To define inclusion folders at compilation time : gcc -I ... (man gcc!)