I have this simple file, called lol.c
#include <iostream>
using namespace std;
int main() {
return(0);
}
From terminal, i type g++ lol.c
This is the output:
In file included from /usr/include/wchar.h:36:0,
from /usr/include/c++/4.9/cwchar:44,
from /usr/include/c++/4.9/bits/postypes.h:40,
from /usr/include/c++/4.9/iosfwd:40,
from /usr/include/c++/4.9/ios:38,
from /usr/include/c++/4.9/ostream:38,
from /usr/include/c++/4.9/iostream:39,
from lol.c:1:
/usr/include/stdio.h:30:22: fatal error: SDL_main.h: File o directory non esistente
#include "SDL_main.h"
^
compilation terminated.
I don't know if the problem is something with SDL, but when i try to run ../configure to install it, i have this:
configure: error: cannot run C compiled programs.
See `config.log' for more details
If is this needed, i can put config.log file too.
There are multiple problems:
you gave a .c extension to a C++ source file; that is wrong, C++ files should have a .cpp (or .cxx, .C, .c++, the last two are a bit frowned upon) extension, or the compiler may try to compile it as C code;
you are invoking gcc instead of g++; this is wrong too, calling gcc on C++ files misses several options required to compile and link correctly (including, but not limited to, linking against the C++ standard library); that was in an older revision of the question, now it says g++;
but most importantly, your build environment is completely broken (some would say "FUBAR"); it is not normal that /usr/include/stdio.h includes stuff from SDL (the fact that it cannot be found is just a minor incident compared to this); you should really purge and reinstall anything related to gcc and to the headers of the C library; look for some libc6-dev package (or similar) to reinstall (be careful not to mess with the C library proper, or your system may be rendered essentially unbootable).
You can't give .c (c extension) to a c++ file.
1 - Change it to .cpp (c++ extension, lol.cpp)
2 - You have to give options to g++ (in your case use -o to create executable file) g++ lol.cpp -o nameofyourprogram
3 - Execute through your terminal ./nameofyourprogram
Related
I'm trying to compile a CPP application (an open source project) in the latest cygwin64 environment using g++ 6.4.0 and I get the following error:
error: 'posix_memalign' was not declared in this scope
now posix_memlign can be found in stdlib.h if you compile the most simple CPP "hello world" application there wouldn't be a problem calling posix_memlign.
The make file of the project report the following setup for the compilation
g++ -DHAVE_CONFIG_H -I. -Wall -Wnon-virtual-dtor -I. -I./include -g -O3 -std=c++0x -g -O3 -std=c++0x -MT lib/rectangular_binary_matrix.lo -MD -MP -MF lib/.deps/rectangular_binary_matrix.Tpo -c lib/rectangular_binary_matrix.cc -DDLL_EXPORT -DPIC -o lib/.libs/rectangular_binary_matrix.o
so it doesn't look like it override the default include path. Any ideas?
p.s.
I was able to build the code on Linux (Redhat) without a problem.
posix_memalign is not part of the C Standard Library or the C++ Standard
library and the cygwin GCC compilers do not provide it, although other
compilers may do so, including GCC compilers from other builders.
You might consider using instead the C Standard function aligned_alloc, if you feel comfortable to edit your project source. It is provided in <cstdlib> for C++ compilation in cygwin g++ 6.4.0
Later
I do see the function in C:\cygwin64\usr\include\stdlib.h...
The fact that you can find the function declaration in the header file
does not mean that the compiler can see it after preprocessing. The same
source header may be used by many builders, exposing different
declarations to the compiler depending on the builder's settings of implementor
macros. In this case, the declaration is concealed from your compiler by
the fact that __POSIX_VISIBLE >= 200112 is false. Identifiers beginning __ are reserved for implementors.
See the explanation of this macro
and note the comment:
* The following private macros are used throughout the headers to control
* which symbols should be exposed. They are for internal use only, as
* indicated by the leading double underscore, and must never be used outside
* of these headers.
[SOLUTION FOUND]
Hello (I'm posting this on 2 threads regarding the same problem).
I'm here because I had the "POSIX_VISIBLE >= 200112" and the "posix_memalign was not declared in this scope" issue, which was halting the compilation of a program.
I'm not a programmer and tried various fixes on my own for a couple hours. Then finally Googled & came upon this site. The solutions here did not work for me, but I'll describe what did work:
The "posix_memalign" text was in a "stdlib.h" file that was being included into the code. The first problem was that in my "cygwin" directory, I have 25 instances of "stdlib.h"! Which one of those was being included?! I'm all new to this, but I finally found that
echo | gcc -E -Wp,-v -
might at least give an idea of which directory the files were being "included" from. This narrowed down the number of "stdlib.h" files to 4. Out of 4 such files, only one had the "posix_memalign" text. I tried changing the filename of that stdlib.h to see if it would cause an error--and confirm that it was the stdlib.h in question. However, this didn't effect the program. So I searched for a "stdlib.h" file in the next directory higher. THAT "stdlib.h" file also had the "POSIX" text in it. So when I changed THAT stdlib.h filename, the program DID error out. So that was the stdlib.h to deal with.
I saw that the "POSIX_VISIBLE >= 200112" instruction effected only the ONE line of code with "posix_memalign" in it. (In other words, the "POSIX_VISIBLE" instruction was not being used for the whole file.) I considered "commenting" it out, or deleting it. But then non-programmer me got the ingenious idea to simply change the ">=" to a "<". So I now had "POSIX_VISIBLE < 200112". I saved the file, ran the "configure" and "make" routine again, and boom, all was well. Program compiled properly.
Moral of the story, if you can determine the file (containing the POSIX statement and the posix_memalign) which is being accessed by your code, you may be able to solve your problem by just changing that one POSIX_VISIBLE operator as I did. (And you may want to switch that operator back after your compiling is done, in case that stdlib.h library file needs to be used by other programs in the future.)
Whenever I try to compile this code it always ends up with this error:
In file included from /usr/include/wchar.h:6:0,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cwchar:44,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iosfwd:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ios:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iostream:39,
from test.cpp:1:
/usr/include/sys/reent.h:14:20: fatal error: stddef.h: No such file or directory
#include <stddef.h>
^
compilation terminated.
The code I was trying to compile is:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World! :D";
return 0;
}
The error is because your gcc-core package and gcc-g++ are not of the same version. Either downgrade one of them to solve the problem or update both the libraries. Updating both the libraries is the recommended way.
I had this error on a fresh MinGW install, it had nothing to do with the installed packages mentioned in the current accepted answer by "Prasanth Karri". In my case the issue was caused by -nostdinc in my Makefile. I actually only needed that compiler flag when building for a different target platform (not when using MinGW) so I fixed the issue by removing that flag from MinGW builds.
When I was incorporating a software library written in C into an existing demo project(used a C++ mbed library) I encountered this problem. The demo project would compile just fine, but after I replaced the existing main file by my own, this error occurred.
At this point I hadn't yet thought about the fact that the mbed library that I needed was written in C++. My own main file was a .c file that #include the mbed header file. As a result I used my normal C source as if it was a C++ source. Therefore the compiler that was used to compile my main file was the C compiler.
This C compiler then encountered a #include of a module that actually does not exist (within its scope), as it's not a C++ compiler.
Only after I inspected the output of the build log I realised the various source C and C++ files were compiled by more that 1 compiler(the c++ compiler). The project used used compilers arm-none-eabi-c++ and arm-none-eabi-gcc (for embedded systems) as seen below.
Compile log:
Building file: ../anyfile.cpp
Invoking: MCU C++ Compiler
arm-none-eabi-c++ <A lot of arguments> "../anyfile.cpp"
Finished building: ../anyfile.cpp
Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc <A lot of arguments> "../main.c"
In file included from <Project directory>\mbed/mbed.h:21:0,
from ../main.c:16:
<Project directory>\mbed/platform.h:25:19: fatal error: cstddef: No such file or directory
compilation terminated.
Of course in a C++ environment cstddef exists, but in a C environment cstddef doesn't exist, in stead it's just C's implementation of stddef.
In other words, cstddef does not exist in the C compiler.
I resolved this problem by renaming my main.c file to main.cpp and the rest of the code compiled smoothly too.
TLDR/Conclusion: When building a C++ project, avoid mixing C files with C++ files(sources and headers). If possible rename .c files to .cpp files to use the C++ compiler in stead of the C compiler where required.
In order to update it, follow below.
If you are on Windows, just run these on command prompt or powershell
Update the package list: mingw-get update
After updating the package list, run: mingw-get upgrade
Source: How to update GCC in MinGW on Windows?
This problem was solved for me as I installed codeblocks with mingw compiler then I copied the mingw folder from codeblocks to C drive and added
C\mingw\bin to the environment variables.
If you try to compile and see a message like, "fatal error: stddef.h: No such file or directory", the error is because your gcc-core and gcc-g++ packages are not of the same version. Rerun the Cygwin install and make sure that you select the highest numbered versions of gcc-core and gcc-g++.
After installing the C++ compiler with MinGW I encountered this problem as well. Apparently, you have to also install mingw32-base. Go to C:/MinGW/bin/mingw-get.exe (my path) and check it for installation at the Basic Setup tab.
I know this topic was few times there, but I can't get satisfactory answer.
C:\Users\Krzysiek>gcc test.c
test.c:3:20: fatal error: iostream: No such file or directory
compilation terminated.
This is what I try to do
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
Simple program with "include"
I've heard of LIBRARY_PATH. So I've setted that. Still this same error I have.
GCC provides wrappers around calling its various compilers.
You are using gcc, which is for C (and consequently will not include or link the C++ standard library; the compiler would go on to complain about the rest of your code, too, since it's not valid C);
Use g++, which is for C++.
Also try to use a conventional extension for C++ source files, which is .cc, .cxx or .cpp.
Use g++ instead: it will link to the c++ standard library.
When you use the gcc command, gcc looks at the file extension to decide which language to use to compile. As you used a .c file, gcc will switch by default to C.
# Use the C compiler
gcc test.c
# Use the C++ compiler
gcc test.cpp
To choose a different language, you can use the -x option:
# Use the C++ compiler even if the extension is .c
gcc -xc++ test.c
Another method of using the C++ compiler is to use g++ in the command line. This is the preferred way, as it links with the correct libraries.
# Use the C++ compiler
g++ test.c
I have the following very simple application that compiles and runs fine:
EDIT: changed the example to be simpilar to end confusion of the real issue
int main() {
return 0;
}
As soon as I add #include <string> (and not even reference std::string), it fails to compile and I get the following error:
/usr/include/c++/4.1.2/bits/allocator.h:82 error: expected template-name before '<' token
Along with about 456 other, similar errors.
Any ideas? Thanks!
UPDATE:
Line 82 of /usr/include/c++/4.1.2/bits/allocator.h references the template __glibcxx_base_allocator at the location of the error. That template is defined in bits/c++allocator.h. When I search the system for that file, I get 3 hits, but none of them are in /usr/include/c++/4.1.2/bits/ as one would expect.
I have version 3.1.6, 4.1.1, and 4.3.2, but not 4.1.2 as the rest of the includes I am using. I am not sure which one is being used (if any, however, I don't get any error for an unknown file), but it seems the problem may stem from this.
The problem appears to be the installed development packages are not correct or incomplete (not to be confused with corrupt). Forcing g++ to use different include versions corrects that:
g++ -nostdic++ hello.cc -o hello -I/usr/include/c++/3.4.6
All the alternative directories (4.1.1, 4.1.2 and 4.3.2) are incomplete causing inappropriate files to be included causing the unusually errors. For example:
/usr/include/c++/4.1.2/bits/allocator.h requires __glibcxx_base_allocator located in bits/c++allocator.h which is being included from either /usr/include/c++/4.1.1 or /usr/include/c++/4.3.2 and appear to be incompatible. Forcing the compiler to use the only complete set of includes rectifies this.
Almost certainly g++ is detecting .cc as a C source file, not C++ and passes it through to gcc instead of compiling as C++. You can easily test by renaming your file to hello.C. There's also a language parameter to g++ you can use.
EDIT: This seems to work fine in g++ 4.2 with a .cc extension so that might not be it. Do you have any other headers included you aren't showing us? They could be interfering with <string>.
EDIT2: Alternatively your headers might not be set up right. Does this work:
#include <string>
int main()
{
return 0;
}
Errors like this have been heard of to occur when the C++ standard library headers are corrupted/not fully installed – maybe there is even a message referring to a missing include among your 456 other errors.
In any case, make sure that libstdc++-devel, resp. the package containing the C++ standard library header files of your distribution, is properly installed.
Check your include path. The paths can be specified as environment variables or specified on the command line. You could be using an include file from a different compiler or different version of the same compiler.
Also, try using <cstdio> rather than <stdio.h>.
Another suggestion: change <> to "".
This could be error caused at preprocess stage. Just preprocess your cpp file by passing flag -E to gcc and Look at the place the compiler complains.
How can I compile a C++ program with the GCC compiler?
File info.c
#include<iostream>
using std::cout;
using std::endl;
int main()
{
#ifdef __cplusplus
cout << "C++ compiler in use and version is " << __cplusplus << endl;
#endif
cout <<"Version is " << __STDC_VERSION__ << endl;
cout << "Hi" << __FILE__ << __LINE__ << endl;
}
And when I try to compile info.c:
gcc info.C
Undefined first referenced
symbol in file
cout /var/tmp/ccPxLN2a.o
endl(ostream &) /var/tmp/ccPxLN2a.o
ostream::operator<<(ostream &(*)(ostream &))/var/tmp/ccPxLN2a.o
ostream::operator<<(int) /var/tmp/ccPxLN2a.o
ostream::operator<<(long) /var/tmp/ccPxLN2a.o
ostream::operator<<(char const *) /var/tmp/ccPxLN2a.o
ld: fatal: Symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status
Isn't the GCC compiler capable of compiling C++ programs?
On a related note, what is the difference between gcc and g++?
gcc can actually compile C++ code just fine. The errors you received are linker errors, not compiler errors.
Odds are that if you change the compilation line to be this:
gcc info.C -lstdc++
which makes it link to the standard C++ library, then it will work just fine.
However, you should just make your life easier and use g++.
Rup says it best in his comment to another answer:
[...] gcc will
select the correct back-end compiler
based on file extension (i.e. will
compile a .c as C and a .cc as C++)
and links binaries against just the
standard C and GCC helper libraries by
default regardless of input languages;
g++ will also select the correct
back-end based on extension except
that I think it compiles all C source
as C++ instead (i.e. it compiles both
.c and .cc as C++) and it includes
libstdc++ in its link step regardless
of input languages.
If you give the code a .c extension the compiler thinks it is C code, not C++. And the C++ compiler driver is called g++, if you use the gcc driver you will have linker problems, as the standard C++ libraries will not be linked by default. So you want:
g++ myprog.cpp
And do not even consider using an uppercase .C extension, unless you never want to port your code, and are prepared to be hated by those you work with.
You should use g++ instead of gcc.
By default, gcc selects the language based on the file extension, but you can force gcc to select a different language backend with the -x option thus:
gcc -x c++
More options are detailed on the gcc man page under "Options controlling the kind of output". See e.g. gcc(1) - Linux man page (search on the page for the text -x language).
This facility is very useful in cases where gcc can't guess the language using a file extension, for example if you're generating code and feeding it to gcc via standard input.
The difference between gcc and g++ are:
gcc | g++
compiles C source | compiles C++ source
Use g++ instead of gcc to compile you C++ source.
If I recall correctly, gcc determines the filetype from the suffix. So, make it foo.cc and it should work.
And, to answer your other question, that is the difference between "gcc" and "g++". gcc is a frontend that chooses the correct compiler.
An update with my GCC version 10.3.0 on Ubuntu. Even if I add -lstdc++ or use the correct extension, cc1plus must be installed on the system. Otherwise this error shows up:
gcc: fatal error: cannot execute ‘cc1plus’: execvp: No such file or directory
One way to get this is to install g++ even if you're not going to use it directly, e.g. sudo apt install g++.
Now, if I use the extension .cc, I can just call gcc directly, however, warnings and errors still show up. To use gcc cleanly, with a .c extension I have to call it like this:
gcc -x c++ info.c -lstdc++
Shorter if I use the .cc extension, like the accepted answer:
gcc info.cc -lstdc++
Or like others have said, just use g++ info.c instead. No extra parameters are needed to indicate C++, and it works with .c, .cc and .cpp extensions.
It worked well for me. Just one line code on the Windows command line (CMD).
First, confirm that you have installed gcc (for C) or g++ (for C++) compiler.
On the command line, for gcc, type:
gcc --version
On the command line, for g++, type:
g++ --version
If it is installed then proceed.
Now, compile your .c or .cpp using the command line.
For C syntax:
gcc -o exe_filename yourfilename.c
Example:
gcc -o myfile myfile.c
Here exe_filename (myfile in example) is the name of your .exe file which you want to produce after compilation (Note: I have not put any extension here). And yourfilename.c (myfile.c in example) is the your source file which has the .c extension.
Now go to the folder containing your .c file. Here you will find a file with the .exe extension. Just open it. Hurray...
For C++ syntax:
g++ -o exe_filename yourfilename.cpp
After it, the process is the same as for the C syntax.
For a .cpp File:
g++ myprog.cpp -o myprog