Libraries

Student writes all the code for an executable program. The only other code used is from standard libraries, which are automatically handled for you.

• On a large program, very rarely will one developer write all the code
• Even if you write the core functionality, your program must adapt to the executable environment and must consider command-line options, multiple input formats, multiple output formats, etc.
• Most programs use libraries besides that of the standard libraries
• Most of the libraries used are not header-file (include-file) only
• For most libraries, you may not have access to the source, or if you do, you cannot change it
• How these libraries are organized is part of the physical design
• Must understand how libraries work

Compile

• Compiles a single source file to object code
• Default output filename for object code
• Optimization levels: -O1, -O2, -O3, where higher is faster executable code but takes longer to compile and potentially has a larger object size
• nm displays the name list (symbol table) of the object code
• T is the external text (code) section
• Also have to compile incr.cpp
• U is externally undefined (does not exist in this file)

Link

• Creates the executable program incr
• All of our source code (in object form) is in the executable
• If we want to use the increment.cpp code in another executable, it would be duplicated
• Becomes complicated if there is more than one source-code file that our main program (incr) wants to use, e.g., suppose a decrement.cpp

Create Static Library

• A static library contains the object code of (potentially) multiple source files
• Existing object code is added to the library
• Static libraries have the extension ".a"
• The name of a static library is prefixed with lib
• Use the ar command (man ar) to create and view static libraries

Link to Static Library

• The object code for increment.cpp is now in the static library libincrement.a
• The -L option tells the compiler where the static library files are. In this case, the current directory
• The -l option tells the compiler to link in the object code from the static library, where the prefix lib of the library name libincrement.a is assumed

Executable with Static Library

• At this point, we can run the program without the static library, as all of our code is in the executable
• If we delete the library or change the increment.cpp and recompile, it does not affect our executable incr
• Updates to functions from a static library require the executable to be relinked

Static Libraries

• Object files collected into a library archive maintained using ar
• Uses .a extension
• GCC compiler has a standard set of libraries that it includes
• libc Standard C library (glibc on Linux)
• libgcc GCC runtime support library
• libstdc++ C++ standard library
• Must tell the compiler if you want to use any other libraries with the -l option
• Standard library directories: /lib, /usr/lib, /lib64, /usr/lib64
• Some Linux distributions (Ubuntu) also look in /usr/local/lib. Some of the RPM distributions do, e.g., OpenSUSE, and some do not, e.g., Fedora, CentOS

Static Libraries Platform Differences

Create Shared Library

• A shared library contains the object code of (potentially) multiple source files
• Difference of a shared library with a static library is that the object code is not linked into the executable, but shared at run time
• The option -shared makes it a shared library
• Shared libraries on Linux have a .so extension (short for shared object)
• Shared libraries on macOS have a .dylib extension (short for dynamic library)
• Object code in a shared library must contain PIC (Position Independent Code) achieved via the option -fPIC

Position Independent Code (PIC)

• Without PIC, the compiled code runs at a fixed memory address
• With PIC, allows functions to be loaded at any position in memory
• Optional for object code in a static library
• Required for object code in a shared library
• Makes accessing functions and global variables indirect
• Calls to code in the library are slightly slower, and the library is slightly larger
• Program builds either build once with -fPIC on, and store in both static and shared libraries, or build twice, one with -fPIC on for the shared library, and one with -fPIC not on for the static library.

Link to Shared Library

• The -L option tells the compiler where the shared library files are. In this case, the current directory.
• The -l option tells the compiler to link in the object code from the shared library, where the prefix lib of the library name libincrement.so is assumed
• The object code is for increment() is not in the executable incr. However, the executable incr knows how to call the function

Executable with Shared Library

• At this point, when we run the program, we get an error
• The problem is that the executable, incr, cannot find the shared library and needs the object code for increment()

Viewing Shared Library Usage

• To view the use of shared libraries, use the ldd command on Linux and the otool -L command on macOS
• May have to use sudo in front of the ldd command
• Note that libincrement is "not found"

Temporary Fix for Executable with Shared Library

• We need to tell the executable where to find the shared library
• The path variable LD_LIBRARY_PATH is a temporary way of doing this
• Here, we indicate to search in the current directory

Install Shared Library

• To install, copy the shared library to a known library directory
• Typically, this is something like /usr/lib or /usr/local/lib
• May have to use sudo for the cp command due to the destination location
• Just copying the library is not enough, as the list of libraries is cached by the O.S.
• The command ldconfig (man ldconfig) updates this cache
• Note what the ldd command now shows
• Install programs often do this as part of the installation process

Locating Shared Libraries

• Standard directories for libraries are the best choice
• Sibling directories often used for alternative package managers, e.g., brew uses /opt/homebrew/bin for Apple Silicon Macs and /opt/homebrew/lib for Intel Macs (or in Rosetta2)
• Same directory often used during development (CMake handles this nicely automatically during builds)
• CMake runtime search path for Linux:
• CMake runtime search path for macOS:

Advantages of Shared Libraries

• When we update a shared library and rerun the program, we get the new behavior
• All executables share the same library, leading to smaller executable programs
• Easier to update as we install a new shared library, restart the computer, and all executables are using the new library
• Updating a shared library does not require the programs to be relinked

Versioning

• User-facing applications/operating systems are versioned with numbers, e.g., iOS 18, and often include names, e.g., macOS Sequoia 15.4.1
• Sometimes the number is a build number or even a hash
• Versions of libraries are important as the API may change over time
• Some changes are breaking changes, e.g., rename a method
• But not all changes to an API are breaking changes, e.g., add new methods
• And we need to update for bug fixes, security enhancements, optimization, etc.

Semantic Versioning

• Form of MAJOR.MINOR.PATCH
• MAJOR when you make incompatible API changes
• MINOR when you add functionality in a backward-compatible manner
• PATCH when you make backward-compatible bug fixes

SONAMES

• sonames are names embedded in a shared library that indicate a particular version
• The name of the shared library is now libincrement.so.1.0.0
• The option -Wl forwards options to the linker
• The linker option -soname,libincrement.so.1 sets the soname field of the shared library to libincrement.so.1
• ldconfig generates the appropriate symbolic link
• On macOS, the names are in the form of libincrement.1.0.0.dylib, with symbolic links to libincrement.1.dylib and libincrement.dylib

Packaging

• Three packages, libincrement1 the library, incr the application, and libincrement1-dev the development package
• The libincrement1-dev adds the symbolic link for libincrement1.so to get the latest version during development
• The libincrement1-dev also adds the static library
• Both packages incr and libincrement1-dev depend on the package libincrement1

Multiple Platforms

• Separate steps for library creation, library installation, and linking executables
• Configurations are different on different platforms, e.g., Linux, macOS, and Windows. This can include filenames, file extensions, directories, etc.
• In Windows, "shared" libraries (DLLs) for an executable are often placed in the same directory as the executable program instead of a central location. If multiple applications use a library, the library is duplicated on the system. This is to avoid DLL Hell.
• All of this can even be different between versions of the same platform, e.g., Ubuntu 22.04 and 24.04
• Handling of multiple architectures, i.e., arm64 and amd64 (x86), can be different, e.g., Linux has separate libraries for each, macOS has multi-architecture libraries
• Mostly handled by tools such as CMake