When I compile a program using just
gcc code.c
There are no messages, and an output file is generated successfully. The outputted file works. However, when I try to the same cygwin installation's gcc compiler in an IDE (I've tried Netbeans and Dev-C++), I get the following errors
main.cpp:27: error: `exit' undeclared (first use this function)
main.cpp:27: error: (Each undeclared identifier is reported only once for each function it appears in.)
main.cpp:77: error: `write' undeclared (first use this function)
main.cpp:78: error: `close' undeclared (first use this function)
I don't see what's different. Why does it not compile?
OK, the issue was that in the IDE, the file had a .cpp extension, whereas when I was compiling from a terminal, it had a .c extension. So, my new question is why does it not compile when it's treated as a c++ file. Isn't C a subset of C++?
C++ is stricter then C. Where C allows you to call a function without a prototype, C++ does not allow this.
To solve the problem, you want to add:
#include <stdlib.h>
Also, when compiling at the command line. Make sure to use the -Wall flag so you'll get important warnings:
gcc -Wall code.c
The IDE is using fussier options to the compiler. You need to include some headers:
#include <stdlib.h> // exit()
#include <unistd.h> // close(), write()
The default options allow almost anything that might be C to compile. By the looks of it, the IDE sets '-Wmissing-prototypes' as one of the compiler options.
If you compile code with a C++ compiler, you must ensure that all functions are declared before use. C is sloppier (or can be sloppier) about that - it is recommended practice to ensure all functions are declared before being defined or referenced, but it is not mandatory. In C++ it is not optional.
There is a subset of C that is also a subset of C++; there are bits of C that are not C++, and there are many bits of C++ that are not C. In particular, an arbitrary C program is not, in general, a C++ program. For example, a C program may not declare 'exit()' and yet it can both use it and still compile. A C++ program must declare 'exit()' before it can user it and compile.
You will have to use g++ for compiling .cpp files.
One possible reason may be that the IDE is unable to access the include files, the cygwin gcc compiler may be expecting it in /usr/include(not sure), and the dev-cpp may not be able to access it.
Related
I have the following C code with a missing function
test1.c
#include <stdio.h>
int main(){
Log("hello");
return 0;
}
Compiling it to an object file with gcc -c test1.c produces an object file with a warning (linking will fail of course).
Compiling the same code (with iostream instead of stdio.h) to an object file using g++ doesn't even compile and it complains by error: use of undeclared identifier 'Log'.
Why didn't gcc stop compilation but g++ did?
C++ does not permit undeclared functions to be called. However, prior to C99, undeclared functions are sometimes permitted in C. Therefore, the code has to result in compile time error in C++, but it can succeed in compiling in C89 (although linking will find no definition of the hypothetical Log.)
Since C99, undeclared functions are not permitted.
Because C and C++ are different languages with different rules.
There is no such thing as an implicit function declaration in C++ and there never has been in any version of the language standard. The shown program is ill-formed.
Non-declared functions can be called in old versions of C. However, since C99 it has been ill-formed in that language as well.
I am building a C program with no problem on CentOS using provided Makefiles in its distro package. However I need to modify source files and I need to use iqxmlrpc and boost libraries for that purpose. I have changed Makefiles respectively but when I want to build the package I get following error:
../src/libiqxmlrpc/libiqxmlrpc/except.h:9:21: error: stdexcept: No such file or directory
../src/libiqxmlrpc/libiqxmlrpc/except.h:10:18: error: string: No such file or directory
In file included from ../src/libiqxmlrpc/libiqxmlrpc/libiqxmlrpc.h:17,
from redir.c:2617:
../src/libiqxmlrpc/libiqxmlrpc/except.h:14: error: expected '=', ',', ';', 'asm' or 'attribute' before 'iqxmlrpc'
... followed by many other errors ...
I believe above error is because iqxmlpc is written in c++ and gcc is treating it as C so I tried followings:
1) Use g++
2) Use gcc -x c++
Doing above, error changes to a lot of following in many header files:
error: expected ‘,’ or ‘...’ before ‘this’
All the lines that compiler is complaining somehow have this or delete keywords as parameter. See below:
int net_route(struct in_addr *dst, int delete);
or
extern int gad_new(struct gad_t **this)
Do you have any idea how can I fix this? Frankly, I have no idea what using 'this' or 'delete' mean as parameters. Are these only parameter names that gcc ignores the rule that we can not use keywords?
------------------------------
BTW, original programmer have used nested functions all across his code which were compiled fine using gcc. when I switch to g++, compiler complains about function-definition not being allowed in another function. Is there any way I can tell g++ to ignore this error?
Those weren't keywords in C, they are in C++.
You will have to rename those parameters before the code will compile in C++.
You may run into other porting issues related to C++'s stricter type checking before you are done.
Another option is to keep the C and C++ code in separate files, and use extern "C" in the C++ code for every function call that must cross the boundary. Since your C code extensively uses nested functions and other features not permitted in C++, this is probably your quickest approach.
this and delete are reserved keywords in C++ (not in C though) . You cannot use these as variable names when compiling with g++.
Its better to use different variable names in parameters and then compile with g++.
I have to compile generated C code that #includes C++ headers and it get it to work on Linux, OS X and Windows. I put the #includes myself to be able to interact with C++ code from it.
The C code however is such that a strict compiler would catch errors that could be treated as warnings. I want to pass these off as warnings as most of this is generated code which I don't have control over.
Here are my attempts to compile it (I use CMake, btw):
(I use these flags: -Wno-write-strings -Wno-error -fpermissive)
Treat the entire project as C++ code: works on Linux (with g++) but on OS X I get:
With Clang:
error: assigning to 'char *' from incompatible type 'const char *'
With g++:
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:18:no such instruction: `vmovdqa LC0(%rip), %xmm3'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:19:no such instruction: `vmovdqa LC1(%rip), %xmm2'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:20:no such instruction: `vmovdqu (%rsi), %xmm7'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:21:no such instruction: `vmovdqu 16(%rsi), %xmm8'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:22:no such instruction: `vmovdqa LC2(%rip), %xmm1'
/var/folders/hf/5dbkbqrx5p3bmnpdqqy4wgpr0000gn/T//ccvMHo2S.s:23:no such instruction: `vpshufb %xmm3, %xmm7,%xmm6'
Treat C code as C code:
Doesn't find <atomic>
fatal error: atomic: No such file or directory
#include <atomic>
Use -Wa -q flags as per this answer:
https://stackoverflow.com/a/19339870/3684931 (I made a mistake there. It should have been -Wa, -q)
Flag becomes invalid.
clang: error: unknown argument: '-q'
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
Use -Wa,-q flags as per this answer:
https://stackoverflow.com/a/19339870/3684931
Flag is still invalid.
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
clang: error: unsupported argument '-q' to option 'Wa,'
How do I go about building this?
You seem to be solving this problem backwards, to me. Every conforming C++ implementation seems to have a compatible C ABI, so C++ projects can use C libraries. Use that to your advantage.
Create C libraries containing your C code, and compile them as C code (e.g. cc -c your_filename.c will produce a your_filename.o object file).
Create a C++ project (where you should be able to include all of your C headers, if you design them carefully), and use your linker to link to the your_filename.o object files you produced in step 1, when compiling that project.
I put the #includes myself to be able to interact with C++ code from it.
This is where you went wrong. #includeing a C++ header from a .c file will never work.
Instead, you need to make header files which are compatible with both C and C++. These files should only contain code in the common subset of C and C++ ; and they should also contain:
#ifdef __cplusplus
extern "C" {
#endif
// main header code here
#ifdef __cpluscplus
}
#endif
so that the C++ units including this header create calls using the C ABI.
In this header , you can declare some functions that will do the interacting with the C++ code which your C files require. And you can implement those functions in a new C++ source file which you write.
I am working with Code::Blocks and C++ GNU GCC and trying to port my Visual Studio Project to GNU GCC.
And while I am trying to compile I get stuck with my define macro from a Defines.h file:
#define out &
And when compiling I get this error:
error: expected unqualified-id before '=' token
On this line:
// Open for output. Default for #c ofstream and fstream.
static const openmode out = _S_out;
In ios_base.h
As I know, that file is a part of a libstd library. Can I disable it? If so, how can I do that?
My library doesn't requiring any std c++, just c library.
There are two main options:
Don't define a macro using the word out.
Declare the macro after you include all of your headers.
But seriously, a macro named out that becomes & is a pretty awful macro. It's going to make it difficult to understand the code very quickly.
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.