Example makefile created by a text editor and put in the directory where c and h files reside.

<target filename>: <source filename>.c <source filename>.h
    gcc -g <filename>.c  -o <filename>
clean:
    rm -f *.o
# is the character to define the line as comment

The makefile for the split hello world file would look like:

hello: hello.o printhello.o
    gcc hello.o printhello.o -o hello
hello.o: hello.c
    gcc -c hello.c
printhello.o:printhello.c
     gcc -c printhello.c
clean:
     rm -f *.o 

To not edit everywhere when the make file is getting used for a new project or if the files get a new name or if you want to set standard compiler options, you can work with variables:

name=hello
include=printhello
$(name): $(name).o $(include).o
    gcc $(name).o $(include).o -o $(name)
$(name).o: $(name).c
    gcc -c $(name).c
$(include).o:$(include).c
     gcc -c $(include).c
clean:
     rm -f *.o 

If some files are in other directories then the -I option can be used to pass the path:

-I/<path to file>

To compile, open a shell and go to directory, then type make.

Per default the destination files of gcc are called a.out. The option -o selects an other name.

Having added the clean section in the makefile as shown above, the command make clean cleans the directory from object files no longer used.

Finally be aware that gcc is normally used to emerge <Gentoo ebuilds> and is therefore set to produce code optimized for speed. The variables defined in /etc/make.conf are passed to gcc, so check those options

CHOST="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"

Those options are OK, but the -fomit-frame-pointer produces long reaction time when you debug your c program. Therefore you might consider to change /etc/make.conf while you are in a longer debug session.

Built runnable binaries can be copied to /usr/local/bin to be used outside of the development environment. Better would be putting just links there to your executable and add a version number to your executable file name. So you are prepared for new versions. However you should not copy executables manually, you should install them following the rules of your Linux distribution to not make a mess. For Gentoo this means you should write an ebuild.

to debug in the console start gdb by gdb<my program>

Then type some commands as:

Is what it should to be a modern easy to go and intuitive gui debugger

Insight is an other front-end for gdb. It uses tk.tcl and wants it in a certain location, otherwise it fails.

An other front-end for gdb is ddd. It is rather ugly and not intuitive. To debug an executable it has to be called in command line ddd<name of executable>. Even it is ugly it works well.

To use Libraries include

#include <math.h> 

to the source code, but this might not be enough.

/usr/lib contains the mathematic library libm. To use it with gcc you must tell gcc by adding -lm that you want it. -l stands for including libraries and m is the short name of libm, where lib gets wiped off. So the gcc command line in the makefile becomes:

gcc -g <source>.c -lm -o <source>

This has to be done for all libraries. The only exception is glibc the global C library.

For the libncurses add: -lcurses

For libraries not in /usr/lib the option -L can be used to tell gcc where they are.

-L /usr/X11R6/lib

Instead of finding out where the libraries are and use this hard coded pkg-config can be used. It will be available after emerge pkgconfig. To see what it does call it as:

pkg-config --libs --cflags modbus and when you have libmodbus installed you get: -lmodbus

After this test you will understand what the following does:

gcc random-test-slave.c -o random-test-slave `pkg-config --libs --cflags modbus`

If code is used again and again, then it is time to put it into a library and make it easily available. The code is compiled as usual with the -c option so the linker will not be involved. The following shows how the split hello world program makes use of a library:

gcc -c printhello.c

The output is a object file printhello.o. A number of such files can be added into a library archive <library>.a

ar r<library>.a <code1>.o <code2>.o

For the printhello.o the command looks as:

ar r libhello.a printhello.o

After running ar, ranlib can be used to add an index of the contents to the file to speed up its use.

ranlib libhello.a

Using the following commands the content of a library can be observed

ar t libhello.a

nm -s libhello.a

After having the library it can be used as:

gcc -o hello hello.c libhello.a

or

gcc -o<program> <program>.c /<path to>/<library>. a

or as standard libraries in /usr/lib but telling with -L where the library is

gcc -o<program> <program>.c -L/<path to library> -l<library-lib>

or for the hello world

gcc -o hello hello.c -L/<path> -lhello

Note, that using this commands the library code is inserted to the program, therefore it is called statically linked libraries. With each program using the library code, a copy of the library code is loaded into the memory.

Statically linked libraries can reside multiple times in the memory. More ideal would be loading the library into memory with the first program demanding it and then share it with all demanding programs. This is the concept of the dynamically linked libraries. Those files end with .so (shared object) suffixes in their names.

Since the library and program are separate files there is a potential for a version conflict. Additionally dynamically linked libraries must be known by the operating system, this is an additional potential to run in troubles.

Version numbers are added to the files. To have a certain flexibility when the version numbers do not match exactly, there is a major and a minor version number. The shared object files appear therefore in multiple forms:

When the program gets loaded by the run-time linker, /lib/ld.so or /lib/ld-linux.so, Linux needs to know where the library is, this information comes out of the linker cache /etc/ld.so.conf that is a binary file and ldconfig updates it. The directories where shared objects are to be expected are listed in: /etc/ld.so.conf. If it will not be found in the linker cache (where just the most recent are) then it will scan certain directories.

The addresses where the code in dynamically linked libraries are placed can not be fixed. Therefore Position Independent Code (PIC) is required that is created with the gcc option -fPIC. To build a shared object compile the code as:

gcc -fPIC -c printhello.c

Then link it to a shared object

ld -shared -soname libhello.so.1 -o libhello.so.1.0 -lc printhello.o

then as root, copy libhello.so.1.0 to /usr/lib, /lib or /usr/local/lib>

create necessary links and cache

ldconfig -v -n

Now an application to test the shared object is necessary. Assuming the shared object has been put in /usr/lib the following command applies:

gcc -o hello hello.c -L/usr/lib -lhello

And now it can be tested:

./hello

To observe what the system knows about it and to get information when trouble shooting, the following commands can be used:

To see dependency of the test program hello:

ldd hello

linux-gate.so.1 => (0xffffe000)

libhello.so.1 => /usr/lib/libhello.so.1 (0xb7f73000)

libc.so.6 => /lib/libc.so.6 (0xb7e4b000)

/lib/ld-linux.so.2 (0xb7f99000)

To see other stuff about the program (as 32 bit or 64 bit):

file hello

hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

To see whats inside the shared object:

nm libhello.so.1.0

00001f4c a _DYNAMIC

00001ff4 a _GLOBAL_OFFSET_TABLE_

00002004 A __bss_start

00000276 t __i686.get_pc_thunk.bx

00002004 A _edata

00002004 A _end

00000250 T printhello

U puts@@GLIBC_2.0

Or even more

objdump -x libhello.so.1.0

Inside the shared object there two functions can be added that will be called each time the library is accessed. The following is a sample code that prints those events to the screen:

void _init()
{
  printf("Inside _init()\n"); 
}

void _fini()
{
  printf("Inside _fini()\n"); 
}