Differences between version 5 and revision by previous author of CompilingHowto.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 5 | Last edited on Friday, July 7, 2006 11:47:08 am | by AristotlePagaltzis | Revert |
| Older page: | version 3 | Last edited on Tuesday, November 5, 2002 4:26:50 pm | by JohnMcPherson | Revert |
@@ -1,38 +1,51 @@
-!!!How compiling works under Linux (and Unixies
in general)
+!!! How compiling works under [
Linux]
(and Unices
in general)
-Note this is the long winded
approach,
gcc(1) is smart enough to do most of these steps for you automagically. :)
+Note this is the longwinded
approach to compiling a [C] program.
gcc(1) is smart enough to do most of these steps for you automagically. :)
-When compiling a [C] program the first step is to PreProcess the source. This is done with
cpp(1). This will take
a .c and some .h files and generate you a
.i file( PreProcess''''ed) that has all the #include's expanded out, and all the #defines replaced
.
+#
cpp(1) takes
a <tt>
.c</tt>
and some <tt>
.h</tt>
files, preprocess the source
and generates an <tt>
.i</tt>
file.
-gcc(1) then takes a .i
file and generates a .
s file (assembler information)
.
+ This
file is the ultimate SourceCode, with all the <tt>#include</tt>s expanded out
and all the <tt>#define</tt>
s replaced
.
-as
(1) then takes a
.s
file and generates a .o
file (object file
).
+# gcc
(1)then takes the <tt>
.i</tt>
file and generates a <tt>
.s</tt>
file (assembler source
).
-ld
(1) then takes the .o
file and links it with any libraries as required
and generates an executable or
a library
.
+# as
(1) then takes the <tt>
.s</tt>
file and generates a <tt>.o</tt> file (object file)
.
-strip(1) can then optionally remove
any unneeded information
in the executable (such as debugging information) reducing it's size
.
+ These are fragments of MachineCode with unresolved symbols. This means that the addresses of various variables and subroutines are not yet known, and
any [CPU] instructions that refer to these unknown addresses must be filled
in.
-alternatively
- gcc foo
.c baz.c -
o baz
-will sort the entire thing out for you :
)
-----
-Object files are .o files. They are fragments of code that may have some unresolved symbols. You link
them together
with ld(1) which
resolves all
the symbols from other
.o files or from libraries
.
+# ld(1) then takes the <tt>
.o</tt> file(s
) and links it/
them with any libraries,
resolves the symbols, and generates an executable or <tt>
.a</tt> library
.
-.a files are libraries of .o files.
They are kinda like a .zip file for
.o files. ar(1) is the tool to manage .a files. if
you run ranlib(1) over a .a file
it will create an index of all the symbols making your compiles faster. I believe [GNU] ar(1) keeps the symbol table up to date so ranlib(1) isn't required, but I could be wrong.
+ <tt>a
.out</tt> is the default name given to
a program if none was specified with the <tt>-o</tt> switch. The reason for this is that it used to be the assembler output (before seperate linking was used), and the assembler was called <tt>a</tt>, hence <tt>a</tt>'s <tt>.out</tt> file.
+
+ <tt>.a</tt>
files are libraries of <tt>
.o</tt>
files. They are kinda like TarBall~s of <tt>
.o</tt>
files. ar(1) is the tool to manage them
. If
you run ranlib(1) over such an archive
it will create an index of all the symbols,
making your compiles faster. I believe [GNU] ar(1) keeps the symbol table up to date so ranlib(1) isn't required, but I could be wrong.
+
+# strip(1) can then optionally remove any unneeded information in the executable (such as debugging information) to reduce its size.
+
+Alternatively, <tt>gcc foo.c baz.c -o baz</tt> will sort the entire thing out for you. :)
+
+!! Libraries
libtool(1) is a program to manage libraries in a CrossPlatform manner under Unix.
-Instead of making an executable
, you can make a shared library
by compiling with the flags "
-shared" (this is a shared library),
and -fPIC (
create PositionIndependentCode)
. the -fPIC is optional, if
you don't use it then when the library is loaded into memory ld.so(8) will relocate the symbols for you (See RelocatingSymbols)
which will write to the memory used by the library, and thusly will cause that library not to be shared between processes due to CopyOnWrite.
I don't know why you wouldn't want to use -fPIC
if your platform supports it, so use it :)
+Instead of making a BinaryExecutable
, you can make a SharedLibrary
by compiling with the flags <tt>
-shared</tt>
and <tt>
-fPIC</tt>. The latter is optional; it means to
create PositionIndependentCode. If
you don't use it then when the library is loaded into memory ld.so(8) will relocate the symbols for you which will write to the memory used by the library, and thusly will cause that library not to be shared between processes due to CopyOnWrite. I don't know why you wouldn't want to use PositionIndependentCode
if your platform supports it, so use it.
:)
+
+ <verbatim>
gcc foo.c -shared -fPIC -c -o foo.o
-You can open dynamically loaded modules using dlopen(3).
You can probably link against these, although I've never bothered figuring out how.
+ </verbatim>
-If you want to make a library that is statically compiled into a program then compile it into a .a file called lib''thenameofyourlibrary''.a and put it in some directory. Then when compiling your main program use -L/path/to/the/libraries to make the compiler search that directory and put -l''thenameofyourlibrary'' on the command line. eg
:
+You can open dynamically loaded modules using dlopen(3). You can probably link against these, although I've never bothered figuring out how.
+
+
If you want to make a library that is statically compiled into a program then compile it into a .a file called <tt>
lib''thenameofyourlibrary''.a</tt>
and put it in some directory. Then when compiling your main program use <tt>
-L/path/to/the/libraries</tt>
to make the compiler search that directory and put <tt>
-l''thenameofyourlibrary''</tt>
on the command line. Eg.
:
+
+ <verbatim>
gcc foo.c -c -o foo.o
ar rcs libs/libfoo.a foo.o
ranlib libs/libfoo.a
gcc baz.c -Llibs/ -lfoo -o baz
+ </verbatim>
+
+!! See also
-a.out is the default name given to a program if none was specified with the -o command line option. The reason for this is that it used to be the assembler output (Before seperate linking was used), thus a (the assembler) .out (output).
+* MakefileHowto
----
-SeeAlso MakefileHowto
+CategoryHowto
