Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,8 @@ - +

Prev	Chapter 7. - Building Berkeley DB for UNIX/POSIX -	Chapter 7. Building Berkeley DB for UNIX/POSIX +	Next

@@ -38,87 +37,125 @@

Warning: the following information is intended to be generic and -is likely to be correct for most UNIX systems. Unfortunately, dynamic -shared libraries are not standard between UNIX systems, so there may be -information here that is not correct for your system. If you have -problems, consult your compiler and linker manual pages, or your system -administrator.

The Berkeley DB dynamic shared libraries are created with the name -libdb-major.minor.so, where major is -the major version number and minor is the minor version number. -Other shared libraries are created if Java and Tcl support are enabled: -specifically, libdb_java-major.minor.so -and libdb_tcl-major.minor.so.

On most UNIX systems, when any shared library is created, the linker -stamps it with a "SONAME". In the case of Berkeley DB, the SONAME -is libdb-major.minor.so. It is important to -realize that applications linked against a shared library remember the -SONAMEs of the libraries they use and not the underlying names in the -filesystem.

When the Berkeley DB shared library is installed, links are -created in the install lib directory so that -libdb-major.minor.so, -libdb-major.so, and libdb.so all refer to the -same library. This library will have an SONAME of -libdb-major.minor.so.

Any previous versions of the Berkeley DB libraries that are -present in the install directory (such as libdb-2.7.so or -libdb-2.so) are left unchanged. (Removing or moving old shared -libraries is one drastic way to identify applications that have been -linked against those vintage releases.)

Once you have installed the Berkeley DB libraries, unless they are -installed in a directory where the linker normally looks for shared -libraries, you will need to specify the installation directory as part -of compiling and linking against Berkeley DB. Consult your system -manuals or system administrator for ways to specify a shared library -directory when compiling and linking applications with the -Berkeley DB libraries. Many systems support environment variables -(for example, LD_LIBRARY_PATH or LD_RUN_PATH), or system configuration -files (for example, /etc/ld.so.conf) for this purpose.

Warning: some UNIX installations may have an already existing -/usr/lib/libdb.so, and this library may be an incompatible -version of Berkeley DB.

We recommend that applications link against libdb.so (for example, -using -ldb). Even though the linker uses the file named -libdb.so, the executable file for the application remembers the -library's SONAME (libdb-major.minor.so). This -has the effect of marking the applications with the versions they need -at link time. Because applications locate their needed SONAMEs when -they are executed, all previously linked applications will continue to -run using the library they were linked with, even when a new version of -Berkeley DB is installed and the file libdb.so -is replaced with a new version.

Applications that know they are using features specific to a particular -Berkeley DB release can be linked to that release. For example, an -application wanting to link to Berkeley DB major release "3" can link -using -ldb-3, and applications that know about a particular -minor release number can specify both major and minor release numbers; -for example, -ldb-3.5.

If you want to link with Berkeley DB before performing library -installation, the "make" command will have created a shared library -object in the .libs subdirectory of the build directory, such -as build_unix/.libs/libdb-major.minor.so. If you want -to link a file against this library, with, for example, a major number -of "3" and a minor number of "5", you should be able to do something -like the following:

+ Warning: the following + information is intended to be generic and is likely to be + correct for most UNIX systems. Unfortunately, dynamic shared + libraries are not standard between UNIX systems, so there may + be information here that is not correct for your system. If + you have problems, consult your compiler and linker manual + pages, or your system administrator. +

+ The Berkeley DB dynamic shared libraries are created with + the name libdb-major.minor. + so, where major is the major version number and + minor is the minor + version number. Other shared libraries are created if Java and + Tcl support are enabled: specifically, libdb_java-major.minor.so + and libdb_tcl-major.minor.so. +

