Daniel Barlow

Linux Documentation Project

May 1999

This document covers how to set up the GNU C compiler and development libraries under Linux, and gives an overview of compiling, linking, running and debugging programs under it. Most of the material in it has been taken from Mitch D'Souza's GCC-FAQ or the ELF-HOWTO - it replaces both documents.

This is the first version to be written in DocBook instead of the old Linuxdoc format, and may contain markup errors. Please let me know if you find anything worng.

As can be determined from the long times between updates of this document, I don't actually have the time or inclination to maintain it much. If you have, can, and want to, drop me some email describing what you'd do with it and why you think you'd be good at it.

Table of Contents
ELF vs. a.out, libc 5 vs 6
Where to get things
GCC installation and setup
GCC versions
Where did it go?
Where are the header files?
Building cross compilers
Porting and Compiling
Automatically defined symbols
Compiler invocation
Debugging and Profiling
Preventative maintenance (lint)
Shared vs static libraries
Interrogating libraries (`which library is sin() in?')
Finding files
Building your own libraries
Dynamic Loading
Error messages
Controlling the operation of the dynamic loader
Writing programs with dynamic loading
Contacting the developers
Bug reports
Helping with development
The Remains
The Credits


ELF vs. a.out, libc 5 vs 6

Three years ago when this document was first created, I opened this section by saying "Linux development is in a state of flux right now" and going on to describe how ELF was replacing the older a.out binary format.

It still is in a state of flux. It always will be. Though that particular change is long since past, development of the Linux kernel and the surrounding system continues to happen, and things change for developers as a result. So it's a good idea to know upfront what kind of system you have in front of you.

The possible candidates, in order of age, are

  • libc 4, a.out: very old systems

  • libc 5, ELF: Red Hat 4.2, Debian 2.0

  • libc 6 (a.k.a glibc 2), ELF: Red Hat 5 - 5.2, Debian 2.1

  • libc 6.1,(a.k.a glibc 2.1) ELF: Red Hat 6

How to tell? The simplest approach is to pick a binary that you consider is typical (e.g. /bin/ls and run ldd on it. One of the listed libraries should be libc - check its version number.
$ ldd /bin/ls => /lib/ (0x4000e000)
        /lib/ => /lib/ (0x40000000)

This document was created on a Debian 2.1 system, so no surprise there.

It's entirely possible that the system you're using may have a mix of different versions on it. What you probably want to know in that case is the version that its C development environment is set up for, so you're best off compiling "hello world" and running ldd on the output thus created. Note that for historical reasons, gcc defaults to an output file called a.out even on ELF systems, so don't assume anything from that.


The copyright information and like legalese can be found at the end of this document, together with the statutory warnings about asking dumb questions on Usenet, revealing your ignorance of the C language by reporting bugs which aren't, and picking your nose while chewing gum.


If you're reading this in Postscipt, dvi, or html format, you get to see a little more font variation than people with the plain text version. In particular, filenames, commands, command output and source code excerpts are set in some form of typewriter font, whereas `variables' and random things that need emphasizing are emphasized.

You also get a usable index. In dvi or postscript, the numbers in the index are section numbers. In HTML they're just sequentially assigned numbers that you can click on. In the plain text version, they really are just numbers. Get an upgrade!

The Bourne (rather than C) shell syntax is used in examples. C shell users will want to use
% setenv FOO bar
where I have written
$ FOO=bar; export FOO

If the prompt shown is # rather than $, the command shown will probably only work as root. Of course, I accept no responsibility for anything that happens to your system as a result of trying these examples. Have a nice day :-)