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
Related
When I'm building POSIX C programs, I want to be portable and use only POSIX or standard C library functions. So, for example, with gcc or clang, I build like this:
gcc -std=c99 -D_XOPEN_SOURCE=600
Setting the standard to C99 removes all extensions, then _XOPEN_SOURCE exposes POSIX interfaces. I no longer have the environment polluted with extensions from GNU, BSD, etc.
However, the waters seem murkier with C++. I want to do this:
g++ -std=c++14 -D_XOPEN_SOURCE=600
This has worked fine for me on various operating systems: Linux/glibc, Haiku, MinGW, macOS, at least. But apparently, there are problems with POSIX feature test macros and C++. Oracle docs have this to say:
C++ bindings are not defined for POSIX or SUSv4, so specifying feature test macros such as _POSIX_SOURCE, _POSIX_C_SOURCE, and _XOPEN_SOURCE can result in compilation errors due to conflicting requirements of standard C++ and these specifications.
While I don't have a copy of Oracle Solaris, I am seeing issues with FreeBSD and OpenBSD.
On FreeBSD:
#include <iostream>
int main() { }
$ clang++ -std=c++14 -D_POSIX_C_SOURCE=200112L t.cpp
In file included from t.cpp:1:
In file included from /usr/include/c++/v1/iostream:37:
In file included from /usr/include/c++/v1/ios:215:
/usr/include/c++/v1/__locale:631:16: error: use of undeclared identifier 'isascii'
return isascii(__c) ? (__tab_[static_cast<int>(__c)] & __m) !=0 : false;
...
(This builds fine with _XOPEN_SOURCE=600). C++ headers on FreeBSD use isacii, a non-standard function, so it's not exposed when _POSIX_C_SOURCE is set.
Or on OpenBSD:
#include <fstream>
int main() { }
$ clang++ -std=c++14 -D_XOPEN_SOURCE=600 t.cpp
In file included from t.cpp:1:
In file included from /usr/include/c++/v1/fstream:183:
In file included from /usr/include/c++/v1/ostream:138:
In file included from /usr/include/c++/v1/ios:215:
In file included from /usr/include/c++/v1/__locale:32:
In file included from /usr/include/c++/v1/support/newlib/xlocale.h:25:
/usr/include/c++/v1/support/xlocale/__strtonum_fallback.h:23:64: error: unknown type name 'locale_t'
char **endptr, locale_t) {
Presumably <locale.h> isn't getting included somewhere it “should” be.
The worrisome conclusion I'm drawing is that you can't portably have a POSIX C++ environment that is free of non-POSIX extensions. These examples work fine on OpenBSD and FreeBSD if the feature test macros are removed. That looks to be because the BSD headers expose BSD functions unless in standard C mode, but they do not care about standard C++ mode (they explicitly check whether macros corresponding to C89, C99, or C11 are set). glibc looks to be the same: it still exposes non-standard C functions in standard C++ mode, so perhaps it's only a matter of time before I run into a build error there.
So the actual question is this: can you write portable POSIX C++ code which does not expose platform-specific functionality? Or if I'm targeting POSIX with C++ should I just not set any feature test macros and hope for the best?
EDIT:
I got to thinking about the implications of this (as in, why do I care?), and the following program, I think, illustrates it. This is Linux/glibc:
#include <ctime>
int dysize;
$ g++ -c -std=c++14 t.cpp
t.cpp:2:5: error: ‘int dysize’ redeclared as different kind of entity
2 | int dysize;
| ^~~~~~
In file included from t.cpp:1:
/usr/include/time.h:262:12: note: previous declaration ‘int dysize(int)’
262 | extern int dysize (int __year) __THROW __attribute__ ((__const__));
This is the standard <ctime> header, which is does not include anything called dysize. That's an old SunOS function that glibc includes for compatibility. A C program built with -std=c99 won't expose it, but C++ always does. And there's no real way of knowing which non-reserved identifiers will be used by various implementations. If -std=c++14 caused non-standard identifiers to be hidden, that would avoid this problem, but it doesn't, and I can't see a way around that.
Which might imply that the feature test macro is a red herring: the source of the problem is that, on at least some real-world implementations, C++ compilers are exposing symbols they're not supposed to.
My suggestion is to build a toolchain, and work from that with the libraries, includes, the correct compiler (perhaps a stripped version that can only use POSIX libraries, includes, etc).
To make it portable, generally you would build the application using static linkers. Other linker options may be necessary that point specifically or include your toolchain environment paths.
And if you're using POSIX threads, you may need -pthread.
I see that you are using system-wide headers and libraries, when really, you probably want a specific to your POSIX application toolchain, to avoid contamination.
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
I am trying to get a C++ software, written to work with the xlC compiler, to work with g++. The Makefile of the original file has:
LIB = -lcomplex -L[address_to_user_folder] -lm
My concern is how to change the above line to work with g++ (I have already changed the compiler type in the first line: CC = g++. Also assuming no more changes are necessary.)
I tried this:
LIB = -lcomplex -lm
and received this error:
/usr/bin/ld: cannot find -lcomplex
I wonder if -lcomplex is valid in g++. If yes, why do I receive this error, and if not, how can I link to a complex number library in my Makefile?
What do you mean "if g++ supports complex numbers"?
G++ supports the standard C++ type std::complex defined in the <complex> header, and also C99-style complex numbers (which are not part of standard C++, this is a GCC extension).
No external library is needed for these features.
If your software is using some other kind of complex numbers then maybe you need an external library.
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
i have redhat with gcc 4.1.1 i have compile as "gcc test.c" and give the following error
Error : expected '=' ,',' , ';' , ásm' or '__ attribute__' before '<' token
the code in "test.c" is as follow
template <typename T> class A {
public:
T foo;
};
Compile with g++ and/or rename your file to test.cpp.
If you compile with gcc test.c then your file will be assumed as a C file. There's no templates in C.
This is C++ code, not C. You need to use g++, i.e. g++ test.c. Also, to avoid confusion, you should rename your file to end with .cpp or .cxx.
From the GCC Manual, compiling a file with the .c extension will compile your code as though it were C, not C++. The easiest solution is to compile your code with g++ instead. The g++ command sets the default language to C++ and automatically links your code against the C++ standard library. You can do both of those with gcc but you have to do it by hand. Exactly how you do that is left as an exercise. :-)