+ On most UNIX systems, when any shared library is created, + the linker stamps it with a "SONAME". In the case of Berkeley + DB, the SONAME is libdb-major.minor.so. + It is important to realize that applications linked against a shared + library remember the SONAMEs of the libraries they use and not the + underlying names in the filesystem. +

+ When the Berkeley DB shared library is installed, links are + created in the install lib directory so that libdb-major.minor.so, + libdb-major.so, and libdb.so all refer to the same + library. This library will have an SONAME of libdb-major.minor.so. +

+ Any previous versions of the Berkeley DB libraries that are + present in the install directory (such as libdb-2.7.so or + libdb-2.so) are left unchanged. (Removing or moving old shared + libraries is one drastic way to identify applications that + have been linked against those vintage releases.) +

+ Once you have installed the Berkeley DB libraries, unless + they are installed in a directory where the linker normally + looks for shared libraries, you will need to specify the + installation directory as part of compiling and linking + against Berkeley DB. Consult your system manuals or system + administrator for ways to specify a shared library directory + when compiling and linking applications with the Berkeley DB + libraries. Many systems support environment variables (for + example, LD_LIBRARY_PATH or LD_RUN_PATH), or system + configuration files (for example, /etc/ld.so.conf) for this + purpose. +

+ Warning: some UNIX + installations may have an already existing + /usr/lib/libdb.so, and this library + may be an incompatible version of Berkeley DB. +

+ We recommend that applications link against libdb.so (for + example, using -ldb). Even though the linker uses the file + named libdb.so, the executable file for the application + remembers the library's SONAME + (libdb-major.minor.so). + This has the effect of marking the applications with the versions they + need at link time. Because applications locate their needed SONAMEs when they are + executed, all previously linked applications will continue to + run using the library they were linked with, even when a new + version of Berkeley DB is installed and the file + libdb.so is replaced with a new + version. +

+ Applications that know they are using features specific to + a particular Berkeley DB release can be linked to that + release. For example, an application wanting to link to + Berkeley DB major release "3" can link using -ldb-3, and + applications that know about a particular minor release number + can specify both major and minor release numbers; for example, + -ldb-3.5. +

+ If you want to link with Berkeley DB before performing + library installation, the "make" command will have created a + shared library object in the .libs + subdirectory of the build directory, such as + build_unix/.libs/libdb-major.minor.so. + If you want to link a file against this library, with, for + example, a major number of "3" and a minor number of "5", you + should be able to do something like the following: +

where BUILD_DIRECTORY is the full directory path to the directory -where you built Berkeley DB.

The libtool program (which is configured in the build directory) can be -used to set the shared library path and run a program. For example, -the following runs the gdb debugger on the db_dump utility after setting -the appropriate paths:

+ where BUILD_DIRECTORY is + the full directory path to the directory where you built + Berkeley DB. +

+ The libtool program (which is configured in the build + directory) can be used to set the shared library path and run + a program. For example, the following runs the gdb debugger on + the db_dump utility after setting the appropriate paths: +

Libtool may not know what to do with arbitrary commands (it is hardwired -to recognize "gdb" and some other commands). If it complains the mode -argument will usually resolve the problem:

+ Libtool may not know what to do with arbitrary commands (it + is hardwired to recognize "gdb" and some other commands). If + it complains the mode argument will usually resolve the + problem: +

On most systems, using libtool in this way is exactly equivalent to -setting the LD_LIBRARY_PATH environment variable and then executing the -program. On other systems, using libtool has the virtue of knowing about -any other details on systems that don't behave in this typical way.

+ On most systems, using libtool in this way is exactly + equivalent to setting the LD_LIBRARY_PATH environment variable + and then executing the program. On other systems, using + libtool has the virtue of knowing about any other details on + systems that don't behave in this typical way. +

@@ -131,11 +168,13 @@ any other details on systems that don't behave in this typical way.

Next - Installing Berkeley DB + Installing Berkeley + DB Home - Running the test suite under UNIX + Running the test suite under + UNIX