Software Development Toolchain

• Volunteer notetakers are needed to share class notes with students registered with Student Accessibility Services.
• Volunteers make a one-semester commitment and notes are shared only with approved students.
• More info: uoguel.ph/notetaker

What is a Tool Chain?

• Developing software projects is inherently linked to the development tools, languages, libraries, and the additional software.
• The term "tool chain" describes the sequence of software tools converting source code (text files) into binary code.
• A tool chain includes more than just the compiler and involves a sequence of tools.

Course Overview

• This course uses C for the "native" portion (A1-A2) and Python/SQL for the UI/database portion (A3).
• The first half of the course will cover C.
• It will also cover tools used by C programmers working with *nix-family OS.
• The lecture will then show how they "chain" in sequence with each other.
• The course raises tools knowledge from the level of ritualized to one of knowledge.

The Common Tools

• C Preprocessor
• C Compiler
• Linker
• Loader
• Make

IDE

• Integrated Development Environments (IDEs) manage tools.
• An IDE is an Interactive Development Environment.
• Windows Visual Studio is available on other platforms.
• macOS has Xcode for its IDE.
• Multi-platform IDEs: Eclipse, IntelliJ, Codelite, CodeBlocks.
• Different languages have different tool chains, as it's possible for an IDE to accommodate more than one.

C Compilers

• Several C compilers exist.
• Popular FOSS compilers:
• GNU Compiler Collection (GCC) is widely usage.
  • It's free, open-source, and often installed default with Linux.
• Clang is a more recent alternative to GCC.
  • It's free, open-source, available on many platforms, installed on macOS with Xcode
• GCC and Clang implement C standards and provide custom extensions.
• The course uses the C compiler from GCC.

How the C toolchain works

• Files within the project include .h and .c extensions

• Those go through several stages.

• C Preprocessor (cpp*):

  • Uses command line options CPPFLAGS and LDFLAGS
  • Output an .i file

• C Compiler (gcc*):

  • Uses command line options CFLAGS
  • Outputs a .s file

• Assembler (gas):

  • Uses command line options SFLAGS
  • Outputs a .o or .obj file

• Linker (ld*):

  • Links .o/.obj files with other .a/.lib and .so/.dll resources
  • Outputs an executable: prog.out, a.out, .exe

• Loader:

  • loads the new executable with ld.so and possibly dlopen
  • Loads into the process memory

• Make can manage the process

• Build time data flows up the chain to runtime

Intermediate Files Note

• Intermediate files (.i, .s, .o) are not always generated by default.
• The use of the .o files are sometimes created.
• .i and .s files are not usually needed.
• To view them, use the -save-temps flag when compiling.

C Preprocessor Explained

• Purpose is to interpret the # directives in .h and .c files before the compiler processes the source code.
• #include: merges header files.
• #define: creates macros, with or without arguments. Expanded by processor.
• #ifdef, if, else, endif: used for conditional compilation.
• #pragma: passed as a compiler directive only ignored if the compiler doesn't recognize it.
• "cpp" is often used as abbreviation for the C preprocessor, which is confusing because "cpp" is also a common acronym and an extension for C++ source files.
• "cpp" means "C preprocessor"

Prevent includes

• Best practice pattern is the ".h" pattern
• In file headername.h:
  • #ifndef HEADERNAME_H
  • #define HEADERNAME_H
  • ...body of .h file...
  • #endif
• The symbol HEADERNAME_H gets created on the first #include “headername.h”
• File contents are skipped, if included again

Headers and Paths

• The #include directive has different syntax for different headers.

• #include <file>: for system header files.

  • Searches a standard list directory for the file.

• #include "file": header files of programs.

  • Searches a file named file as follows:
    • first in the directory containing the current file.
    • then in the "quote" directories.
    • then the same directories used for <file>.

• Paths to the file must no go in the #include statement.

• Not: #include "../includeDir/Parser.h"

• If files move, the path breaks

• Include the file itself: #include "Parser.h".

• The compiler toolchain will deal with the paths.

• You can use -I option to pass header file directories to the compiler.

  • gcc -I../includeDir myFile.c
  • gcc -I../includeDir -I/home/username/stuff/otherIncludeDir myFile.c

• Paths used in a command can be relative or absolute.

C Compiler tool explained

• Purpose: Compile C language source code (.i file) into assembly language (.s).
• Issues warnings/errors and diagnoses abuses of language.
• Intermediate .i and .s files deleted after assembly unless requested with the -save-temps option.
• See the sample .c, .i, .s, etc. files in the GCC_intermediate_files.zip example.
• Compile with gcc -save-temps test.c.

Assembler

• Purpose: Assemble assembly code (.s) from compiler into object code (.o).
• This step is very transparent.
• There are rarely used options to control settings.
• Assembly statements can utilize vector instructions for the CPU's vector processing unit.

