On Linux systems, you can see which dynamic libraries are loaded into a process by running cat /proc/pid/maps where pid is the relevant process ID.
About your second question: If the libraries are statically linked to libcurl then they cannot use the wrong library version: the linking is static.
If the linking is dynamic then only one libcurl can be loaded. However libcurl seems to be relatively API/ABI stable so this usually wouldn't be a problem.
context: I have a python program which relies on multiple libraries implemented in C++, exposed via pybinder.
My impression is: when python import xxx, it loads shared libraries (.so) into virtual memory. This is something I remember I read from book or webpage but cannot find it now.
I want to know how I can verify it in Linux? I tried to strace with event open, the only shared libraries opened are something like py/__init__.so (all python internal libraries), which doesn't look correct to me.
In the code base, I have multiple libcurl with multiple versions, all of them are introduced by 3-rd parties libraries. I want to know if I have a way to enforce when running python applications, they don't intervene?
For example: python program A relies on C++ shared library B and C.
B relies on libcurl (V1), statically linked.
C also relies on libcurl (V2), also statically linked.
Bad things could happen if B invokes libcurl (V2), since there might be conflict.
How python loads C++ shared library