I compiled boost iostreams with zlib and bzip2 support according to this tutorial https://www.boost.org/doc/libs/1_49_0/libs/iostreams/doc/installation.html :

I changed working directory to ~/cpp_libs/boost_code/boost_1_55_0/libs/iostreams/build/ and typed:

bjam -s ZLIB_SOURCE=~/cpp_libs/zlib_code/zlib-1.2.11 -s BZIP2_Source=~/cpp_libs/bzip2_code/bzip2

It has generated libs:

~/cpp_libs/boost_code/boost_1_55_0/bin.v2/standalone/zlib/gcc-9/debug/libboost_zlib.so.1.55.0 ~/cpp_libs/boost_code/boost_1_55_0/bin.v2/libs/iostreams/build/bzip2/gcc-9/debug/libboost_bzip2.so.1.55.0 ~/cpp_libs/boost_code/boost_1_55_0/bin.v2/libs/iostreams/build/gcc-9/debug/libboost_iostreams.so.1.55.0

However now I don't know how to link to this libraries, because it has version extensions in their names.

If I rename libraries:

libboost_zlib.so.1.55.0 to libboost_zlib.so

libboost_bzip2.so.1.55.0 to libboost_bzip2.so

libboost_iostreams.so.1.55.0 to libboost_iostreams.so

I can link them with command "-lboost_zlib -lboost_iostreams -lboost_bzip2", however when I run the compiled program it prints:

./main: error while loading shared libraries: libboost_iostreams.so.1.55.0: connot open shared object file: No such file or directory.

So how to link to this libraries without renaming?

I am using g (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

CodePudding user response：

Here's the usual workflow that's used to build and install shared libraries on Linux. The exact details vary widely between different libraries and all packages but they all follow the same general framework:

1. The software package builds an installation image, placing the libraries as <libdir>/<name>.<version>, where <libdir> is the system library installation directory, like /usr/lib or /usr/lib64, or perhaps /lib or /lib64, or there could be several variations.

2. <name> is the base name of the shared library, such as libboost_zlib.so in your case, and is the epoch/version/release of the shared library, or 1.55.0.

3. As part of building the shared library, the library's name, epoch and version is recorded in the shared library itself, in this case it would be libboost_zlib.so.1.55.

4. At this point the actual details start to diverge between different Linux distributions. In some this step occurs as part of creating an installation package. On other Linux distributions this happens when the package actually gets installed, but at some point the ldconfig tool gets executed.

5. ldconfig goes through and creates all the needed symbolic links for all shared libraries in standard system shared library directories. In this case it would create the following symbolic links:

libboost_zlib.so => libboost_zlib.so.1.55
libboost_zlib.so.1.55 => libboost_zlib.so.55.0

This ends up being the final state of the installed shared library. When you build the software with the shared library the -lboost_zlib flag to the linker results in the linker attempting to link the executable with libboost_zlib.so. This reads the libboost_zlib.so.1.55 encoded in the actual shared library (see step 3 above), and the linked executable is marked as requiring libboost_zlib.so.1.55 to be loaded when it gets executed.

When the linked executable gets executed, an attempt is made to open libboost_zlib.so.1.55, which uses that symbolic link to find the actual shared library.

I changed working directory to ~/cpp_libs/boost_code/boost_1_55_0/libs/iostreams/build/ and typed:

bjam -s ZLIB_SOURCE=~/cpp_libs/zlib_code/zlib-1.2.11 ...

You used a non-standard process for compiling and building these shared libraries. It's now up to you to fill in the missing steps, do all the heavy lifting, and create the missing symbolic links. Note that you can commandeer ldconfig into doing your bidding, by pointing it at your installation directory, see its manual page for more information.

You will also need to deal with the fact that the shared libraries ended up getting installed in a non-standard directory that the runtime loader will not search by default. You will need to use additional compilation options (namely -rpath) when linking code with the shared libraries in that directory, but that's going to be a separate issue.