Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
CompilingHowto
Edit
PageHistory
Diff
Info
LikePages
!!! How compiling works under [Linux] (and Unices in general) 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. :) # cpp(1) takes a <tt>.c</tt> and some <tt>.h</tt> files, preprocess the source and generates an <tt>.i</tt> file. This file is the ultimate SourceCode, with all the <tt>#include</tt>s expanded out and all the <tt>#define</tt>s replaced. # gcc(1)then takes the <tt>.i</tt> file and generates a <tt>.s</tt> file (assembler source). # as(1) then takes the <tt>.s</tt> file and generates a <tt>.o</tt> file (object file). 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. # 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. <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 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 </verbatim> 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 * MakefileHowto ---- CategoryHowto
2 pages link to
CompilingHowto
:
UserSubmittedNotes
MakefileHowto
