I am at 82 % of compiling and it stops (use Linux OS), thus this is the screenshot.
I want to use this SFML but why is it so hard to compile it and install it?
I try this :
grep "assert" SoundRecorder.cpp
at the so-called file
Thanks.
Sounds like a broken compiler installation. assert() is part of the <cassert> header, as correctly recognized by the compiler, yet for some reason it doesn't seem to correctly include it, as it can't find the symbol.
I'd suggest to reinstall the compiler and see if that resolves the issue.
You may, as #Botje suggested also double check whether the defined <cassert> header (which include other headers), actually include an implementation of assert(), but would be odd, if it didn't. On Linux you should usually find them in /usr/include/c++/<version>/ or alternatively run g++ -v -v -v which should list the location of the include directory as well.
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.
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>
I'm new to C++ and trying to understand how it is finding headers. Originally I was just trying to find out what classes are available for me to include in my source code. I believe that different compilers will use different include directories, and hence class availability will vary. My plan was to find the "include" directory that the compiler was using and assume I can include anything there. So I am just getting more confused as I go.
First, I am writing C++ code in Code::Blocks, on Windows 7. The IDE is set to use GNU GCC for compilation, which I learned means it uses the G++ compiler for C++ code. I found my compiler here: C:\MinGW\bin\mingw32-g++.exe, Code::Blocks settings point to that.
So I assumed that G++ must be using C:\MinGW\include recursively to find all its headers. To test my theory, I searched for "iostream.h". To my surprise, I do not even have "iostream.h" on my C drive. Despite that, my code compiles and works when I include that.
So my questions:
How is G++ finding the iostream header when my hard drive does not even have it?
Will all the standard C++ headers (as listed here: http://msdn.microsoft.com/en-us/library/ct1as7hw.aspx) be available to all C++ compilers? with the same exact name so I don't have to change my source code?
Regarding the second question, the standard does not require the headers to be available as files. It requires the #include directive to be present in the program and the compiler to behave as if the declarations that the standard required were present in the program. But the compiler is free to inject the declarations in any way it deems fit.
That being said, g++ in particular does have files backing up each one of the headers. Without knowing your particular configuration I cannot tell you where the headers will be but you can stop the compilation process after the preprocessor and examine the output:
$ cat test.cpp
#include <iostream>
int main() {
std::cout << "Hi\n";
}
$ g++ -E test.cpp | head -10
# 1 "test.cpp"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "test.cpp"
# 1 "/usr/include/c++/4.2.1/iostream" 1 3
# 42 "/usr/include/c++/4.2.1/iostream" 3
# 43 "/usr/include/c++/4.2.1/iostream" 3
The paths above are on a MacOSX Lion, and it shows that in this particular configuration iostream is included from /usr/include/c++/4.2.1/iostream. In windows head might not be available, but you can redirect the output to a file and read it from there.
Using quotation marks will search the current directory before moving to the ones it would search with angle brackets. There are other directories than the files listed in \include. That's where you'll find the ones without any extension. You may have a c++ folder in there with those files inside, but even searching for them from within the CodeBlocks directory using the Windows 7 search shows you where they're located.
Yes, they should all be accessible with the same name, using angle bracket includes to reach them. Of course there is always a small chance that some might be missing. If this is the case, that implementation would seem pretty unreliable from first sight. All major compilers today should definitely adhere to this.
To use your own headers with your classes in them, they should be in the same directory as the main cpp file, and you should use quotation includes.
1) The reason you can't find iostream.h is there's no such header, it's spelled iostream in standard C++. If you try #include <iostream.h> it will fail, so it isn't finding headers you don't have :)
If you run g++ -v test.cpp it will show all the paths it uses to look for headers when compiling test.cpp
2) Yes, they wouldn't be standard headers if they were missing or had different names depending on your compiler!
Answer 1: I've used Code::Blocks for very little time, but for what I remember in Dev-C++ and MSVC++, the headers are in the IDE's directory. (For example, my MSVC++ include directory is in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include, and it HAS the iostream file.)
Answer 2: The most common header files are in the most common IDE's / compilers' set.
Tip: Did you not mean "iostream" instead of "iostream.h"?
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 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.