Avinash Prasad
                              CSP301   


        Linking And Compiling                                     Doxygen & Latex                               CVS


REVISION


The Compiler Action:
                  Anything after preprocessing stage is architecture dependent.
Object Files:
                Object files  contain the binary representation of code and data from source files -along with information needed for relocation and linking.
                'nm' that we saw in the class is a tool  to see this symbol information while 'objdump' can be used to  obtain a lot more information about the
                object files.   (Use man pages to see the plethora of options and information that come with these two tools)

                 Type of object files
                In addition there are shared object files that can be added and relocated at link time or load time. We will soon learn about the special advantages from the same.


CLASS III

Linking :

            Everything compiled as object (prior to the linking stage) has
            Intentions at link time are to resolve as many undefined symbols as possible.
            The types of symbols that we can possible have are:


             The linking process proceeds with these symbols as followed:
            To simplify things lets consider linking process for a  static binary  in very simple words.
                            As we scan the files specified to be included in compilation we build a pool each for  undefined  ,  defined  symbols. Keep resolving undefined symbols in the
             pool and addending to the defined pool as new  defined symbols are encountered. Do it for all the files being linked  or any static libraries being compiled against.
             At the end of it all if the pool of undefined symbols has shrunk to zero we have a successful attempt as symbol resolution.

Programming Tips: If you get errors reporting redecleration of variables in files of type (/tmp/xxxxxxxx) this could be a possible reason.
                                 From the way this is done it is apperent that static libraries must be placed at the end. Special care must be taken when cyclic dependencies exist between the                                      libraries.

             Linking also requires relocation since all the object files have addresses calculated relative to zero.

             The steps involved are:
             Have a look at 'objdump -r a.o'  we will see a set of relocation records generated in relocatable object files that are used now to set the entry for any
             undefined reference right.


Working with Shared Libraries:
            
             Advantages:

          Command format :   gcc -shared(make shared) -fPIC (standing for Position independent code) -o libuseless.so(output lib) a.o b.o

          Linking to the shared library:
          Imagine a situation when the library changes since the time of compilation. In that case the addresses in the library may change causing the binary to be broken
          So only minor changes in the libaray are possible with relinking in case of statically linked shared files.

          On the other hand dynamic linking of shared libraries at runtime causes a cost to be incurred  at every run of the program , but this allows for quite change in libraries
          without  any  hassles  of relinking you executables agains them. But this demands strict adherence to API on the part of executable programmers and library programmers
          as this may cause unforseen changes in the behavious of the executables.


Tools to plav with:
          gcc, ar, objdump , nm, ldd( use it on any binary to see what all libraries it is linked against),strip(to strip off symbol table information-- use it only on linked object files)

Moving On: Using Make

           Lets get back to the bussiness of code organization again.

          As you might remember there were a sequence of steps that we followed to get an executable. Remembering them and performing them in order may give headaches to
          programmers. You can device many ways to perform the same sequence of operations by a single command.

         Some one got a noble idea about checking the files for update  and recompiling only those files that get effected by the changes made. This can save a lot of compilation time              for  large projects.


          This notion got formalized into the 'make' utility which is a framework to do just what we said above. It works on the principle of dependency that must be satisfied to
          complete a certain target. The utility parses a file named 'makefile' or 'Makefile by default.

          For example:                                
                                                            target : source file(s)
                                                                    
command (must be preceded by a tab)

         The directive here says that the target file shall be compiled only if its source files are modified. Here 'command ' represents all the action that must be taken in that order to          fulfill the target directive.  ( do 'info make ' to obtain all the information on make and the format of makefiles)

        Make process is recursive, i.e. is execution of one directive depends on another  then the other directive is satisfied before execution of first occurs.
          Make is capable of perfoming non-compilation tasks ( and is heavily used for installing executables). (clean etc)
            Make supports regular expressions ,implicit rule, macros etc. ( *.c , %.o : %.c)
             Make supports variables and creation of environment ($CC=gcc  , $VPATH =.....(search path for target source files)....)


Programming Tips:  Its good to see the use of  the default variables they make the task of making general makefiles easier.
                                  Phony  directive should be used whenever the target  isn't a files but just a comand  to be executed.
                                 
        

                                                            



          
         
         
         

             
            
                     
                                 


Thanks  -- Avinash                                                                                                                                                                                                                                                         ...stride away