C Expert Programming Chapter 5 Thinking about Linking 5.3 5 Special Secrets of Library Linking

Five special secrets of function library connection: (the real situation of UNIX link)
1. The extension of dynamic library file is ".so", while the extension of static library file is ".a"
Shared archives have the filename extension ".sa", and shared archives are just a transitional form to help people transition from static libraries to dynamic libraries.

2. For example, through the -lthread option, the compiler is told to link to libthread.so
In fact, the compiler is told to link to the corresponding function library according to the option -lname, and the name of the function library is libname.so--- In other words, the "lib" part and the file extension are omitted, but a "-l" is added in front.

3. The compiler finds the library in a certain directory
It looks in some special locations and looks for the library in /usr/lib.For example, the thread library is located in /usr/lib/libthread.so.
The compiler option -Lpathname tells the linker some other directories. If the -l option is added to the command, the linker will look in these directories for function libraries.The system environment variables LD_LIBRARY_PATH and LD_RUN_PATH are used to provide this information.The use of environment variables is now deprecated for reasons of security, performance, and creating runtime independence.Generally, the -Lpathname and -Rpathname options are used when linking.

4. Observe the header file to confirm the function library used
A good suggestion is to observe the #include directive used by the program.Each header file included in a program may represent a library that must be linked.But the name of the header file is usually not similar to the name of the function library it corresponds to.
The libraries under solaris 2X
#InClude file name The compiler option used in the reference name of the Kulu Lu Road
/usr/lib/libm.so -lm
/usr/lib/libm.a             -dn -lm
  /usr/lib/libc.so          lib/libx11.so -l/usr/openwin/lib -1X11
/usr/lib/libthread.h-lthread
/usr/libcurses.a-lcurses
      /usr/lib/libsocket.so                 -lsocket
Another inconsistency with library linking is that the library contains definitions of many functions, but the prototype declarations of these functions
is spread across multiple header files.

The nm command browses all symbols in each library in /usr/lib, looking for missing symbols.By default, the linker will look in /usr/cc/lib and /usr/lib, you should start from these two places too, and expand the search further if you can't find it.(eg /usr/openwin/lib)
%cd /usr/lib
%foreach i (lib?*)
?echo $i
?nm $i | grep xdr_refrence | grep -vUNDEF
?end
...
This runs the nm command on all libraries in this directory, it displays a list of symbols known in the library.Set the symbols to be searched by grep, and filter the symbols marked as UNDEF (referenced in the library, but not defined here).It turns out that xdr_reference is in the libnsl library.Requires -lnsl at the end of the compiler command line.

5. Compared with extracting symbols in dynamic libraries, the method of symbol extraction in static libraries is more restrictive.
In dynamic linking, all library symbols enter the virtual address space of the output file, and all symbolsVisible to all files linked together.In contrast, with static linking, when processing the archive, it just looks in the archive for undefined symbols that the loader knows about at the time.In short, the order in which the various statically linked libraries appear on the compiler command line is very important.Symbols are resolved in left-to-right order.If the same symbol is defined differently in two different libraries, and the static library appears in a different order, the results may be different.

Another problem arises if you import the static library before your own code.Because the undefined symbols have not yet appeared at this point, it does not pull any symbols from the library.Then, when the target problem is handled by the linker, all its references to the library will be unimplemented!

libm often exists as a statically linked archive.If your program uses some mathematical functions such as sin(), etc., if you statically link it like this:
cc -lm main.c
You will get an error message, as follows:
Undefined first referenced
symbol in file
sin main.o
ld:fatal: Symbol referencing errors. No output written to a.out
In order to be able to extract the required symbols from the math library, you first need to make the fileContains unresolved references as follows:
cc main.c -lm
The linker uses the convention .

/*Where should the library options be placed*/
Always place the -l library option at the far right of the compile command line

Workspaces can declare functions like the following in the mode that is loaded into the linker, thus providing more clues to the linker:
On the PC, when Borland's compiler driver tries to guess what needs to be linkedThis problem also occurs with floating point numbers.
scanf: floating point formats not linked
abnormal program termination(scanf: floating point formats not linked, program terminated abnormally)
When the program uses floating point formats in scanf() or printf(), butWhen not calling any floating point function, there is a possibility of
guessing wrong
static void forcefloat(float *p) {
float f = *p; forcefloat(&f);
}
You don't need to actually call this function, just make sure it's linked.This gives the Borland PC's linker a sufficiently reliable clue that the floating-point library is indeed needed.
There is also a similar message, when the software requires a numerical coprocessor and the computer does not have it installed, the Microsoft C runtime system prints a message saying "floating point not loaded".This problem can be solved by relinking the program using the floating point number emulation library.