I’m not sure whether this is the correct spot for a question like this, but here we go.
Today I updated Tumbleweed to 20200901, which brought me Boost 1.74. Unfortunately, it left some bits and pieces of Boost 1.71 on my system since some applications (e.g. ncmpcpp) depend on it. The problem I now have is that my linker seems to prefer to link against Boost 1.71 - even though the library in question is not present on my system anymore. Here is a curious example:
I have a library, say, liba.so, which links to various Boost components. Here is what ldd shows:
ldd liba.so
linux-vdso.so.1 (0x00007ffe861fd000)
libboost_iostreams.so.1.74.0 => /usr/lib64/libboost_iostreams.so.1.74.0 (0x00007f320f6e3000)
libboost_log.so.1.74.0 => /usr/lib64/libboost_log.so.1.74.0 (0x00007f320f63f000)
libboost_filesystem.so.1.74.0 => /usr/lib64/libboost_filesystem.so.1.74.0 (0x00007f320f622000)
libboost_program_options.so.1.74.0 => /usr/lib64/libboost_program_options.so.1.74.0 (0x00007f320f5e1000)
libboost_timer.so.1.74.0 => /usr/lib64/libboost_timer.so.1.74.0 (0x00007f320f5d8000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f320f5b6000)
libboost_atomic.so.1.74.0 => /usr/lib64/libboost_atomic.so.1.74.0 (0x00007f320f5ab000)
libboost_regex.so.1.74.0 => /usr/lib64/libboost_regex.so.1.74.0 (0x00007f320f4d7000)
libboost_thread.so.1.74.0 => /usr/lib64/libboost_thread.so.1.74.0 (0x00007f320f4b6000)
libboost_chrono.so.1.74.0 => /usr/lib64/libboost_chrono.so.1.74.0 (0x00007f320f4ac000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f320f2d0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f320f18b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f320f16f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f320efa8000)
libz.so.1 => /lib64/libz.so.1 (0x00007f320ef8e000)
libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f320ef6d000)
librt.so.1 => /lib64/librt.so.1 (0x00007f320ef62000)
/lib64/ld-linux-x86-64.so.2 (0x00007f320f8bd000)
libicui18n.so.67 => /usr/lib64/libicui18n.so.67 (0x00007f320ec53000)
libicuuc.so.67 => /usr/lib64/libicuuc.so.67 (0x00007f320ea69000)
libicudata.so.67 => /usr/lib64/libicudata.so.67 (0x00007f320ea66000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f320ea60000)
So far, so innocent - only Boost 1.74 is used, which is exactly as expected. Now I have an executable, which links against liba. Even though the main program is the most simple “Hello World!” program, the linker now gives me:
ldd main
linux-vdso.so.1 (0x00007fff7f18c000)
liba.so.3 => /home/kyoki/lib/liba.so.3 (0x00007f3015de0000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3015bd8000)
libm.so.6 => /lib64/libm.so.6 (0x00007f3015a93000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3015a79000)
libc.so.6 => /lib64/libc.so.6 (0x00007f30158b2000)
libboost_iostreams.so.1.71.0 => not found
libboost_log.so.1.71.0 => not found
libboost_filesystem.so.1.71.0 => /usr/lib64/libboost_filesystem.so.1.71.0 (0x00007f3015896000)
libboost_program_options.so.1.71.0 => /usr/lib64/libboost_program_options.so.1.71.0 (0x00007f3015846000)
libboost_timer.so.1.71.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3015824000)
libboost_atomic.so.1.71.0 => not found
libboost_date_time.so.1.71.0 => not found
libboost_regex.so.1.71.0 => /usr/lib64/libboost_regex.so.1.71.0 (0x00007f301574a000)
libboost_thread.so.1.71.0 => /usr/lib64/libboost_thread.so.1.71.0 (0x00007f3015723000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3015f96000)
libboost_chrono.so.1.71.0 => not found
libicui18n.so.67 => /usr/lib64/libicui18n.so.67 (0x00007f3015416000)
libicuuc.so.67 => /usr/lib64/libicuuc.so.67 (0x00007f301522a000)
libicudata.so.67 => /usr/lib64/libicudata.so.67 (0x00007f3015227000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3015221000)
Consequently, executing main fails while loading the shared libraries. In other cases, ldd shows that the program (or library) is looking for both version 1.74 and 1.71 of the same Boost library. Any idea, why this is happening? The missing libraries are not available as packages anymore and I’d rather not compile and install Boost 1.71 locally, even though this is possible.
