Python如何加载C＆＃x2B;＆＃x2B;共享库
上下文：我有一个Python程序，该程序依赖于通过Pybinder暴露的C ++中实现的多个库。 我的印象是：当Python 导入XXX时，它将共享库（.so）加载到虚拟内存中。这是我记得我从书或网页中读到的东西，但现在找不到。
我想知道如何在Linux中验证它？我尝试使用event open ，唯一打开的共享库是py/__ init __。对我来说看起来不正确。
在代码库中，我有多个具有多个版本的Libcurl，所有版本均由3-RD PAIRNE库介绍。我想知道我在运行Python应用程序时是否有办法执行，它们不干预？
例如：Python程序A依赖于C ++共享库B和C。 B依赖于Libcurl（V1），静态链接。 C还依赖于libcurl（V2），也静态链接。 如果B调用Libcurl（V2），可能会发生坏事，因为可能发生冲突。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在Linux系统上，您可以通过运行
cat/proc/pid/mapspid> pid 是相关的过程ID，从而将哪些动态库加载到过程中。关于您的第二个问题：如果库在静态上链接到libcurl，那么他们将无法使用错误的库版本：链接是静态的。
如果链接是动态的，则只能加载一个
libcurl。但是，libcurl似乎是相对较高的API/ABI稳定，因此这通常不是问题。On Linux systems, you can see which dynamic libraries are loaded into a process by running
cat /proc/pid/mapswherepidis 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
libcurlcan be loaded. Howeverlibcurlseems to be relatively API/ABI stable so this usually wouldn't be a problem.