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.
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 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.
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
$ 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 usageGNU 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 dbaltlenTwo 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.
You have to watch carefully. Modern compilers shrug quickly.