Ok. How would you add you directory to the search path?
You would need to add it to LD_LIBRARY_PATH to load the library.
I don't need to add it to LD_LIBRARY_PATH because I forcibly loading them from program folder with
InitSSLInterface(filepath + 'libssl' + ext, filepath + 'libcrypto' + ext);
Make sure not to do that in .bashrc or somewhere else global because then every program is going to load your older openssl while some of those might need OpenSSL 3.
No global, nor touching anything outside program folder
It might be better and safer to use the .a option and link the openssl version statically into your program.
I have already said this above, that it would be ideal to encapsulate all dependencies inside the binary by static linking.
This would simultaneously reduce both the volume of distribution (since static linking would take only the necessary parts, and not the entire volume of the library) so is the number of distribution units, reducing them to one (in the simplest case). And we have not yet touched on reducing the size of the binary by packers.
P.S. further research led to the finding of a regular way to include the path of the initial search for shared libraries
inside executable file, by passing to the linker
-rpath or
-R-rpath {path to lib(s) folder}
for example for folder `lib` in
current folder
or for folder `lib` in program
executable binary's folder (relative, in
most cases we must use this method)
or for
absolute path to folder `lib' (remember, when putting your shared libs to places where other programs can search of such libs, it can affect problems, we discussed above)
In order to pass this to the linker, it is necessary to set the appropriate parameter in the project properties in Lazarus (see attachment)
In fpc, accordingly, you just need to pass the -k key with these parameters to the compiler
At the output, we get in the executable file with readelf -d
(RUNPATH) Library runpath: [lib]
or
(RUNPATH) Library runpath: [$ORIGIN/lib]
Thus, in my opinion, this is an acceptable way to distribute the program together with shared libraries, without affecting the system environment and without affecting other programs.
So if we want to distribute .so files in program folder, then we must set rpath just to $ORIGIN
In case that for some reason the libraries in the specified folder are not found, then the search for shared libraries will follow the usual route.
As for the versions of OpenSSL itself, as it was said, support for the 1.x branch ended on September 11, 2023, the 3.0.x branch is experiencing problems with speed, although it has a longer lifetime. Therefore, in my opinion, a reasonable choice would be to use the 3.1.x branch (currently the latest version 3.1.2). The most optimal would be to compile libssl.so.3 and libcrypto.so.3 from the library source codes yourself and rely on them when developing and testing your program.
I am waiting for competent comments and opinions.
Recent
