The title is not very descriptive. Let's see if I can explain myself.
I have a c++/Qt application that makes use of python modules via the Python/C API. When compiling, I do it using the version that I have installed on my computer. In this case (*.pro file):
unix {
INCLUDEPATH += /usr/include/python3.6m
LIBS += -L /usr/local/lib/python3.6 -lpython3.6m
DEPENDPATH += /usr/include/python3.6m
}
win32 {
INCLUDEPATH += C:\Python\Python37\include
LIBS += -L C:\Python\Python37\libs -lpython37
DEPENDPATH += C:\Python\Python37\include
}
Then I have a pyrun.h
and a pyrun.cpp
where are the own functions to read and execute modules. In the *.cpp I have:
#include <Python.h>
#include "./pyrun.h"
I have the doubt because being compiled with those versions of libraries in particular, when trying to run the application on another computer it asks for exactly those versions, even if it has higher versions. So is that normal behavior? Can it be made to support higher versions?
Thank you
edit:
I'm trying to add data to the question, which is not very well formulated.
If I make ldd
my app, I'll get the libraries it depends on:
linux-vdso.so.1 (0x00007ffcf0bbc000)
libpython3.6m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0 (0x00007f657385f000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f6573644000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f6573433000)
libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f65731f4000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f6572fa7000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f6572da5000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6572b7d000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6572845000)
...
So if for example it was updated libxcb-glx.so.0
, the program would not complain. However, having a version of python higher than the one used for the compilation (in my case 3.6 libpython3.6m.so.1.0
) causes the program to claim the exact version.
Dangers of version change
This problem occurs when linking with dynamic libraries.
A dynamic library is nothing more than binary code that has no entry points (the typical function
main
). It is nothing more than a collection of functions (its API) available to programs that make use of this library.When someone removes a new version of a library, it is because that new version has changes with respect to the previous version. These changes could be grouped into:
Thus, changing the version of a library is not a trivial operation, but it does entail risks.
development vs deployment
When you are developing a program you normally make use of a developer version of the library. This version is characterized by:
When you deploy your application you should, as a general rule, include the libraries you depend on in the deployment. If you don't, the program has to find a compatible library on the system
Have you programmed that search somewhere?
Normally you haven't. The consequence is that your program will try to locate the libraries in a series of prefixed paths:
If the program is unable to find the libraries in these paths, it will not be able to run correctly and will end with an error.
the answer is in the comments of @Juanjo.
My mistake was thinking that a higher python library (3.8 vs 3.6 in my case) would somehow just be compatible with an application that uses and links to a lower one.
Only higher versions that use the same number can do that (obviously, on the other hand).