我正在尝试冻结并在我的Solaris11机器中分发以下使用多处理模块的python代码:
import multiprocessing
def f(name):
print 'hello', name
if __name__ == '__main__':
p = multiprocessing.Process(target=f, args=('fer',))
p.start()
p.join()
但是,即使可执行文件在编译器机器(Solaris11)下工作正常......
[root@zgv-wodbuild01 pyinstaller]# testfer/dist/testfer
hello fer
[root@zgv-wodbuild01 pyinstaller]# echo $?
0
...抱怨任何其他机器(Solaris11)中的多处理库:
root@dest01a # ./testfer.r004
Traceback (most recent call last):
File "testfer.py", line 1, in <module>
File "/root/pyinstaller/PyInstaller/loader/pyimod03_importers.py", line 389, in load_module
File "multiprocessing/__init__.py", line 84, in <module>
File "/root/pyinstaller/PyInstaller/loader/pyimod03_importers.py", line 546, in load_module
ImportError: ld.so.1: testfer.r004: fatal: relocation error: file /tmp/_MEIlBa4uh/_multiprocessing.so: symbol __xnet_sendmsg: referenced symbol not found
Failed to execute script testfer
root@dest01a # echo $?
255
PyInstaller命令已使用--onefile
标志启动,因此每个所需的库都应包含在最终的ELF文件中(多处理也是如此)。但我也尝试通过编辑.spec文件中的hidden-import
部分来显式包含多处理库。
我还尝试在旧的Solaris 10计算机中冻结源代码以确保向后兼容性。使用和不使用-lrt
等特殊LDFLAGS编译PyInstaller引导加载程序。使用--debug
标志。但到目前为止,没有任何工作,也没有给我一些线索。
显然,二进制文件是为正确的体系结构而构建的,并且没有库问题:
root@dest01a # file testfer.r004
testfer.r004: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, UltraSPARC1 Extensions Required, dynamically linked, stripped
root@dest01a # crle
Platform: 32-bit MSB SPARC
Default Library Path (ELF): /lib:/usr/lib (system default)
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
root@dest01a # ldd -r testfer.r004
libdl.so.1 => /lib/libdl.so.1
libm.so.2 => /lib/libm.so.2
libz.so.1 => /lib/libz.so.1
librt.so.1 => /lib/librt.so.1
libc.so.1 => /lib/libc.so.1
root@dest01a # ldd -r /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1
libelf.so.1 => /lib/libelf.so.1
libcryptoutil.so.1 => /lib/libcryptoutil.so.1
libz.so.1 => /lib/libz.so.1
libm.so.2 => /lib/libm.so.2
所以我没有想法了。 提前感谢任何见解。
更新:感谢Andrew Henle的评论,我已经取得了一些进展。我再次重新编译了PyInstaller引导加载程序,但这次将LDFLAGS环境变量建立为LDFLAGS="-lsocket -lrt"
。
现在它不再抱怨__xnet
个符号,而是symbol get_fips_mode
。如你所见:
root@lnrep01a # ./testfer.r004
ld.so.1: testfer.r004: fatal: relocation error: file /lib/libsoftcrypto.so.1: symbol get_fips_mode: referenced symbol not found
Killed
所以我可能只需要在编译过程中添加一些额外的标志。我将通过互联网寻找它们,但如果有人知道缺少什么,那将非常受欢迎。
答案 0 :(得分:0)
原来这不是一个gcc bug。在深入分析了两种环境之后,我意识到/lib/libsoftcrypto.so.1
库差异很大。事实上,编译器机器中的库包含get_fips_mode
符号......
[root@zgv-wodbuild01 pyinstaller]# nm /lib/libsoftcrypto.so.1 | grep -i get_fips_mode
[3438] | 623016| 212|FUNC |GLOB |0 |18 |get_fips_mode
...目的地机器没有:
root@dest01a # nm /lib/libsoftcrypto.so.1 | grep -i get_fips_mode
[3755] | 0| 0|FUNC |GLOB |0 |UNDEF |get_fips_mode
尝试使用具有类似库版本的其他编译器机器后,使用-lsocket
ldflag编译pyinstaller引导加载程序就足够了:
root@dest01a # ./testferv3
hello fer
root@dest01a # echo $?
0