FreeTDS User Guide: A Guide to Installing, Configuring, and Running FreeTDS
Prev |  | Next

# Appendix A. On Linkers

> FreeTDS is a library, obviously, its functions invoked by an application. How the application finds the library can be mysterious. In the interest of making FreeTDS easier to use, this appendix discusses how it all works.

> This appendix focusses on using FreeTDS in your application. It isn't intended to help in building FreeTDS, although the background information it provides might be useful.

# What is a C function?

A C function is a named bit of code.

A C compiler recognizes function names in source code by parsing the C language. When it encounters a function name, it looks for a definition for the function — i.e. actual code implementing it — in the current file. If it finds one, it creates machine instructions to push any parameters on the stack, jump to the named address, and clear the stack after the functions returns. If it doesn't find one, it shrugs[1] and adds that name to the list of names to be resolved later. We'll get to what that means in a minute.

The compiler's job ends where the linker's begins.

Compiler's job

- Convert source code into object code

- Put in jumps to defined functions

- Create a list of defined functions, and their addresses

- Create a list of undefined functions

The nm utility displays function names. Here are the ones defined by `bsqldb.c` (in `bsqsldb.o`):

    $ nm bsqldb.o | grep -wi t
    0000000000000000 T err_handler
    0000000000000270 T get_login
    00000000000001d0 t get_printable_size
    0000000000000940 T main
    00000000000000a0 T msg_handler
    00000000000007d0 t next_query
    00000000000006c0 t set_format_string
    0000000000000080 t usage

GNU nm marks with a lower-case letter functions that are locally defined, not intended to be used outside the file. The C programmer marked those functions static. Note how closely the source code corresponds to the object code:

    $ grep ^static src/bsqldb.c
    static int next_query(DBPROCESS *dbproc);
    static void print_results(DBPROCESS *dbproc);
    static int get_printable_size(int type, int size);
    static void usage(const char invoked_as[]);
    static int set_format_string(struct METADATA * meta, const char separator[]);

(Order doesn't matter. It's a set, not a list.)

Here are some functions used, but not defined, by `bsqldb.o`:

    $ nm bsqldb.o | grep -w U | head
                     U __assert_fail
                     U __ctype_b_loc
                     U __errno_location
                     U __strdup
                     U __xpg_basename
                     U asprintf
                     U calloc
                     U dbaltbind
                     U dbaltcolid
                     U dbaltlen

Two things to note. First, the functions defined by `bsqldb.o` have addresses, and undefined functions don't. Second, only the name identifies the function. It's been that way since about 1978, and it's one reason C libraries are so useful: to find a function, the tool need only resolve the name, i.e. convert the name into an address. The caller (the programmer, really) has to know the function's inputs and semantics (how it behaves), but the tool's job is bone simple. Which turns out to be quite handy.

### Notes

[1] | You have to watch carefully. Modern compilers shrug quickly.

Prev | Home | Next
Contributors |  | What is a C library?