[NTLUG:Discuss] re-linking????

[Richard Cobbe]

Lo, on Saturday, 15 April, 2000, aal did write:

> Kevin Brannen wrote:
> 
> > aal wrote:
> > >
> > > I have an executable that says I need to relink it....How do I go about
> > > that?
> >
> > Get the source, and recompile -- following the instructions in the
> > README/BUILDING/INSTALL file (whatever it uses).
> >
> 
> ok
> so re-linking is just another word for recompiling??
> 

No.  Compiling and linking are in fact two separate phases of the build
process.  However, unless you've got the .o's around from a previous build,
you'll have to re-compile the program as well.

(The rest of this post gets pretty technical; those of you who don't care
about the details of C/C++/Unix development may wish to hit 'n' and move
on.)

It is common for large programs to be split into multiple source files for
ease of management.  Each of these source files may refer to routines and
data in the other files.  Each file is compiled separately; this simply
translates the data and routines within that one file to machine language,
but does not resolve the references to other files.  Linking is the process
of resolving all of those inter-file dependencies.

So, for example, I've got a program that's in 3 separate C source files:
x.c, y.c, and z.c, and I use some routines in the standard C math library,
which (IIRC) isn't linked in by default.  Like most compilers, gcc allows
you to compile and link in one step:

$ gcc x.c y.c z.c -o program -lm

but you can do it separately:

$ gcc -c x.c -o x.o
$ gcc -c y.c -o y.o
$ gcc -c z.c -o z.o
$ gcc x.o y.o z.o -o program -lm

The first three lines simply compile each file into a separate "object"
file, without linking.  The object file x.o is a file containing the binary
code for the stuff in x.c, plus enough information to allow the linker to
go through and resolve all of the references between x and the rest of the
program (including the math library, specified by -lm) later.  The last
line links all three objects together with the math library, resolving
these references, and creating the executable named `program.'

The linker is in fact a separate program, /usr/bin/ld, so you could do the
link stage manually if you wanted.  However, when you use the compiler to
do the linking, it also links in several object files and a library or two
that are required for most C/C++ programs.  In addition, the linker command
line options and scripting language are pretty daunting.  Because of these
issues, people usually let the compiler do it.

Why split a program up like this?  It's better organization, but it can
also cut down on compilation time.  If I'm testing my sample program and I
find a bug somewhere in y.c, all I have to do is recompile y.c and then
relink -- I don't have to touch x.o or z.o at all.  (In practice, it's
rarely that simple, but you still generally come out ahead with separate
compilation like this.)  Programmers usually set up makefiles to simplify
this process; see make(1) for a brief overview of what make does.

The above is a bit of a simplification, but that's the general idea.

Richard