Where is the -I (captial i) path relative to in g++? - c++

I am in the App folder of my project. I run the following command to compile character.cpp
g++ -Wall -std=c++11 -I../App -c Character/character.cpp -o Obj/character.o
which is in App/Character directory. character.cpp has the following include
#include "Inventory/inventory.hpp"
where the folder of inventory.cpp is App/Inventory.
I thought because I am running the g++ command from App, the default include path would start from App and therefore I wouldn't need to have the -I../App part of the command. To me this seems to be saying "move one level higher than App then move into App and include from there" which seems redundant but without that line it doesn't work.
Can anyone explain why?
EDIT
Looking at it again and some more documentation, I believe that if no -I path is specified, g++ will look in its default directories and then all other includes (like the one I have causing problems) are relative to the file that includes them. So I have to add the -I part to say "look in the App directory too" and since it doesn't like just -I, I have to use ../App because that is equivalent to not moving at all. Can anyone confirm if this is at all accurate?

You can use -I. for searching headers from the current directory, instead of -I../App.
This include preprocessor directive
#include "Inventory/inventory.hpp"
forces gcc (g++ or cpp) to search the header not from the current path (App/), but from directory of your source file (App/Character):
/root/App# strace -f g++ -c -H ./Character/character.cpp 2>&1 |grep Inven
[pid 31316] read(3, "#include \"Inventory/inventory.hp"..., 35) = 35
[pid 31316] stat64("./Character/Inventory/inventory.hpp.gch", 0xbfffe6a4) = -1 ENOENT (No such file or directory)
[pid 31316] open("./Character/Inventory/inventory.hpp", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
..then try system directories
This is documented here: https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
GCC looks for headers requested with #include "file" first in the directory containing the current file
This behavior can be not fixed in the Language standard (ISO C), and is implementation-defined (as commented by Richard Corden and answered by piCookie in What is the difference between #include <filename> and #include "filename"?):
specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner.
But this is the way the C compiler should work under Unix, according to Posix, aka The Open Group Base Specifications Issue 7:
Thus, headers whose names are enclosed in double-quotes ( "" ) shall be searched for first in the directory of the file with the #include line, then in directories named in -I options, and last in the usual places. For headers whose names are enclosed in angle brackets ( "<>" ), the header shall be searched for only in directories named in -I options and then in the usual places. Directories named in -I options shall be searched in the order specified.
It is useful when your current directory is far from the source directory (this is the recommended way in autotools/autoconf: do mkdir build_dir5;cd build_dir5; /path/to/original/source_dir/configure --options; then make - this will not change source dir and will not generate lot of file in it; you can do several build with single copy of source).
When you start g++ from the App directory with -I. (or with -I../App or -I/full_path/to/App), gcc (g++) will find the Inventory. I added warning to the header to see when it will be included; and -H option of gcc/g++ prints all included headers with pathes:
/root/App# cat Inventory/inventory.hpp
#warning "Inventory/inventory.h included"
/root/App# cat Character/character.cpp
#include "Inventory/inventory.hpp"
/root/App# g++ -I. ./Character/character.cpp -H -c
. ./Inventory/inventory.hpp
In file included from ./Character/character.cpp:1:
./Inventory/inventory.hpp:1:2: warning: #warning "Inventory/inventory.h included"

Related

How to specify location of angle-bracket headers in gcc/g++?

Is there a way to tell gcc/g++/clang where to look for headers that are included via angle brackets ("<", ">")?
I don't use the angle bracket convention for non-system files, but the problem is that when I try using the headers from some packages I download, I get errors for all of the included files.
For example, say I want to include headers from a module called Foo that I download:
/foo-v1.0/include/DependencyA.hpp:
#ifndef DEP_A_HPP
#define DEP_A_HPP
class DependencyA
{
...
};
#endif
/foo-v1.0/include/Api.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include <Foo/DependencyA.hpp>
void doSomething(DependencyA* da);
#endif
Then, in my own code:
/mycode.cpp:
#include "/foo-v1.0/include/Api.hpp"
DependencyA* da = new DependencyA();
doSomething(da);
I get a compile error:
fatal error: 'Foo/DependencyA.hpp' file not found
I've tried building with:
clang -c mycode.cpp -isystem./foo-v1.0/include -o mycode.o
clang -c mycode.cpp -isystem./foo-v1.0/include/ -o mycode.o
clang -c mycode.cpp -I./foo-v1.0/include -o mycode.o
clang -c mycode.cpp -I./foo-v1.0/include/ -o mycode.o
and so on, to no avail.
How do I tell the compiler to resolve <Foo/**/*> to a particular root directory for every included file?
The answer is already in the comments.
To check include dirs one can use the method described here: What are the GCC default include directories? , preferably with - replaced with /dev/null:
clang -xc -E -v /dev/null
On my machine for clang it gives
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/clang/11.0.0/include
/usr/include
End of search list.
To discover how to manipulate this list, it suffices to read the gcc (or clang) manual (man clang or find it in the Internet, for example, https://man7.org/linux/man-pages/man1/gcc.1.html ). For gcc this reads:
Options for Directory Search
These options specify directories to search for header files, for
libraries and for parts of the compiler:
-I dir
-iquote dir
-isystem dir
-idirafter dir
Add the directory dir to the list of directories to be searched
for header files during preprocessing. If dir begins with = or
$SYSROOT, then the = or $SYSROOT is replaced by the sysroot
prefix; see --sysroot and -isysroot.
Directories specified with -iquote apply only to the quote form
of the directive, "#include "file"". Directories specified with
-I, -isystem, or -idirafter apply to lookup for both the
"#include "file"" and "#include <file>" directives.
This description is followed by a detailed description of the order in which header files are searched and by some recommendations as to which option to use for which purpose. You'll find it in the manual. Search for "Options for Directory Search".
What I really don't like in your code is this line:
#include "/foo-v1.0/include/Api.hpp"
It seems to contain the absolute path to the header and I've never seen anything like this. I would change it to
#include "Api.hpp"
with /foo-v1.0/include being added to the search list via the usual compiler -I command-line option.

Does g++ not take header files from the first include path it exists in?

I'm trying to build a third party tool. I'm not very familiar with the C++ build tools, and I'm not sure how this should be resolved.
dcp2icc.src/dcp2icc.cpp line 6 is:
#include "dng_camera_profile.h"
dng_sdk_1_2/dng_sdk/source/dng_camera_profile.h line 39:
#include "dng_hue_sat_map.h"
There are two dng_hue_sat_map.h files:
$ ls -l dng_sdk_1_2/dng_sdk/source/dng_hue_sat_map.h fixes/dng_sdk/dng_hue_sat_map.h
-r--r--r-- 1 user users 3141 Apr 9 2008 dng_sdk_1_2/dng_sdk/source/dng_hue_sat_map.h
-rw-r--r-- 1 user users 3124 Oct 31 2015 fixes/dng_sdk/dng_hue_sat_map.h
Finally, this is the command which gets run:
g++ -o build/dcp2icc/dcp2icc.o -c -m32 -O2 -iquote- -DUNIX_ENV=1 -D_FILE_OFFSET_BITS=64 -DkBigEndianHost=0 -Idcp2icc.src -Ifixes/dng_sdk -Idng_sdk_1_2/dng_sdk/source -INone dcp2icc.src/dcp2icc.cpp
I expected that because -Ifixes/dng_sdk comes before -Idng_sdk_1_2/dng_sdk/source, fixes/dng_sdk/dng_hue_sat_map.h would be used, but this is not the case:
In file included from dng_sdk_1_2/dng_sdk/source/dng_camera_profile.h:39:0,
from dcp2icc.src/dcp2icc.cpp:6:
dng_sdk_1_2/dng_sdk/source/dng_hue_sat_map.h:129:8: error: extra qualification 'dng_hue_sat_map::' on member 'operator==' [-fpermissive]
bool dng_hue_sat_map::operator== (const dng_hue_sat_map &rhs) const;
^~~~~~~~~~~~~~~
How does g++ choose which file to use when the header file exists in two include locations? Does it matter which sequence the includes are in, and if so, how?
man g++ simply has this to say:
-I dir
Add the directory dir to the list of directories to be searched for header files. Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the special treatment of system headers are not defeated . If dir begins with "=", then the "=" will be replaced by the sysroot prefix; see --sysroot and -isysroot.
The GCC spec says the following, which as far as I can tell is the opposite of what I'm seeing:
You can specify multiple -I options on the command line, in which case the directories are searched in left-to-right order.
You're using the #include "..." form, rather than the #include <...> form.
The file dng_sdk_1_2/dng_sdk/source/dng_camera_profile.h is including "dng_hue_sat_map.h". #include "..." first searches relative to the file doing the including, so it first searches in dng_sdk_1_2/dng_sdk/source, regardless of -I options.

Atmega, avr-gcc, assembly include file from another directory

I can't convince avr-gcc on windows to include a *.h file from another directory:
>avr-gcc -Wa,-gdwarf2 -x assembler-with-cpp -c -mmcu=atmega256rfr2 halW1.S
C:\Users\me\AppData\Local\Temp\ccjzoYpN.s: Assembler messages:
C:\Users\me\AppData\Local\Temp\ccjzoYpN.s:6: Error: can't open halGccD.h for reading: No such file or directory
The required file is one up level in ../include folder
(this is the BitCloud stack provided by Atmel itself)
I tried as Atmel Studio does to pass include folder:
>avr-gcc -Wa,-gdwarf2 -x assembler-with-cpp -c -mmcu=atmega256rfr2 halW1.S -I "..\include"
But seems that avr-gcc assembler ignores the -I option. I tried with relative, absolute, even put that path in global PATH.
If I copy required *.h in the same folder where *.S file resides, it's working.
What is wrong?
Ok, found'it by mistake.
In case anyone needs, -I is not working alone for assembly files. When using avr-gcc as assembler, explicit assembler (-Wa) or linker (-Wl) directives must precede others. Such as:
-Wa,-I"..\..\path_to_h"
Also pay attention to backslash (not slash)... the old windows problem.
Seems that avr-gcc should parse correctly, but is not.

Instruct compiler to ignore header prefix found in a #include

[As Cornstalks explained below, I'm trying to strip a header prefix that's used in an #include. So it appears this question is not a duplicate of How to make g++ search for header files in a specific directory?]
I'm making some changes to a library. I have the library locally, so its not installed in its customary system location.
I have a test source file and its sided-by-side with the library. The test file has a bunch of includes like:
#include <foo/libfoo.h>
And it also has a bunch of customary includes, like:
#include <iostream>
I'm trying to compile the test file using:
$ g++ ecies-test.c++ -I. -o ecies-test.exe ./libcryptopp.a
And (the space between -iquote . does not appear to make a difference):
$ g++ ecies-test.c++ -I. -iquote . -o ecies-test.exe ./libcryptopp.a
The problem I am having is I don't know how to tell g++ that <foo/libfoo.h> means "./libfoo.h". Effectively, I'm trying to strip the prefix used to include the header. I've looked in the manual under 2.3 Search Path, but it does not really discuss this scenario.
I have about 60 extra test files I use for the library. And each has 10 or 20 includes like this. So I can't go through and change #include <foo/libfoo.h> to #include "./libfoo.h" in 500 or 600 places.
I tried #rici's work around by creating the fictitious directory structure, but it broke GDB debugging. GDB cannot find symbols for class members, so I can't set breakpoints to debug the code I am attempting to modify.
How do I tell the compiler to look in PWD for system includes?
Below is a typical error. ECIES_FIPS is in my local copy of the library.
$ g++ -DNDEBUG=1 -g3 -Os -Wall -Wextra -I. -iquote . ecies-test.c++ -o ecies-test.exe ./libcryptopp.a
ecies-test.c++:29:17: error: no member named 'ECIES_FIPS' in namespace
'CryptoPP'
using CryptoPP::ECIES_FIPS;
~~~~~~~~~~^
ecies-test.c++:44:5: error: use of undeclared identifier 'ECIES_FIPS'
ECIES_FIPS<ECP>::Decryptor decryptor(prng, ASN1::secp256r1());
^
ecies-test.c++:44:16: error: 'ECP' does not refer to a value
ECIES_FIPS<ECP>::Decryptor decryptor(prng, ASN1::secp256r1());
^
/usr/local/include/cryptopp/ecp.h:30:20: note: declared here
class CRYPTOPP_DLL ECP : public AbstractGroup<ECPPoint>
...
In case it matters:
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix
There is no option which tells gcc to ignore directory prefixes in include paths. If your program contains #include <foo/header.h>, there must be some path_prefix in the include list such that path_prefix/foo/header.h resolves to the desired file.
While you cannot configure gcc to ignore the foo, you can certainly modify the filesystem as you please. All you need is that there be somewhere a directory foo which maps onto the directory where the header files are stored. Then you can add the parent of that directory to the search path.
For example:
mkdir /tmp/fake
ln -s /path/to/directory/containing/header /tmp/fake/foo
gcc -I /tmp/fake ... # Ta-daa!
Using the -I option to add the current folder as an include directory, you could create a folder called "foo" in the current directory and put your libfoo.h file inside.
Obviously, this doesn't strip the "foo" prefix in your #include, but it is a workaround.
I have about 60 extra test files I use for the library. And each has 10 or 20 includes like this. So I can't go through and change #include to #include "./libfoo.h" in 500 or 600 places.
If the above criteria is just a matter of convenience, then a tool like sed can be used to do all the work. Something like
$ sed -i 's/\(^\s*#include\s*[<"]\)foo\/\([^>"]*[>"]\s*$\)/\1\2\t\/\/ This line was replaced/' *
will replace all the occurrences of #include <foo/file.h> with #include <file.h> (you might have to adjust it slightly, I'm on a Windows machine at the moment and can't test it). This will work if all the files are in the PWD. If there is a more complex file structure, then it can be used in conjunction with grep and xargs.
NOTE: Make sure that the svn directories are ignored when using.

compilation error when including directory containing headers

I have a directory maths which is a library that is comprised solely of header files.
I am trying to compile my program by running the following command in my home directory:
g++ -I ../maths prog1.cpp prog2.cpp test.cpp -o et -lboost_date_time -lgsl -lgslcblas
but I get the following compilation error:
prog1.cpp:4:23: fatal error: maths/Dense: No such file or directory
compilation terminated.
prog2.cpp:6:23: fatal error: maths/Dense: No such file or directory
compilation terminated.
maths is located in the same directory(i.e. my home directory) as the .cpp files and I am running the compilation line from my home as well.
prog1.cpp and prog2.cpp have the following headers
#include<maths/Dense> on lines 4 and 6 respectively, hence I am getting the error.
how do I fix it.
You can either change your include path to -I.. or your includes to #include <Dense>
Wait, if maths is in the same directory as your source files and that is your current directory, you can either change your include path to -I. or your includes to #include "Dense"
maths is located in the same directory(i.e. my home directory) as the .cpp files
Your include path is given as -I ../maths. You need -I ./maths – or simpler, -I maths since maths is a subdirectory of the current directory, not of the parent directory. Right?
Then in your C++ file, use #include <Dense>. If you want to use #include <maths/Dense> you need to adapt the include path. However, using -I. may lead to massive problems1, I strongly advise against this.
Instead, it’s common practice to have an include subdirectory that is included. So your folder structure should preferably look as follows:
./
+ include/
| + maths/
| + Dense
|
+ your_file.cpp
Then use -I include, and in your C++ file, #include <maths/Dense>.
1) Consider what happens if you’ve got a file ./map.cpp from which you generate an executable called ./map. As soon as you use #include <map> anywhere in your code, this will try to include ./map instead of the map standard header.