Resolving .so Library File Errors in Arch Linux

status
Published
date
Jun 27, 2020
featured_image
slug
resolving-so-library-file-errors-in-archlinux
tags
summary
Sometimes when I want to install a new package on my arch, pacman says that the package conflicts with another package or a package required by another package.
type
Post
Sometimes when I want to install a new package on the system, pacman says that this package conflicts with another package or a package required by another package, and I need to delete something. Occasionally, one can unintentionally install unnecessary packages, making these conflicts inevitable.
But sometimes we encounter an error like the one below when we try to run these packages.
Here, I tried to run the libreoffice package, but it tells me that the shared object libboost_iostreams.so.1.69.0 cannot be found. Shared objects are files with the .so extension and are essentially output files of C/C++. While files with the .a extension are static libraries, those with the .so extension are dynamically linked objects. This means that after a change in the program, .a files need to be recompiled, but there is no such requirement for .so files.
💡
For a more detailed answer: see here.
So why is this? The reason is simple. We can actually think of these libraries as similar to the .dll files in Windows. Many software applications need these libraries, so it is essential for these libraries to be dynamically shared and complete. However, sometimes we may encounter a problem like the one above.

Solution

If we look at the error, we can see the numbers 1.69.0 at the end of the file name. These numbers represent versioning for .so files, and this versioned file is just a link file for libboost_iostreams.so.
To solve the error here, all we need to do is find the source file and create a link file with the file name mentioned in the error.
These files are primarily found under the /usr/lib directory, so it is most logical to search for the source file in this directory. Once the file is found, we can create the link using the ln command and the -s parameter by specifying the source file. The most important thing to pay attention to here is to use an absolute path for the file path. Meaning we should provide the path starting from the root directory. Because when linking files, the absolute path value is not calculated for the given path.
When we run the package again, the error will likely be gone, but if you encounter a similar error, you can repeat the above process to recreate the missing link file.

Another possibility

But there is one more possibility. In this case, your package may give an undefined symbol error for the relevant library file.
In this case, the library file might be an older version, or while installing a package, this library file might have been needed, and the package might have installed a different version of this library file. Here you need to do two things: reinstall the package of the library file or reinstall the package itself.
This error was given by the libreoffice package. I uninstalled and reinstalled LibreOffice, but I continued to encounter the same error. So what I needed to do was reinstall the library. I searched for the library name with the pacman -Ss command.
In the results that came up, I saw and installed the harfbuzz-icu library package.
💡
The pacman -Ss command searches on AUR servers, The pacman -Qs command searches locally installed packages.
After this installation process, the error disappeared when I ran LibreOffice.

But the most important thing I learned from this error was that I need to do system updates from time to time. Maybe because I am someone who doesn't like changes, I was resisting updates, but I saw that things on the system broke for no reason when I didn't, so now I will do the necessary updates and upgrades weekly.
:wq
 

© Samet 2017 - 2024