It's been a while since I've dealt with C/C++, so forgive me if this is a ridiculously easy to answer question - I just don't quite know how to "Google" it.
I have a file, "MyFile.h" that includes file "includedFile.h". However, the compiler cannot find the file. Please see below picture:
What I'm doing is moving the project from an old Solaris box to a Linux box. The weird thing is that it worked on the Solaris box as-is but Linux is a little confused.
The makefile that I use for the project hasn't changed either which makes me think that it may be a compiler option...
So how do I tell the compiler on Linux where that include file is, or how do I specify it in "MyFile.h?"
With gcc and clang, you specify the include path using -I:
g++ -o myprogram main.cc extra.cc -I/usr/include/boost -I/my/extra/include/files
You can specify full paths in your files, as in #include "/path/to/my/includedfile.h", but I strongly discourage this as it forces everyone who wants to compile your code to comply with that directory layout.
Also relevant: Read the following link for the difference between #include <file> and #include "file" in gcc: http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
Assuming you are using g++, you pass a path with the -I flag.
g++ ..... -I<a path to your includes> -I<another path to includes>
Related
How can I tell where g++ was able to find an include file? Basically if I
#include <foo.h>
g++ will scan the search path, using any include options to add or alter the path. But, at the end of days, is there a way I can tell the absolute path of foo.h that g++ chose to compile? Especially relevant if there is more than one foo.h in the myriad of search paths.
Short of a way of accomplishing that... is there a way to get g++ to tell me what its final search path is after including defaults and all include options?
g++ -H ...
will also print the full path of include files in a format which shows which header includes which
This will give make dependencies which list absolute paths of include files:
gcc -M showtime.c
If you don't want the system includes (i.e. #include <something.h>) then use:
gcc -MM showtime.c
Sure use
g++ -E -dI ... (whatever the original command arguments were)
If your build process is very complicated...
constexpr static auto iWillBreak =
#include "where/the/heck/is/this/file.h"
This will (almost certainly) cause a compilation error near the top of the file in question. That should show you a compiler error with the path the compiler sees.
Obviously this is worse than the other answers, but sometimes this kind of hack is useful.
If you use -MM or one of the related options (-M, etc), you get just the list of headers that are included without having all the other preprocessor output (which you seem to get with the suggested g++ -E -dI solution).
For MSVC you can use the /showInclude option, which will display the files that are included.
(This was stated in a comment of Michael Burr on this answer but I wanted to make it more visible and therefore added it as a separate answer.)
Usability note: The compiler will emit this information to the standard error output which seems to be suppressed by default when using the windows command prompt. Use 2>&1 to redirect stderr to stdout to see it nonetheless.
I am unable to compile a C project that uses a library called "FFmpeg" with a compiler called "GCC", and I believe it might be either because I don't quite understand how #include works or because I am using the wrong compilation process.
In a folder called Test, I have a file Test/test.c with the following contents:
#include <stdio.h>
#include <stdlib.h>
#include "FFmpeg/libavcodec/avcodec.h"
The folder FFmpeg is located at Test/FFmpeg. When I try to compile this with GCC, I receive the following error:
fatal error: libavutil/samplefmt.h: No such file or directory
The file Test/FFmpeg/libavcodec/avcodec.h has the following code in it:
#include "libavutil/samplefmt.h"
#include "libavutil/attributes.h"
#include "libavutil/avutil.h"
... //many more #include statements
Is the issue here that I need to add "FFmpeg/" to all of these include statements?
If so, is there a way to automatically do this? This library is enormous and probably has hundreds of these statements.
If not, what should I be doing instead? Should I attempt to compile the library by itself? If so, how do I then include this compiled version of the library in my program?
Notes:
The command I am using to compile is gcc -c test.c.
I have GCC installed via MinGW.
I ultimately need to be able to compile this program to both a .dll and an .so.
I apologize if any of the terminology I use here is incorrect or if my explanations are poor. I know almost nothing about compilation. Please let me know if I need to fill in more information.
When #include is used with quotation marks (e.g. #include "file path here"), it will read that file path as a relative file path.
In the case of compiling a C program using GCC, file paths are relative to the current directory. The "current directory" is the one into which you have placed your command prompt using the cd command.
In my case, I cd'd into C:/Users/User/Documents/Test, meaning that all relative file paths are relative to C:/Users/User/Documents/Test. So when my compiler read
#include "libavutil/samplefmt.h"
it basically tried to do this:
#include C:/Users/User/Documents/Test/libavutil/samplefmt.h
when I instead needed the compiler to look at …/Test/FFmpeg/libavutil/samplefmt.h.
It turns out that the solution to this is to give the compiler additional locations to which relative paths might be relative. This is done with the -I[file path here] argument when you compile.
In my case, the way I needed to use this idea was to add C:/Users/User/Documents/Test/FFmpeg as a location to which paths might be relative. Thus, I could have taken my compile command:
gcc -c test.c
And inserted this:
gcc -IC:\Users\User\Documents\Test\FFmpeg -c test.c
However, this is actually an extremely clunky solution. There is a much easier way: it turns out that these file paths you provide with the -I argument can be relative to your current directory themselves. In my case, because my current directory in the command prompt was alreadyC:/Users/User/Documents/Test, I could simply remove this portion from the above command, shortening it to this:
gcc -IFFmpeg -c test.c
And this solved my problem.
The following problem: Cygwin or Visual Studio give the error.
CGAL/Splitters.h: No such file or directory
This error appears for every header! The header is implemented by the code
#include <CGAL/Splitters.h>
The error disappears, if I change the code, such that I write the whole path:
#include <c:/path1/path2/CGAL/Splitters.h>
But this is no solution which satisfies me, because I would have to change hundreds of such code fractions.
I think it should be a problem of Visual studio or cygwin. In cygwin I wrote the command:
$ g++ -std=c++11 example.cpp -o example
What is the reason for the error? How can I fix it?
Please give easy understandable instructions, since I am a beginner in C++.
The compiler does not know where to look for the header file
referred to by #include <CGAL/Splitters.h> unless you tell it,
because that header file is not located in any of the compiler's
default search directories for header files.
You tell the compiler where to look by passing it an -I option:
$ g++ -I/path/to/cgal/headers -std=c++11 example.cpp -o example
where that header file will be:
/path/to/cgal/headers/CGAL/Splitters.h
Further reading: An Introduction to GCC - for the GNU compilers gcc and g++
Later
So for every of the header files I have to write the - I option?
No. -I/path/to/cgal/headers/ by itself will of course tell the compiler
where to find every CGAL header file used in your program.
You can check include path in Visual Studio :
Tools > Options > Projects and Solutions > VC++ Directories > Include files
So, check default header file path.
I hope this can help you.
How can I tell where g++ was able to find an include file? Basically if I
#include <foo.h>
g++ will scan the search path, using any include options to add or alter the path. But, at the end of days, is there a way I can tell the absolute path of foo.h that g++ chose to compile? Especially relevant if there is more than one foo.h in the myriad of search paths.
Short of a way of accomplishing that... is there a way to get g++ to tell me what its final search path is after including defaults and all include options?
g++ -H ...
will also print the full path of include files in a format which shows which header includes which
This will give make dependencies which list absolute paths of include files:
gcc -M showtime.c
If you don't want the system includes (i.e. #include <something.h>) then use:
gcc -MM showtime.c
Sure use
g++ -E -dI ... (whatever the original command arguments were)
If your build process is very complicated...
constexpr static auto iWillBreak =
#include "where/the/heck/is/this/file.h"
This will (almost certainly) cause a compilation error near the top of the file in question. That should show you a compiler error with the path the compiler sees.
Obviously this is worse than the other answers, but sometimes this kind of hack is useful.
If you use -MM or one of the related options (-M, etc), you get just the list of headers that are included without having all the other preprocessor output (which you seem to get with the suggested g++ -E -dI solution).
For MSVC you can use the /showInclude option, which will display the files that are included.
(This was stated in a comment of Michael Burr on this answer but I wanted to make it more visible and therefore added it as a separate answer.)
Usability note: The compiler will emit this information to the standard error output which seems to be suppressed by default when using the windows command prompt. Use 2>&1 to redirect stderr to stdout to see it nonetheless.
I'm experiencing an extremely weird problem in a fresh OSX 10.4.11 + Xcode 2.5 installation. I've reduced it to a minimal test case. Here's test.cpp:
#include "macros.h"
int main (void)
{
return 1;
}
And here's macros.h:
#ifndef __JUST_TESTING__
#define __JUST_TESTING__
template<typename T> void swap (T& pT1, T& pT2)
{
T pTmp = pT1;
pT1 = pT2;
pT2 = pTmp;
}
#endif //__JUST_TESTING__
This compiles and works just fine if both files are in the same directory. HOWEVER, if I put macros.h in /usr/include/gfc2 (it's part of a custom library I use) and change the #include in test.cpp, compilation fails with this error :
/usr/include/gfc2/macros.h:4: error: template with C linkage
I researched that error and most of the comments point to a "dangling extern C", which doesn't seem to be the case at all.
I'm at a complete loss here. Is g++ for some reason assuming everything in /usr/include/gfc2 is C even though it's included from a .cpp file that doesn't say extern "C" anywhere?
Any ideas?
EDIT : It does compile if I use the full path in the #include, ie #include "/usr/include/gfc2/macros.h"
EDIT2 : It's not including the wrong header. I've verified this using cpp, g++ -E, and renaming macros.h to foobarmacros.h
G++ may well indeed be assuming that everything in /usr/include is C. Try compiling your code with -E and studying the line markers in the preprocessor output:
g++ -E test.cpp | grep '^#'
You'll likely see things like
# 1 "/usr/include/gfc2/macros.h" 1 3 4
The 4 is the preprocessor hinting to G++ that it should wrap everything in extern "C", on the supposition that your platform's ancient header files in /usr/include predate C++. See Preprocessor Output in the CPP manual.
These days G++ mostly ignores this hint, because most platforms' C headers are no longer ancient. See the NO_IMPLICIT_EXTERN_C target macro in the GCC Internals manual. But it may be that this old version of Xcode has GCC configured without NO_IMPLICIT_EXTERN_C and thus is listening to the preprocessor's hint. (This is set when GCC itself is built -- I don't think there's a command-line switch to override it.)
You may be able to work around this by wrapping the contents of your header file in extern "C++".
This is a shot in the dark, but is there another file named macros.h somewhere under /usr/include or in your GCC installation? GCC has a facility for wrapping headers, called #include_next, which might be the cause of your problem.
One thing you can do to disambiguate your macros.h from any other macros.h in the include path is to include it as gfc2/macros.h. This way, the compiler will search every directory in the include path for a subdirectory named gfc2 containing a file named macros.h, reducing the chance of a collision. It also prevents you from having to add /usr/include/gfc2 to the include path.
BTW, #include "file.h" searches the current directory first. To skip that and go straight to the include path, use #include <file.h>:
#include <stdio.h>
#include <gfc2/macros.h>
Another approach is to choose a filename that is more likely to be unique, like gfc2macros.h.
Well, it really looks weird...
How does XCode calls g++?
I don't think g++ spontaneously decides that an include file has C linkage just because it's in a different directory. Did you try to compile your project by hand?
Try "g++ main.cpp -I/usr/include/gfc2/". If this solves your problem than it's not g++. Maybe does XCode precompile headers?
Have you tried not changing the test.cpp file at all, but instead when you compile also say:
-I/usr/include/gfc2/
You can see where g++ is looking for includes with the verbose flag:
g++ -v -o test test.cpp
And this will just run the preprocessor and show what is actually included in the file and compiled:
g++ -E test.cpp | less
If the wrong files are getting included (or your header is getting wrapped in another, as bk1e suggests) you'll be able to find out with that output.
I just ran into this issue as well when compiling a C++ project that we normally build on 10.5 and 10.6 (Xcode 3.0+) on a 10.4 PPC machine with Xcode 2.5 installed. It looks as if the preprocessor treats anything added to the gcc include path with '-isystem' as if it should be "extern C". Changing '-isystem' to '-I' resolved the issue.