• Choose a category
• All
• Classic-Fiction

By Root 1115 0

either the .a or the .so file is used for linking, and the compiler looks in /lib and /usr/lib (as well as a variety of other places) by default. If you have your own libraries, you can keep these files anywhere, and control where the linker looks with the -L option to the compiler. See "More Fun with Libraries" in Chapter 21 for details.

The shared library image, .so.version, is kept in /lib for most system-wide libraries. Shared library images can be found in any of the directories that ld.so searches at runtime; these include /lib, /usr/lib, and the files listed in ld.so.conf. See the ld.so manual page for details.

If you look in /lib, you'll see a collection of files such as the following:

lrwxrwxrwx 1 root root 17 Jul 11 06:45 /lib/libncurses.so.5 \

-> libncurses.so.5.4

-rwxr-xr-x 1 root root 319472 Jul 11 06:45 /lib/libncurses.so.5.4

lrwxrwxrwx 1 root root 13 Jul 11 06:45 libz.so.1 -> libz.so.1.2.2

-rwxr-xr-x 1 root root 62606 Jul 11 06:45 libz.so.1.2.2

Here, we see the shared library images for two libraries -- libncurses and libz. Note that each image has a symbolic link to it, named .so., where is the major version number of the library. The minor number is omitted because ld.so searches for a library only by its major version number. When ld.so sees a program that has been compiled with the stubs for Version 5.4 of libncurses, it looks for a file called libncurses.so.5 in its search path. Here, /lib/libncurses.so.5 is a symbolic link to /lib/libncurses.so.5.4, the actual version of the library we have installed.

When you upgrade a library, you must replace the .a and .so. files corresponding to the library. Replacing the .a file is easy: just copy over it with the new versions. However, you must use some caution when replacing the shared library image, .so.; many of the text-based programs on the system depend on shared library images, so you can't simply delete them or rename them. To put this another way, the symbolic link .so. must always point to a valid library image. To accomplish this, first copy the new image file to /lib, and then change the symbolic link to point to the new file in one step, using ln -sf. This is demonstrated in the following example.

Let's say you're upgrading from Version 5.4 of the libncurses library to Version 5.5. You should have the files libncurses.a and libncurses.so.5.5. First, copy the .a file to the appropriate location, overwriting the old version:

rutabaga# cp libncurses.a /usr/lib

Now, copy the new image file to /lib (or wherever the library image should be):

rutabaga# cp libncurses.so.5.5 /lib

Now, if you use the command ls -l /lib/libncurses, you should see something like the following:

lrwxrwxrwx 1 root root 17 Dec 10 1999 /lib/libncurses.so.5 ->

libncurses.so.5.4

-rwxr-xr-x 1 root root 319472 May 11 2001 /lib/libncurses.so.5.4

-rwxr-xr-x 1 root root 321042 May 11 2001 /lib/libncurses.so.5.5

To update the symbolic link to point to the new library, use the command:

rutabaga# ln -sf /lib/libncurses.so.5.5 /lib/libncurses.so.5

This gives you:

lrwxrwxrwx 1 root root 14 Oct 23 13:25 libncurses.so.5 ->\

/lib/libncurses.so.5.4

-rwxr-xr-x 1 root root 623620 Oct 23 13:24 libncurses.so.5.4

-rwxr-xr-x 1 root root 720310 Nov 16 11:02 libncurses.so.5.5

Now you can safely remove the old image file, libncurses.so.5.4. You must use ln -sf to replace the symbolic link in one step, especially when updating crucial libraries, such as libc. If you were to remove the symbolic link first, and then attempt to use ln -s to add it again, more than likely ln would not be able to execute because the symbolic link is gone, and as far as ld.so is concerned, the libc library can't be found. Once the link is gone, nearly all the programs on your system will be unable to execute. Be very careful when updating shared library images. For libncurses, things are less critical because you will always have command-line programs left to clean up any mess you have made, but if you are used to using ncurses-based