Fakelibs or about how to create Linux applications that are not dependent on the version of libraries installed in the system.
To date, there are a fairly large number of builds of Linux distributions and an even greater number of different versions of these distributions. It often happens that installing an application that is not included in the distribution is a whole adventure. Compiled binaries do not start because were compiled with other versions
libraries and the only way to install the application is to rebuild it from the source. It often happens that these sources drag a bunch of libraries along with them, sometimes it happens that these libraries do not match with their versions already installed, and other previously installed applications do not want to work with new versions of libraries ... Thus, the simple task of installing the required applications takes an abyss of time, and often it becomes an insurmountable barrier for not too stubborn or not enough trained users.
I think it is precisely such difficulties that are one of the main factors hindering the mass distribution of a magnificent operating system, which in all other respects is significantly superior to its analogues.
I must immediately note that this method requires some caution from the programmer in choosing the functions used and, as a result, is not always suitable for everyone. However, in most cases, it is suitable. It is suitable in cases when the programmer uses only those functions whose interface and data structures do not change from version to version of libraries. For example, the interface of the vast majority of functions libc has not changed since the time of Kernighan and Ritchie (i.e., from the eighties of the last century). There has long been a POSIX standard, and over the past 20 to 25 years, all Linux distributions have tried to support it. If your application does not go beyond the scope of this standard, this method is definitely suitable for you. On the other hand, if the application uses libraries that are not found on all Linux distributions or that change significantly from version to version, it is better to link them statically.
The essence of the method.
In order for the application not to depend on the versions of dynamic libraries, it is necessary that the linked libraries do not have version information. How to do it? Of course, you can try to rebuild all the libraries from the source, but this is long and tedious ... Instead, I wrote a simple script that generates a fake library using standard tools. This fake library has only function names and exported variables. No version information.
The script can be downloaded from here:
The libraries thus obtained are used only for building. When building in makefile, you must add the -L/path/to/fakelibs switch before the -l switch for each library used.
mkdir /usr/local/fakelibs ./mkfakelib.pl /usr/lib/i386-linux-gnu/libc.so /usr/local/fakelibs/ ./mkfakelib.pl /usr/lib/i386-linux-gnu/libpthread.so /usr/local/fakelibs/ mkdir /usr/local/fakelibs64 ./mkfakelib64.pl /lib/x86_64-linux-gnu/libc.so.6 /usr/local/fakelibs64/ -c gcc -m32 app.o -o app -dynamic-linker -L/usr/local/fakelibs/ -lpthread -L/usr/local/fakelibs -lc -lc_nonshared gcc -m64 app64.o -o app64 -dynamic-linker -L/usr/local/fakelibs64 -lc -lc_nonsharedApplications collected in this way are easily transferred from one system to another, as a rule, they start and work stably. However, I ran into a small problem occurring in 64-bit Ubuntu 16.04 On this system, the compiled applications also worked completely correctly, except that the "dlopen" function returned error 2 "invalid caller" for any arguments. At the same time, the 32-bit version of the same application on the same system worked fine. So far, I have not found a way to defeat this problem. If you know this method, please write to me or leave a comment on the forum .