Examples for different types of library linking
-----------------------------------------------

Go to each of three directories

Read Makefile. 

Then type:
	make
	experiment on executable using ls -l, objdump, readelf, ldd to review size, dissassemble, view ibraries ...
	run executable (also on another system if statically linked to verify it works)
	make clean (is everything clean again?)

The three directories show:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
01_STATIC_LIB_LINK_AT_COMPILE_TIME
#Static library linked at compile time

gcc -c addvec.c
gcc -c multvec.c
ar rcs libvector.a addvec.o multvec.o
#(ar -t to see contents) (may also see ar -cvq) 
gcc -c main.c
gcc -static -o prog2c main.o libvector.a (OR gcc -static main.o -L. -lvector)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
02_SHARED_LIB_LINK_COMPILE_TIME_export_LD_LIBRARY_PATH
#Shared library linked at compile time

gcc -c -fPIC addvec.c
gcc -c -fPIC multvec.c
gcc -shared -o libvec.so addvec.o multvec.o 
                                             OR IN ONE STEP INSTEAD OF 3 STEPS
                                             gcc -shared -o libvec.so -fPIC addvec.c multvec.c
gcc -c main.c
gcc -o prog2c main.o libvec.so
                                             OR
                                             gcc -o prog2c main.o ./libvec.so
                                             OR
                                             gcc -o prog2c main.o -Wl,-rpath ./ -L./ libvec.so
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
03_SHARED_LIB_LINK_RUN_TIME  (Dynamic Library)
#Shared library linked at run time
gcc -c -fPIC addvec.c
gcc -c -fPIC multvec.c
gcc -shared -o libvec.so addvec.o multvec.o 
                                             OR IN ONE STEP INSTEAD OF 3 STEPS
                                             gcc -shared -o libvec.so -fPIC addvec.c multvec.c
gcc -rdynamic -o prog2c main.c -Wl,-rpath ./ -L./ -lvec
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Also, experiment with

1) gcc (our compiler), in particular what flags: -c, -O, -DVARIABLE, -ggdb, and -pg do? 

   ld (our linker)

2) ldd - view non-static library dependencies in object code
   ar tf OR nm -> .o files and functions dependencies for static lib
   nm -D OR nm -dynamic -> .o files and functions dependencies for shared lib

3) Notice that for static/shared library linking (i.e. using -l) to work you must
   a) pre-add library_path to /etc/ld.so.conf (what the system undestands) and run /sbin/ldconfig
      (or commonly add to preexisting /usr/lib)
   b) run ldconfig -n library_path_to & link with -Lpath -> good until system reboot
   c) Set LD_LIBRARY_PATH (worse, security issues, why?)


4) readelf -d (symbols for shared library)
   readelf -a for all
   man readelf....

   objdump -Dx (disassemble & all headers)
           -dx (dissassemble instr parts & all headers)
           -x
           -j .data -j .got (show only for these sections)
   
Other related commands: hexdump
Other interesting commands: bindiff, binwalk

/* The difference between readelf and objdump:

   Both programs are capable of displaying the contents of ELF format files,
   so why does the binutils project have two file dumpers ?

   The reason is that objdump sees an ELF file through a BFD filter of the
   world; if BFD has a bug where, say, it disagrees about a machine constant
   in e_flags, then the odds are good that it will remain internally
   consistent.  The linker sees it the BFD way, objdump sees it the BFD way,
   GAS sees it the BFD way.  There was need for a tool to go find out what
   the file actually says.

   This is why the readelf program does not link against the BFD library - it
   exists as an independent program to help verify the correct working of BFD.

   There is also the case that readelf can provide more information about an
   ELF file than is provided by objdump.  In particular it can display DWARF
   debugging information which (at the moment) objdump cannot.  *
