Difference between revisions of "SPO600 Code Building Lab"
Chris Tyler (talk | contribs) |
Chris Tyler (talk | contribs) |
||
| (12 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Category:SPO600 Labs]]{{Admon/lab|Purpose of this Lab|In this lab, you will do a baseline build of a software package.}} | + | [[Category:SPO600 Labs - Retired]]{{Admon/lab|Purpose of this Lab|In this lab, you will do a baseline build of a software package.}} |
== Lab 2 == | == Lab 2 == | ||
| Line 5: | Line 5: | ||
=== Prerequisites === | === Prerequisites === | ||
| − | You must have a working accounts on a Linux system (such as | + | You must have a working accounts on a Linux system (such as the [[SPO600 Servers]] or [[SPO600 Host Setup|your own system]]). |
=== Tasks === | === Tasks === | ||
| Line 11: | Line 11: | ||
{{Admon/caution|Do not build or install this software as the root user.|Do not build the software as root, and do not install the software into the system directories. Doing so may cause conflicts with other software on the system and/or may leave your system in an unusable state, and may be very difficult to reverse.}} | {{Admon/caution|Do not build or install this software as the root user.|Do not build the software as root, and do not install the software into the system directories. Doing so may cause conflicts with other software on the system and/or may leave your system in an unusable state, and may be very difficult to reverse.}} | ||
| − | # Select | + | ==== Build an open source software package ==== |
| − | # Download the source code for the software. | + | # Select an open source software package from the [http://www.gnu.org/software/software.html Free Software Foundation's GNU Project] or another open source project. |
| − | # Build the software. You may need to install build dependencies (e.g., compilers, tools, and libraries); you can do this (and only this) as the root user. | + | # Download the source code for the software. (Do not install with dnf/yum!) |
| − | # | + | # Build the software. You may need to install build dependencies (e.g., compilers, tools, and libraries); you can do this (and only this) as the root user using dnf/yum. For example, if you need <code>cmake</code>, run the command <code>sudo dnf install cmake</code>, and if you need the library <code>ncurses</code>, then run the command <code>sudo dnf install ncurses-devel</code> (the <code>-devel</code> specification will cause dnf to install the header files as well as the library, so that you can build software that uses that library). |
| − | # | + | # Without installing the new software that you just built (because that could override the existing and working version), test that it works. |
| − | # Blog about the process, your results, your observations, and what you learned. | + | # Blog your results. Explain (don't just document) each of the steps required to build your software and any dependencies you need to install. Include your reflections on the process. |
| + | |||
| + | ==== Build and test glibc ==== | ||
| + | {{Admon/tip|Read the glibc Instructions|The glibc software and build system are complex, since this is core library which underlies most of the software on the system. [https://www.gnu.org/software/libc/ Read the documentation carefully.]}} | ||
| + | |||
| + | # Find and build the source code for the latest released version of the GNU Standard C Library (glibc) -- see the instructions at https://sourceware.org/glibc/wiki/Testing/Builds. Note that glibc uses two parallel directory trees: one which contains the source code, and one which contains configuration and the output of the build system. You can safely delete all of the contents of the build directory and rebuild at any time. | ||
| + | # Test the library which you have built (Critical: do this without installing it on your system and overwriting your existing glibc installation!). Prove that your version of the library is used in your tests by introducing a change in behaviour (for example, a small bug). | ||
| + | # There are multiple implementations of some of the glibc functions: a basic version, written in C, and one or more versions optimized for various target architectures, in C or assembler (.s or .S files). Learn the mechanisms used to override one implementation with another -- read up on the override and multiarch system (don't just google "override" and "multiarch", because these have different meanings in different contexts! Research how those terms specifically apply to glibc). | ||
| + | # Blog about the process, your results, your observations, and what you learned. Explain what glibc is and why it is important. Provide convincing proof that the version you tested is the specific version of glibc which you built. Explain the override and multiarch mechanisms. | ||
Latest revision as of 08:44, 1 November 2023
Purpose of this Lab
In this lab, you will do a baseline build of a software package.
In this lab, you will do a baseline build of a software package.
Contents
Lab 2
Prerequisites
You must have a working accounts on a Linux system (such as the SPO600 Servers or your own system).
Tasks
.png){kind=small}
Do not build or install this software as the root user.
Do not build the software as root, and do not install the software into the system directories. Doing so may cause conflicts with other software on the system and/or may leave your system in an unusable state, and may be very difficult to reverse.
Do not build the software as root, and do not install the software into the system directories. Doing so may cause conflicts with other software on the system and/or may leave your system in an unusable state, and may be very difficult to reverse.
Build an open source software package
- Select an open source software package from the Free Software Foundation's GNU Project or another open source project.
- Download the source code for the software. (Do not install with dnf/yum!)
- Build the software. You may need to install build dependencies (e.g., compilers, tools, and libraries); you can do this (and only this) as the root user using dnf/yum. For example, if you need
cmake, run the commandsudo dnf install cmake, and if you need the libraryncurses, then run the commandsudo dnf install ncurses-devel(the-develspecification will cause dnf to install the header files as well as the library, so that you can build software that uses that library). - Without installing the new software that you just built (because that could override the existing and working version), test that it works.
- Blog your results. Explain (don't just document) each of the steps required to build your software and any dependencies you need to install. Include your reflections on the process.
Build and test glibc
Read the glibc Instructions
The glibc software and build system are complex, since this is core library which underlies most of the software on the system. Read the documentation carefully.
The glibc software and build system are complex, since this is core library which underlies most of the software on the system. Read the documentation carefully.
- Find and build the source code for the latest released version of the GNU Standard C Library (glibc) -- see the instructions at https://sourceware.org/glibc/wiki/Testing/Builds. Note that glibc uses two parallel directory trees: one which contains the source code, and one which contains configuration and the output of the build system. You can safely delete all of the contents of the build directory and rebuild at any time.
- Test the library which you have built (Critical: do this without installing it on your system and overwriting your existing glibc installation!). Prove that your version of the library is used in your tests by introducing a change in behaviour (for example, a small bug).
- There are multiple implementations of some of the glibc functions: a basic version, written in C, and one or more versions optimized for various target architectures, in C or assembler (.s or .S files). Learn the mechanisms used to override one implementation with another -- read up on the override and multiarch system (don't just google "override" and "multiarch", because these have different meanings in different contexts! Research how those terms specifically apply to glibc).
- Blog about the process, your results, your observations, and what you learned. Explain what glibc is and why it is important. Provide convincing proof that the version you tested is the specific version of glibc which you built. Explain the override and multiarch mechanisms.
