linux crash course c programming

• Changes high level language code into assembly code • Here code is optimized by the compiler there are varying levels of optimization • The better the compiler, the neater and more eff

Old Chapter 10:

Programming Tools

A Developer’s Candy Store

UNIX/Linux and Programming

• Since the OS and most of the tools are

written in C, continued development

necessitated a thorough set of C

development tools

• Over time, many other languages found their way to UNIX/Linux, making it an excellent

development platform

• Machine Independent + Portable +

Standards Based = Great for Development

• We’ll focus on C, but these processes extend

to most other compiled languages

• Scripting languages are different –

interpreted (ex perl, python, shell scripts)

Compiling and Linking

Preprocessor

Compiler

Assembler

Linker

• Directives in C/C++ files

• #include include_file

– Inserts code files from other locations

– Can be files you’ve written, or standard library files

• Ex:

– #include “myHeader.h”

– #include <stdio.h>

• Changes high level language code into

assembly code

• Here code is optimized by the compiler

(there are varying levels of optimization)

• The better the compiler, the neater and more efficient this code is

• Assembly code is then turned into readable object code

machine-• Each code file compiled and assembled

creates a file with a o extension

• These are binary files – not readable by

human eye

• The last step is to combine all the object

code into one executable

• Combines with system libraries with common function calls – system specific

• Executables are in Executable and Linking

Format (ELF) – standardized

Shared Libraries

• Most systems contain a collection of

standard shared libraries

• Contain standard defined functions, written for the specific OS and machine architecture

• Most often found in /lib, /usr/lib

• If you’ve got a 64-bit system – also have

/lib64 and /usr/lib64

• Also /usr/X11R6/lib for X Windows apps

Shared Libraries, con’t

• Two types of shared libraries

• Dynamic – not linked when compiled, called upon execution

• Static – linked when compiled, any changes

to library forces recompilation of program

• To see what libraries a program uses, use ldd

• When you change a source file that is

referenced by other files, you have to

recompile your program

• If your program has a great deal of source files, it can be hard to remember what is dependent on what

• Enter make

make con’t

• make will only recompile files that it needs to

• Checks modification dates to see if any

dependent files need to be recompiled

• Uses a file called a Makefile to keep track of the dependencies

• Saves time and is convenient

Makefile example

form: size.o length.o

gcc –o form size.o length.o size.o: size.c form.h

gcc –c size.c

length.o: length.c form.h

gcc –c length.c

form.h: num.h table.h

cat num.h table.h > form.h

clean:

rm *.o *core*

make con’t

• When you run make without arguments, it

will attempt to build the first target in the file

• So the end result (complete program) should

be the first line

• You can force make to build any target by

issuing it as an argument

– Ex: make clean

• CFLAGS – C compiler flags

• CPPFLAGS – C++ compiler flags

• COMPILE.c – translates to:

$(CC) –c $(CFLAGS) $(CPPFLAGS)

Advanced Makefiles con’t

• LDFLAGS – linker flags

• LINK.c – translates to:

$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS)

• FILES – list of source files

• HEADERS – list of header files

• OBJECTS – list of object files

• First level of debugging is simply putting breaks and print statements in your code

• Can be time consuming

• To help prevent problems tell compiler to show warnings about common mistakes

• gcc –Wall will show all warnings

• Lets you trace through memory dumps to

see where run time errors occur

• GNU gdb symbolic debugger

• Compile programs with –g to allow

debugging

• This adds debugging information to program,

a list of symbols that relate to variables and functions

• Also allows you to associate system calls in executable to lines in source file

gdb con’t

• gdb is very robust and complex, lots of

commands and options

• Other graphic front ends are available, but at the command line your best bet is probably going to be gdb

System Calls

• Kernel is responsible for process control,

filesystem management, and operation of peripheral devices

• We have access to these kernel abilities via system calls

• The system works directly on our behalf

• Depending on the operation you may need elevated privileges

Important system calls

• fork() – create new process

• exec() – runs program in memory

• getpid() – get a process ID

• kill() – terminates a process

• open() – open a file

• read() – read an open file

• write() – write to an open file

CVS: Source Code Management

• When multiple people are working on a

project, source code management becomes

an issue

• Need something to keep track of revisions, and make sure users don’t step on one

another

• Enter CVS – Concurrent Versions System

– Developed from Revision Control System (RCS)

• Allows users to check out source code,

modify it, the check it back in and integrate their changes

• When you check out files, a copy is made for you to edit

• Originals are kept in data store

• You then can commit your changes to the

store

CVS con’t

• Syntax:

cvs [cvs-options] command [options]

• Commands include:

– checkout – get copy of source

– commit – submit changes

– update – check for changes made by others – add – add new file to project

– delete – remove file from project