How is C used in Linux?

Answer 1

C is primarily handled by the GNU C Compiler (GCC) in Linux, which in turn can be used directly by programmers or used by IDEs to build C programs. There are other C compilers available for Linux as well.

As for how they run, well, like in most UNIX or UNIX-like operating systems, there will be a feature-complete compliant standard C library, often used as part of the overall core system. In Linux this is usually the GNU C Library (glibc), but like GCC, there are alternatives in common usage.

The C compilation process can be somewhat complex.

First, the compiler invokes a preprocessor to parse the preprocessor directives (All those statements that begin with #.), which will do things such as modify the source code based on its own logical syntax, replace #includes with the contents of the headers given, etc. This will output a new C source file, the first of a few types of intermediary files created during the compilation. This source file will be devoid of any preprocessor directives and will be raw C code.

Second, a lot of compilers translate the new raw C code into native Assembly for the target architecture. Assembly is as close as you can get to the hardware without it being straight up raw machine language. This outputs Assembly source files.

Third, an assembler runs through all the assembly and finally translates them into machine code binary, usually formatted in the target platform's preferred binary format. In Linux's case, it'll be assembled in ELF format. The output of this are usually "unusable" binaries called object files, one for each source file.

Fourth, a linker makes its first pass, sewing together all of the object files into one (Or possibly several.) "final" binary, which is extremely close to the final product.

Finally, the linker makes its second pass and zips in library information for any shared objects (libraries.) the final binary needs to use to be functional, and, depending on if the binary is meant to be executable, link in libc's start code so it'll start properly. It will, if all these steps go right, output what one hopes to get from this venture: Usable binaries, be they libraries or executables.

Of course, there are often steps that precede and follow the actual build process, but they're not as relevant to C. These steps usually involve running a configure script that makes sure all the needed build requirements are met and that the build environment is sane, not to mention preparing the source code to be better suited to your system for a build so that the binary will run correctly AND optimized.

Following the configure is usually a make operation, which iterates through its build rules and makes sure all source files are built and ultimately linked together, and to save a programmer potential weeks typing out a batch build process, not to mention to include certain build parameters configured by the configure script. After the build a make is often invoked again, usually to install the resultant software, though makefiles are such that there could be a series of things you could do to the software after it is built, such as test suites or post-build configuration.

Also, I didn't mention this, but during the raw C to raw Assembly phase, some compilers will sometimes apply an exhaustive set of optimization rules to your code, usually for speed, but also often for size. This is usually a fine thing to do, but GCC in particular has been known to overzealously apply its optimizations. System software should only be lightly optimized, if at all, by the compiler, meaning that the burden is even heavier on the programmer to write efficient code.

There are some other optimizations, most notably being able to strip debug or unused symbols from a binary to make it leaner, though stripping symbols from a library will rip it to shreds and trash it, so never do that on a library.

Answer 2

The kernel, along with a large majority of programs that run on Linux, were written in C.