标签：调用 x86 lib Python python so.1 64 linux 相互
目录PyNode是一个轻量级的Node.js C++扩展包，使用Node.js的N-API写成的，能在同一个进程里通过底层C/C++的API实现python和javascript的互操作，只需要进行数据类型的转换，运行效率高。详细的原理讲解可以看我这篇介绍。
本文主要简单记录一下使用PyNode的一些实践经验。
前提
安装的前提是装好两种语言的runtime。
- Node.js：没啥特别的，直接装就行了。
Linux系统安装Node.js可以直接用NVM（Node Version Manager），与python的conda类似。
- Python：由于PyNode是在Node.js的C++扩展里嵌入了python，因此需要Python的动态/静态库。
一般情况下，cpython官方给的安装版都是由一个动态库（比如在Linux里会叫：libpython3.x.so），和一个依赖该库的小可执行文件组成。这样非常方便其它C++程序嵌入python。
这种Python通常是通过--enable-shared选项编译安装的，可以在你的python环境里运行：
这个返回import sysconfig sysconfig.get_config_vars('Py_ENABLE_SHARED')[1]就是true，[0]就是false。true代表着是通过--enable-shared选项编译安装的。
还有一种更本质的方法，直接看可执行文件依赖的动态库。Linux上可以通过ldd命令，Mac OS上可以通过otools -L命令，查看你的python可执行文件的依赖情况：
出现结果例如：# If your python command is "python3", use `which python3` # On Linux: ldd `which python` # On Mac OS otools -L `which python`
说明你的python有动态库，那么PyNode的安装应该不会出现啥问题。# On Linux root@7fe6daacb730:/# ldd `which python` linux-vdso.so.1 (0x00007ffe41b47000) libpython3.9.so.1.0 => /usr/local/lib/libpython3.9.so.1.0 (0x00007fd5feb2c000) # python library libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fd5feaf2000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd5fead1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd5feacc000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fd5feac7000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd5fe944000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5fe781000) /lib64/ld-linux-x86-64.so.2 (0x00007fd5fef08000) # On Mac OS /your/python/executable/dir/venv/bin/python: /Library/Frameworks/Python.framework/Versions/3.9/Python (compatibility version 3.9.0, current version 3.9.0) # Depends on python shared library /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
安装
首先，如果python库没啥问题，按项目简介所说，安装前首先确认好你需要使用的python环境，如果要用虚拟环境，也先进入虚拟环境。
# Install gyp-next
pip install gyp-next
# Install PyNode
npm install @fridgerator/pynode
# or
yarn add @fridgerator/pynode
那么，如果你的python不依赖动态库咋办呢？如果你是Conda环境，那么还是有可能找到动态库的：
找到你的Python动态库
适用于Conda环境。一些详细的log可以参考这个Issue。下面的介绍跟我在这个Issue里的comment基本一样的。
如果你用的是Conda环境，恭喜你，他们提供的python，旧一点的，可能会遇到GCC版本低问题，而新一点的，已经直接用静态库build成可执行文件了，再也不依赖动态库了：
(py38) $ ldd `which python`
linux-vdso.so.1 (0x00007ffe03efd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faa187be000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007faa185bb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faa1821d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faa17ffe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa17c0d000)
/lib64/ld-linux-x86-64.so.2 (0x00007faa18d5d000)
不过好消息是，Conda声称他们尽管不用，但还是提供了动态库，所以我们只要找到它就可以了。有一个很好用的python包find_libpython，能很好地找到你的python动态库：
(py38) $ pip install find_libpython
(py38) $ find_libpython # or "python -m find_libpython" /xxx/miniconda3/envs/py38/lib/libpython3.8.so.1.0.
然后我们要做的就是把动态库的目录路径作为库路径添加到PY_LIBS里（-L）。
但这样做链接的时候能找到库，后面执行的时候也还是会找不到，一种解决方法是用rpath把这个路径给他刻烟吸肺，运行的时候也能找到（通过-Wl,-rpath=）。那么加在一起，你的包安装命令就应该是：
PYTHON_SHARED=/xxx/miniconda3/lib PY_LIBS="$(python ../build_ldflags.py) -L$PYTHON_SHARED -Wl,-rpath=$PYTHON_SHARED" npm install @fridgerator/pynode
使用
没啥好说的，使用起来很简单，按项目首页的Readme做就可以了。列一些使用Tips和可能出问题的地方。
const pynode = require('@fridgerator/pynode')的时候动态链接错误
Uncaught:
Error: libpython3.9.so.1.0: cannot open shared object file: No such file or directory
at Object.Module._extensions..node (node:internal/modules/cjs/loader:1168:18)
at Module.load (node:internal/modules/cjs/loader:989:32)
at Function.Module._load (node:internal/modules/cjs/loader:829:14)
at Module.require (node:internal/modules/cjs/loader:1013:19)
at require (node:internal/modules/cjs/helpers:93:18) {
code: 'ERR_DLOPEN_FAILED'
}
根据StackOverflow上说，链接时能找到库是一回事，不代表它运行的时候也能找到，运行的时候查找动态库又有另一套路径（……）。
验证方法可以是：
cd进入node_modules/@fri/x/build/Release里，会找到编译好的PyNode.node
然后，ldd PyNode.nodelinux-vdso.so.1 (0x00007ffef7de3000) libpython3.9.so.1.0 => not found # Failed to find when executing libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f976bd9c000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f976ba13000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f976b7fb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f976b40a000) /lib64/ld-linux-x86-64.so.2 (0x00007f976c1bd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f976b06c000)
就是说，build的时候提供-lpython3.9和-L<path_to_shared_library>是明确指定好库，这样生成的文件PyNode.node才包含这个库，换句话说，它才会出现在ldd的list里。
但这个可执行文件运行的时候找共享库，跟build的时候提供的路径没有关系，感觉它像是会在一个给定的路径集合里找，所以这些路径集合里没有libpython3.9.so.1.0，那ldd就会显示not found。
在linux下，一种解决方案是通过往环境变量LD_LIBRARY_PATH里添加这个动态库的目录，例如：如果动态库的绝对路径为/opt/libpath/libpython3.9.so.1.0，那么可以在~/.bashrc里添加一行：
export LD_LIBRARY_PATH="/opt/libpath:$LD_LIBRARY_PATH"
这之后再ldd .node文件，就能找到了：
linux-vdso.so.1 (0x00007ffc01562000)
libpython3.9.so.1.0 => /opt/libpath/libpython3.9.so.1.0 (0x00007f041a327000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f041a123000)
libstdc++.so.6 => /mnt/asp_test/env/miniconda3/lib/libstdc++.so.6 (0x00007f041a9be000)
libgcc_s.so.1 => /mnt/asp_test/env/miniconda3/lib/libgcc_s.so.1 (0x00007f041a9aa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0419d32000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f0419b2f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0419791000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0419572000)
/lib64/ld-linux-x86-64.so.2 (0x00007f041a91d000)
另一种方法是用rpath，就像上面针对Conda环境安装的那样，把动态库的路径同时也加到-Wl,-rpath=里。
ImportError: math.cpython-39-x86_64-linux-gnu.so: undefined symbol: PyFloat_Type
或者类似undefined symbol: PyExc_ValueError和undefined symbol: PyExc_SystemError的错误。
通常会在Linux上出现，属于是打开动态链接的时候出了问题。PyNode提供了一个dlOpen函数来手动打开动态链接。
- 首先肯定是要找到你的动态库，可以使用上文所说的
find_libpython包来查找。假设为：/opt/libpath/libpython3.9.so.1.0 - 然后在Node.js里：
const pynode = require('@fridgerator/pynode'); pynode.dlOpen('/opt/libpath/libpython3.9.so.1.0');
在Node.js里运行Python的multiprocessing
Node.js通过C API起了一个python解释器，这种情况下本进程的可执行程序其实是node。换句话说，sys.argv[0]，sys.executable都是指向node的可执行程序。
而python环境中开新的多进程同时运行，会获取当前的可执行程序（excutable），发现竟然不是python，那multiprocessing就读不懂这个可执行程序的信息，比如说找不到main从而报错。
查看源代码后发现了multiprocessing.spawn里的这么一段：
有一个接口set_executable，可以重新设置可执行程序。所以通过PyNode去调用使用了multiprocessing的python程序可以这么做：重新设置executable为你的python可执行程序。
比如，我用了virtualenv，我的可执行程序就是：/my/project/path/venv/bin/python
const pynode = require('@fridgerator/pynode');
pynode.startInterpreter();
const sp = pynode.import('multiprocessing.spawn');
sp.get('set_executable').call('/my/project/path/venv/bin/python');
// Run the multiprocessing python code
需要注意的是，这种补丁操作只适用于纯Python的multiprocessing。如果你的某个子进程混入了一些node.js的代码，那么会报错。还没搞懂具体原理，我猜想原因可能是，子进程是通过python可执行程序起的，找不到node环境。
Jest单元测试卡住不会结束
表现是：
- 当测试文件多于
cpu_count - 1的时候，整个测试程序卡住，不会再进行下一个test suite。 - 如果使用
--runInBand选项禁止多线程执行单元测试，会Segment Fault。
起因是segment fault了，而Jest不知道为啥在多线程跑单元测试的时候（一般一个文件一个线程，开线程的数量是cpu_count - 1），在某些OS里遇到segment fault当前线程就会卡死，所以总共会坚持cpu_count - 1个test suite，然后才卡死。如果文件数据少于cpu_count - 1的话，会顺利运行完。
经过研究，segment fault的原因是：StartInterpreter不可以重复调用2次，因为它里面有一个函数执行的时候需要Python的全局进程锁（GIL），但StartInterpreter在第二次调用的时候不调用Py_Initialize，因此也不重新获取GIL，导致segment fault了。
而Jest的每个测试的环境都是全新的，不管是把const pynode = require('@fridgerator/pynode');放到单独一个文件里require，还是用一个全局变量标记是否已经start Interpreter都无法阻止StartInterpreter被调用2次导致segment fault。
解决办法就是不用Jest 修改源码，不管怎样在调用那个函数前都获取一下GIL（PR）。
这个PR还没被merge进pynoe的版本，想安装这个版本的话，可以下载我fork的repo里的源码。
然后在项目根目录里npm pack，会得到一个.tgz文件，然后在package.json里这么写：
"dependencies": {
"@fridgerator/pynode": "file:./pynode/fridgerator-pynode-0.5.2.tgz"
},
路径就是你的这个文件相对于package.json的路径。
标签：调用,x86,lib,Python,python,so.1,64,linux,相互 来源： https://www.cnblogs.com/milliele/p/15856279.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。