Executables (binaries) are typically built as in compiled and linked. The linking combines object files into executable with calls to external libraries – shared objects.
When program is run, dynamic linker connects the binary to the shared objects that the system has. The system where you run the program may not be the same as the system where the program was built; the libraries have to be binary compatible for the run to succeed.
The error is not directly from that though. When the RPM package was built, it got also metadata about (some) libraries (e.g. libboost_program_options.so) that it requires. This way package manager can already tell what is needed. (The error messages from dynamic linker can be more cryptic.)
There is a “plan B”:
- Get the src.rpm source package from which the
MariaDB-server-11.4.7-1.el9.x86_64package has been built from - Build (with
mock) the binary packages for el10 - Install the packages
This can be a rabbit hole as the build may require other packages that el10 does not have. Furthermore, the requirement for specific version of libboost_program_options could be stated in the spec – the build instructions within the source package – and then the build cannot use the available Boost version (1.83.0-5) automagically.