(Lab4) GCC Build Lab

The purpose of this lab is to become familiar with the process of building large software projects, utilizing tools such as make and automake/autotools. This is useful because we will be working on the GCC compiler for the course project.

AArch64

aarch64-002

You can access this system at the hostname aarch64-002.spo600.cdot.systems; using OpenSSH from the command line, you can use these arguments:

ssh username@aarch64-002.spo600.cdot.systems

Step 1: Obtain the Source Code

Login on aarch64-002:

Ensure Git is installed:

Check out the GCC sources:

Check files:

Step 2: Configure Your Build

I should create a separate build directory (outside the source tree) to compile GCC：
For example, if the source is in ~/git/gcc, you could do something like this:

mkdir ~/gcc-build-001
cd ~/gcc-build-001
~/git/gcc/configure --prefix=$HOME/gcc-test-001

Waiting for configuration to complete.

Step 3: Perform the Build

To efficiently build a project using make, use the -j option to specify concurrent jobs, ideally between (cores + 1) and (cores * 2 + 1), depending on your system's threading and disk speed. Since builds can take from 20 minutes to several hours, it's recommended to use the screen utility for session persistence and the time command to measure build duration. Additionally, redirect both stdout and stderr to a log file using tee for monitoring, as demonstrated in the command:

time make -j 24 |& tee build.log

three hours later.....finally....

Step 4: Install the Build

To install the software into the directory that you configured in step 2, run make install.

Then check in home:

Step 5: Test the Build

You can test the build using make check in the build directory. You can also use the installed build of the compiler by setting your path to include the bin directory within the installation directory as the first directory in your PATH:

PATH=$HOME/gcc-test-001:$PATH

BUT, we can Set PATH to let the system give priority to the newly compiled GCC:

To create a simple C program:

Update the timestamp on the file “passes.cc” (which will be in the gcc subdirectory of the source tree) either by editing the file and saving it, or by using the touch command.

find passes.cc:

update timestamp:

Rebuild the software in your build directory by re-issuing the make command. Because only one source file changed, the build time should be a tiny fraction of the time required for the initial build. Record the build time and any observations you make.

Since I only modified passes.cc (updated the timestamp), I can rerun make in the GCC build directory (gcc-build-001). Since only one file changed, this build should be much faster than the original full build.

Rebuild the software again, with no changes to the source code. This is a “null rebuild”, which will give you an idea of the amount of time it takes make to simply traverse the directory trees and determine that no changes are required. Record the build time and any observations you make.

This null rebuild took only 3 minutes and 34 seconds, much less than the full build of 198 minutes and 15 seconds, indicating that make was efficiently checking file changes without performing actual compilation. The user time (6 minutes and 57 seconds) was longer than the real time, indicating that make was mainly calculating file dependencies on the CPU rather than being limited by I/O reading speed. Throughout the process, make only traversed the directory tree, checked the timestamps of source and target files, and confirmed that all files were up to date, so no compilation was performed.

x86_64

x86_64-001

This x86_64 system is a workstation/server class system (x86-64-v4 architectural level) with 64GiB RAM. It has the hostname x86-001.spo600.cdot.systems. It can be accessed using OpenSSH with these arguments:

ssh username@x86-001.spo600.cdot.systems

I perform the same process on x86_64.


make install:


check gcc:

update the timestamp of the file "passes.cc" and rebuild the software in the gcc-build-001 directory:

This lab helped me better understand the GCC build system, and I found the process of compiling and testing my own version of GCC very interesting and insightful.