These exercises give you practice managing:
- Dynamically and statically linked programs
- Shared object library cache
- Shared object library paths
- Link shared objects
To get the most from the practice exercises in this series, you should have a basic knowledge of Linux and a working Linux system on which you can practice the exercises covered in this article.
Exercise 1. List dynamically linked shared objects
Imagine you are a systems administrator for a Linux file server. You are
working to create a new directory, and suddenly, the popular
mkdir command returns an error. This error
could be the result of a missing dynamically linked library. You've
probably used the mkdir tool numerous times. It
is just one example of a program that depends on external shared objects
to function properly.
- Use the appropriate command to properly identify the
shared libraries
mkdircalls externally.
Exercise 2. Find statically linked executables
You have now found shared libraries dynamically linked to the
mkdir command.
- Locate an executable in the /bin directory that doesn't use external shared libraries.
Exercise 3. Find information about library caching
Linux caches library location information for dynamically linked programs to improve performance.
- Locate the caching directory on your Linux
computer, and use the appropriate command to find a library that
mkdirneeds.
Exercise 4. Set an alternative shared library path
Commonly used Linux executables such as mkdir
typically use a common path that your Linux distribution sets. Suppose the
organization you are working for requires the use of a third-party program
that is dynamically linked to shared libraries not included in a
typical Linux computer's library search path. In such cases, you might
consider creating a separate directory for the libraries. However, the
program needs to locate the libraries when executed. For this task, assume
that the third-party application foo has been provided, but an
older version uses a shared library not installed on your Linux computer.
- Create a directory with the path /opt/foo/lib.
- Create a file in the /opt/foo/lib directory, and name it foo.so.
- Use the
exportcommand to set the library path variable that will enable the application to find foo.so at run time.
Exercise 5. Create a symbolic link to a shared library
Consider the possibility that foo software has been updated and documented to use the latest /lib/libcat.so library in place of foo.so. Even though the new software has backward compatibility to use foo.so, you can experiment using the new library by creating a symbolic link:
- Rename the original foo.so to foo.so.old.
- Create a symbolic link from /lib/libcat.so to /opt/foo/lib/foo.so.
Follow these solution steps to check your work.
- The developerWorks article "Learn Linux,101: Manage shared libraries" (developerWorks, March
2010) describes the commands required to complete these exercises.
- At the LPIC
Program site, find detailed objectives, task lists, and sample
questions for the three levels of the LPI's Linux systems administration
certification. In particular, look at the LPI-101 detailed objectives and the sample questions.
- Review the entire LPI exam
prep series on developerWorks to learn Linux fundamentals and
prepare for systems administrator certification based on LPI exam
objectives prior to April 2009.
-
Exam Preparation Resources for Revised LPIC Exams provides a list
of other certification training resources that LPI maintains.

Tracy Bost is a seasoned software developer and systems engineer. He is also a lecturer and trainer for the Linux operating system. Tracy has been certified as both a Red Hat Certified Engineer (RHCE) and a Microsoft Certified Systems Engineer (MCSE), along with being an active member of the Linux Foundation. He has worked in several industries, including mortgage, real estate, and the nonprofit sector.



