I get the following error when dealing with C using Fedora:
[king#localhost ~]$ gcc -o1 tempdaa.c
tempdaa.c:3:17: fatal error: queue: No such file or directory
#include <queue>
^
compilation terminated.
Any ideas on where the problem is?
gcc is generally what you use to compile C code. If you want to compile C++ code, you'd tend to use g++.
Now it's true that gcc can compile C++ if it's clear you have a C++ program but I think, from memory, that's indicated by the extension rather than the content.
Since your extension is .c rather than something like .cpp or .cc or .cxx, it will definitely think it's C code and behave accordingly.
Hence the C++ header queue will not be available to you.
My suggestion is that you name your C++ source files "correctly", or force the language type explicitly:
gcc -x c++ -o1 tempdaa.c
Related
Im doing an assignment and the requirement instruction say "Your code should compile correctly (no warnings and errors) with no flags other -o. you should compile your code to a debug-able executable without producing any warnings or error messages. (Note that -O and -o are different flags.)"
So Im so confused what does the " no flags other -o " means. As far as I know, "flag is a general tool for rudimentary signalling and identification, especially in environments where communication is similarly challenging.", so does the requirement mean that we can't use any for loop ?
No, the requirement is referring to command-line flags, ie options to the compiler. Eg, assuming gcc, gcc -o foo foo.c.
However, since the program is meant to be debuggable, the requirements are contradictory because creating a debuggable executable requires (for gcc) the -g flag.
On many compilers, you can control the warning level with flags. The requirement here is to not use those flags, yet raise no warning.
Said differently, you are just asked to write neat and clean C code using no specific extension nor any semi valid constructs (code not conforming to the standard but accepted with warnings by a compiler)
I have a simple, representative C program, stored in a file called hello.c:
#include <stdio.h>
int main(void)
{
printf('Hello, world\n');
return 0;
}
On my Linux machine, I attempted to compile the program with gcc:
gcc hello.c
which returns an error:
undefined reference to "___gxx_personality_v0" ... etc
As has been discussed before in the context of C++, this problem arises in the linking stage, when gcc attempts to link C libraries to a C++ program, thus giving the error. In one of the answers, someone mentioned that the extension does matter, and that gcc requires the .c extension when compiling C files, and some other extension (e.g. .cpp) when compiling C++ files.
Question: How do I set gcc to use the file extension to determine which compiler to use, since gcc seems to be defaulting to C++ on my system? Specifying the language through the file extension alone doesn't seem to be enough. If I specify the language using the -x flag, gcc functions as expected.
gcc -x c hello.c
Typically, you let make decide this.
GNU Make has built in implicit rules, which automatically pick the right compiler.
Try a Makefile with these contents:
all: some_file.o some_other_file.o
And then place a some_file.cpp and some_other_file.c in the same directory, and gnu make will automatically pick the correct compiler. The linker, you may still have to provide yourself. When mixing C and C++, it's usually easiest to link with g++, like so:
program.exe: some_file.o some_other_file.o
g++ -o $# #^
This is the same as:
program.exe: some_file.o some_other_file.o
g++ -o program.exe some_file.o some_other_file.o
I am learning C with the GCC compiler and Geany (Arch Linux, if it makes a difference). However, I am seeing the words compile and build used interchangeably, both in Geany and on the internet. I am asking for clarification that the way I understand the compiling process is correct, because Googling it is just making me more confused.
Say I write a simple helloworld.c file:
#include <stdio.h>
int main(void)
{
printf("Hello world!");
return 0;
}
If I run gcc -c helloworld.c, the compiler produces a helloworld.o object file. Geany calls this process compilation and the compiler says Compilation finished successfully.
Now, if I run gcc -o helloworld helloworld.c, the compiler produces an executable file called helloworld and Geany calls it building. However, the compiler again says Compilation finished successfully.
I understand that the -c option produces an object file, and that multiple of these can be linked together with libraries to produce an executable file, but I am confused about which scenario is compilation and which is building.
Furthermore, if I had just one source file in the project, such as a single helloworld.c file, is gcc -o helloworld helloworld.c enough to turn the source code into an executable?
Thanks
To answer your 2nd question: yes, gcc -o myprog myprog.c is just fine. So is gcc -o myprog *.c or gcc -o myprog foo.c bar.c baz.c.
To answer your first question: technically speaking, there's no word as 'building' :) However, the word 'building' and 'compiling' can be used interchangeably to describe the whole process of producing a final executable from source code.
In a more precise context you would say there is:
preprocessing, when the preprocessor includes header files, expands macros, etc.
parsing, where the parser tokenizes the source text and produces a structured data model (a so-called Abstract Syntax Tree) of the program flow.
compiling or compilation, when a code generator traverses the AST and generates assembly code from it
assembling, when the compiler driver invokes an assembler program which turns the assembly text into binary object code and finally
linking or linkage, when the compiler driver invokes a linker to look up symbols in libraries, fill in missing addresses, etc.
So, strictly speaking, only the 3rd small step is the compilation; furthermore, using the GNU toolchain and make, people tend to call the first four steps (producing an object file from a .c source file) compilation as one.
More on all this here...
Compiling is generally thought of as turning source code into machine code, but not necessarily also linking the machine code to create a final executable. Building is a more general term to describe the whole process of creating the final executable. Building will involve both compiling and linking. If you aren't using the -c option, then the linking is done automatically, so this would be considered building, but compiling was also part of that process.
You may find the terms being used a bit loosely though.
When you compile a program, the compiler just checks if the file has any compile-time errors (such as syntax and semantic errors) in it. When you "build" the program, the compiler first checks for any errors in it, and then converts the source code into machine code (actual compilation) and creates an executable file in the process.
For your second question, yes gcc -o helloworld helloworld.c alone would be enough to "turn the source code into an executable".
When writing a basic c program.
#include <stdio.h>
main(){
printf("program");
}
Is the definition of printf in "stdio.h" or is the printf function automatically linked?
Usually, in stdio.h there's only the prototype; the definition should be inside a library that your object module is automatically linked against (the various msvcrt for VC++ on Windows, libcsomething for gcc on Linux).
By the way, it's <stdio.h>, not "stdio.h".
Usually they are automatically linked, but the compiler is allowed to implement them as it pleases (even by compiler magic).
The #include is still necessary, because it brings the standard functions into scope.
Stricto sensu, the compiler and the linker are different things (and I am not sure that the C standard speaks of compilation & linking, it more abstractly speaks of translation and implementation issues).
For instance, on Linux, you often use gcc to translate your hello.c source file, and gcc is a "driving program" which runs the compiler cc1, the assembler as, the linker ld etc.
On Linux, the <stdio.h> header is an ordinary file. Run gcc -v -Wall -H hello.c -o hello to understand what is happening. The -v option asks gcc to show you the actual programs (cc1 and others) that are used. The -Wall flag asks for all warnings (don't ignore them!). The -H flag asks the compiler to show you the header files which are included.
The header file /usr/include/stdio.h is #include-ing itself other headers. At some point, the declaration of printf is seen, and the compiler parses it and adjust its state accordingly.
Later, the gcc command would run the linker ld and ask it to link the standard C library (on my system /usr/lib/x86_64-linux-gnu/libc.so). This library contains the [object] code of printf
I am not sure to understand your question. Reading wikipedia's page about compilers, linkers, linux kernel, system calls should be useful.
You should not want gcc to link automagically your own additional libraries. That would be confusing. (but if you really wanted to do that with GCC, read about GCC specs file)
I am attempting to cross-compile on AIX with the xlc/xlC compilers.
The code compiles successfully when it uses the default settings on another machine. The code actually successfully compiles with the cross-compilation, but the problem comes from the linker. This is the command which links the objects together:
$(CHILD_OS)/usr/vacpp/bin/xlC -q32 -qnolib -brtl -o $(EXECUTABLE) $(OBJECT_FILES)
-L$(CHILD_OS)/usr/lib
-L$(CHILD_OS)/usr/vacpp/lib/profiled
-L$(CHILD_OS)/usr/vacpp/lib
-L$(CHILD_OS)/usr/vac/lib
-L$(CHILD_OS)/usr/lib
-lc -lC -lnsl -lpthread
-F$(CHILD_OS)$(CUSTOM_CONFIG_FILE_LOCATION)
When I attempt to link the code, I get several Undefined symbols:
.setsockopt(int,int,int,const void*,unsigned long), .socket(int,int,int), .connect(int,const sockaddr*,unsigned long), etc.
I have discovered that the symbols missing are from the standard c library, libc.a. When I looked up the symbols with nm for the libc.a that is being picked up, the symbols do indeed exist. I am guessing that there might be a problem with the C++ being unable to read the C objects, but I am truly shooting in the dark.
Sound like it might be a C++ name mangling problem.
Run nm on the object files to find out the symbols that they are looking for. Then compare the exact names against the libraries.
Then check the compilation commands, to ensure that the right version of the header files is being included - maybe it's including the parent OS's copy by mistake?
I was eventually able to get around this. It looks like I was using the C++ compiler for .c files. Using the xlc compiler instead of the xlC compiler for C files fixed this problem.