Difference between revisions of "SPO600 Code Building Lab"
Chris Tyler (talk | contribs) (→Build an open source software package) |
Chris Tyler (talk | contribs) (→Build and test glibc) |
||
Line 27: | Line 27: | ||
# Obtain the source code for glibc via git using the instructions at https://sourceware.org/glibc/wiki/Testing/Builds | # Obtain the source code for glibc via git using the instructions at https://sourceware.org/glibc/wiki/Testing/Builds | ||
# Build and test your version of glibc. '''Do Not''' install it into the system directories or you may destroy the existing Linux installation! | # Build and test your version of glibc. '''Do Not''' install it into the system directories or you may destroy the existing Linux installation! | ||
− | # Blog about your results. Provide convincing proof that you can test the specific version of glibc which you | + | # Blog about your results. Provide convincing proof that you can test the specific version of glibc which you built -- for example, by intentionally creating a bug, and proving that that bug exists in the version you're testing. Explain override and multiarch mechanisms (don't just google "override" and "multiarch", because these have different meanings in different contexts). |
Revision as of 10:44, 11 September 2018
Contents
Lab 2
Prerequisites
You must have a working accounts on a Linux system (such as the SPO600 Servers or your own system).
Tasks
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-devel
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 build (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
- Find and build the source code for the latest released version of the GNU Standard C Library (glibc). 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 a function: a basic version, written in C, and one or more versions optimized for the target architecture, in C or assembler (.s or .S files). Learn the mechanisms used to override one implementation with another. Read up on the multiarch system.
- Blog about the process, your results, your observations, and what you learned.
- Obtain the source code for glibc via git using the instructions at https://sourceware.org/glibc/wiki/Testing/Builds
- Build and test your version of glibc. Do Not install it into the system directories or you may destroy the existing Linux installation!
- Blog about your results. Provide convincing proof that you can test the specific version of glibc which you built -- for example, by intentionally creating a bug, and proving that that bug exists in the version you're testing. Explain override and multiarch mechanisms (don't just google "override" and "multiarch", because these have different meanings in different contexts).