麻烦冻结(使用PyInstaller)python源包括Solaris中的多处理模块

时间:2016-09-21 08:21:28

标签: python multiprocessing solaris pyinstaller

我正在尝试冻结并在我的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

所以我可能只需要在编译过程中添加一些额外的标志。我将通过互联网寻找它们,但如果有人知道缺少什么,那将非常受欢迎。

1 个答案:

答案 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