【问题标题】:cx_freeze embedding my shared object library into the binary executable?cx_freeze 将我的共享对象库嵌入到二进制可执行文件中?
【发布时间】:2013-04-03 02:25:05
【问题描述】:

我可以使用 cx_freeze 来打包我的 python 工具,但是我需要的库无法加载。由于某种原因,输出的可执行文件/二进制文件名称不断包含在路径中。

我收到以下错误:

OSError:/home/derekx/sbu/build/exe.linux-x86_64-2.7/secure_boot_utility/lib/libcrypto.so.1.0.0:无法打开共享对象文件:不是目录

库被打包到 /home/derekx/sbu/build/exe.linux-x86_64-2.7/lib/libcrypto.so.1.0.0

创建的二进制“secure_boot_utility”也在 build/exe.linux86_64-2.7 目录中。

我的输入脚本和 setup.py 位于 /home/derekx/sbu。

我使用“python setup.py build”来打包工具/依赖项..

任何帮助将不胜感激。我已经尝试了这些选项的组合,但仍然出现相同的错误。

我的 setup.py 是:

import sys
from cx_Freeze import setup, Executable

sys.path.append('sbu_scripts/')
sys.path.append('lib/')

binincludes = ['libcrypto.so.1.0.0']
binpaths = ['/home/derekx/sbu/lib']
includefiles = [('lib/libcrypto.so.1.0.0','lib/libcrypto.so.1.0.0'),]

exe = Executable(
    script="secure_boot_utility.py",
    )

setup(
    name = "SecureBoot",
    version = "0.1",
    description = "Test Secure Boot",
    options = {"build_exe": {'copy_dependent_files':True, 'create_shared_zip':True, 'bin_includes':binincludes, 'bin_path_includes':binpaths, 'include_files':includefiles}},
    executables = [exe]
    )

【问题讨论】:

  • 我以前没见过。您可以尝试将库复制到与可执行文件相同的文件夹中,而不是复制到 lib/ 子文件夹中吗?
  • 是的。选项 'copy_dependent_files':True 似乎在创建可执行文件的同一级别复制了我需要的几个库(包括 libcrypto)。如果我也将 include_files 设置为向上复制一级,则在运行可执行文件时仍然会遇到同样的问题。谢谢
  • 如果我添加 zip_include 以将库作为 lib/libcrypto.so.1.0.0 添加到 zip 文件中,我仍然会收到相同的错误 :(
  • 编译的库不能在 zip 文件中工作,它们必须是真实文件。您可以在与可执行文件相同的目录中显示带有 libcrypto 的目录布局吗?你的代码是如何加载 libcrypto 的?
  • 使用 cx_freeze/setup.py 之前:

标签: python shared-libraries cx-freeze


【解决方案1】:

我不确定为什么顶级目录 (getcwd) 是可执行文件名。

无论如何,我都能够使用 os.path.exists 在我的代码中添加一些内容并重新调整发送到 LoadLibrary 的值。

感谢 Thomas 抽出宝贵时间回复。

这本来是别人的工具,我不得不支持。 发生的事情是 sys.path[0] 被用来获取当前工作目录以构建正在加载的库的完整路径。 我不确定为什么使用 cx_freeze 创建的可执行文件总是将可执行文件名称嵌入到当前工作目录中。

我是如何修复它的,检查了构建的库的完整路径是否与 os.path.exists 一起存在:

if os.path.exists(path_to_lib) is False:
    path_to_lib = LibName

return path_to_lib

这样,如果完整路径存在,它就可以工作,并且如果它不只使用应该从 LD_LIBRARY_PATH 环境设置中获取它的 LibName。

【讨论】:

  • 不客气。顺便说一句,向以后的读者展示您制定的解决方案是一种很好的做法。没有什么比发现有人已经解决了您遇到的问题但没有说明如何解决更令人沮丧的事情了。
  • 添加了我所做的。再次感谢
  • 顺便说一句,可执行文件位于 sys.path 上的原因是,通过某些选项,可执行文件可以附加一个包含纯 python 模块的 zip 文件。
  • 我尝试将 append_script_to_exe 和 include_in_shared_zip 设置为 False 似乎都没有帮助。您指的是另一种选择吗?谢谢
  • 这对解决您的问题没有帮助,但它解释了为什么可执行文件名称在 sys.path 中。
猜你喜欢
  • 2013-11-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-05-29
  • 2023-03-15
  • 2022-11-10
  • 2015-07-20
相关资源
最近更新 更多