Linker

• It stitches together objects (.o) into a single binary program file, like an executable or library.
• Includes all the .o object files that make up the user program.
• Considers all the referenced system libraries.

Linker Libraries

• Static libraries (.a / .lib): inserted in the executable file.
• Dynamic libraries (.so / .dll): linked in at run time.

How Linking Works

• Object files have tables of external references (e.g., call printf).
• Reads all libraries until matching external definition found (e.g., code for printf() in stdio.h).
• Libraries are linked differently depending on the format.
• Static Linking:
  • pulls definitions (function code, global variables) into the program, fixes refs to point to their locations.
• Dynamic Linking:
  • makes a note to note which library file to get the def at runtime.

Linking and Paths

• The linker automatically links standard C libraries, excluding the math library.
• Other required libraries need to be explicitly passed to the linker with the -l option.
• To link the C math library, add the -lm option to the compiler.
• Discussed in a later lecture is the convention on library naming.

Linking Path Info

• The linker needs to know the disk location of the libraries, and by default looks in certain system directories.

• For example /usr/lib, /usr/local/lib.

• It's important to note that the linker does not look in the current directory.

• If both myCode.c and the someLibrary are in the same directory, the compiler will throw an error /usr/bin/ld: cannot find -IsomeLibrary: No such file or directory

• To give the linker additional locations use the -L flag.

• For example gcc myCode.c -L/path/to/a/library -lsomeLibrary

• In this case use: gcc myCode.c -L. -lsomeLibrary

Preprocessor and Linker paths

• -I: provides paths for the preprocessor.
• Locations of header files for #include.
• -L: provides paths to the linker for library locations.
• -l: provides names of libraries for the linker to link with.

Why gcc Is Involved

• GCC acts as a front end for {cpp, gcc, ld}.
• To get these tools, you keep executing "gcc".
• GCC is calling them for you: gcc is not cpp or ld.
• gcc knows where all standard libraries are installed, and beefs up *FLAGS for you.

Loader

• Examined steps concerned with creating binary files.
• Next is looking at what happens with that binary when executed.
• Program tells OS to execute a program file.
• OS creates a fresh process.
• Segments of the program file are copied to different areas of the virtual memory for the process.
• Program instructions ("text" segment)
• Static data ("data" segment)
• OS creates a new stack and an empty heap.
• Then, OS transfers control to the first instruction of the program.

Loader and Dynamic Libraries

• ld.so will load dynamic linked libraries when a program starts.
• References (calls) will be fixed on demand.
• Because most of libraries will not referenced.
• Some programs use dlopen to load a Shared Object plugin at runtime.
• OS pauses execution while loader grabs the object, links into code, continue.

Loader Paths

• To see dependencies on Linux, use ldd {file}.
• For example, ldd a.out.
• The loader has to know where to find shared runtime libraries.
• To see what directories the loader knows, check /etc/ld.so.conf.d.

Loader Directory Paths

• By default, the current directory is not included, and it's not checked.
• Fix this with the environment variable, LD_LIBRARY_PATH:
  • export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
• The statement should be added to the end of .bashrc to avoid retyping.
• It facilitates loading the List API library and linking the A1 parser library.

Compiling list library

• The sample code for list library consists of three files:
  • LinkedListAPI.c: Library function implementations.
  • LinkedListAPI.h: Library headers (function prototypes, etc.).
  • StructListDemo.c: Demo executable with function main().

To Successfully Run an Example

• It's neccessary to Compile the library

• Then compile demo, which requires

  • the location of library headers
  • the location of the linked library file
  • the library path
  • the library binary file name

• Libraries compiled using Makefile makes a binary file called liblist.so

• When linking a listed library, one refers to it as a list.

StructListDemo example

• When compiling the executable demo file with gcc StructListDemo.c, you encounter errors.

/usr/bin/ld: /tmp/ccUliKAO.o: in function `main':
StructListDemo.c:(.text+0x1f4): undefined reference to
`initializeList'
/usr/bin/ld: StructListDemo.c:(.text+0x2d4): undefined reference to
`insertBack'
...

• The C compiler toolchain component that generates this error is the linker.
• Solution: tell the library to link and where it is.

To Correctly Create Example

• gcc StructListDemo.c -L. -llist
• -L. tells the linker to look in current directory, additional to global path.
• -llist tells the linker to link with the listed library.
• This library is called liblist.so.
• After creating example. if run, the code throws an open shared object error.

./StructListDemo: error while loading shared libraries: liblist.so:
cannot open shared object file: No such file or directory

• The loader is the cause of this error.
• This is fixed by telling it to look in the same directory.

This quiz explores software development toolchains, their importance for developers, and specific tools used in CIS*2750. It covers dynamic linking with ld.so, runtime loading with dlopen, and listing shared library dependencies.