Object files vs Library files and why?

Question

I understand the basics of compilation. Source files compiled to object files which the linker then links into executables. These object files are comprised of source files

Answer 1

Object files contain definitions of functions, static variables used by those functions, and other information output by the compiler. This is in a form that can be connected by the linker (linking points where functions are called with the entry points of the function, for example).

Library files are typically packaged to contain one or more object files (and therefore all the information in them). This offers advantages that it is easier to distribute a single library than a bunch of object files (e.g. if distributing compiled objects to another developer to use in their programs) and also makes linking simpler (the linker need to be directed to access fewer files, which makes it easier to create scripts to do linking). Also, typically, there are small performance benefits for the linker - opening one large library file and interpreting its content is more efficient than opening and interpreting the content of lots of small object files, particularly if the linker needs to do multiple passes through them. There are also small advantages that, depending on how hard drives are formatted and managed that a few large files consumes less disk space than a lot of smaller ones.

It is often worth packaging object files into libraries because that is an operation that can be done once, and the benefits are realised numerous times (every time the library is used by the linker to produce the executable).

Since humans comprehend source code better - and therefore have more chance of getting it working right - when it is in small chunks, most large projects consist of a significant number of (relatively) small source files, that get compiled to objects. Assembling object files into libraries - in one step - gives all the benefits I mentioned above, while allowing humans to manage their source code in a way that makes sense to humans rather than linkers.

That said, it is a developer choice to use libraries. The linker doesn't care, and it can take more effort to set up a library and use it than to link together lots of object files. So there is nothing stopping the developer employing a mix of object files and libraries (except for the obvious need to avoid duplication of functions and other things in multiple objects or libraries, which causes the link process to fail). It is, after all, the job of a developer to work out a strategy for managing the building and distribution of their software.

There is actually (at least) two types of library.

Statically linked libraries are used by the linker to build an executable, and compiled code from them is copied by the linker into the executable. Examples are .lib files under windows and .a files under unix. The libraries themselves (typically) do not need to be distributed separately with a program executable, because need parts are IN the executable.

Dynamically linked libraries are loaded into the program at run time. Two advantages are that the executable file is smaller (because it doesn't contain the content of the object files or static libraries) and that multiple executables can use every dynamically linked library (i.e. it is only necessary to distribute/install the libraries once, and all executables which use those libraries will work). Offsetting this is that installation of programs becomes more complicated (the executables will not run if the dynamically linked libraries cannot be found, so installation processes must cope with the potential need to install the libraries at least once). Another advantage is that dynamic libraries can be updated, without having to change the executable - for example, to fix a flaw in one of the functions contained in the library, and therefore fix the functioning of all programs which use that library without changing the executables. Offsetting this is that a program which relies on a recent version of a library may malfunction if only an older version of the library is found when it runs. This gives maintenance concerns with libraries (called by various names, such as DLL hell), particularly when programs rely on multiple dynamically linked libraries. Examples of dynamically linked libraries include DLLs under windows, .so files under unix. Facilities provided by operating systems are often installed - with the operating system - in the form of dynamically linked libraries, which allows all programs (when correctly built) to use the operating system services.

Programs can be developed to use a mix of static and dynamic libraries as well - again at the discretion of the developer. A static library might also be linked into the program, and take care of all the book-keeping associated with using a dynamically loaded library.