【发布时间】：2013-04-23 11:54:33
【问题描述】：
我正在尝试 CX_Freeze Linux 平台的应用程序。 Windows MSI 安装程序运行良好，但 Linux 对应部分并没有真正按照我想要的方式运行。
构建包时，它可以在原始系统上完美运行，但是当移植到不同的系统（尽管架构相同）时，它会产生段错误。我做的第一件事是检查库，libc、pthread 和 libdl 存在一些巨大的版本差异。所以我决定将这些包含在构建中，如下所示：
if windows_build:
build_exe_options['packages'].append("win32net")
build_exe_options['packages'].append("win32security")
build_exe_options['packages'].append("win32con")
pywintypes_dll = 'pywintypes{0}{1}.dll'.format(*sys.version_info[0:2]) # e.g. pywintypes27.dll
build_exe_options['include_files'].append((os.path.join(GetSystemDirectory(), pywintypes_dll), pywintypes_dll))
else:
build_exe_options['packages'].append("subprocess")
build_exe_options['packages'].append("encodings")
arch_lib_path = ("/lib/%s-linux-gnu" % os.uname()[4])
shared_objects = ["libc.so.6", "libpthread.so.0", "libz.so.1", "libdl.so.2", "libutil.so.1", "libm.so.6", "libgcc_s.so.1", "ld-linux-x86-64.so.2"]
lib_paths = ["/lib", arch_lib_path, "/lib64"]
for so in shared_objects:
for lib in lib_paths:
lib_path = "%s/%s" % (lib, so)
if os.path.isfile(lib_path):
build_exe_options['include_files'].append((lib_path, so))
break
在检查了原始的 cx_frozen bin 之后，动态库似乎在那里发挥了作用并完美地拦截了调用。虽然现在我处于 pthread 段错误的位置，因为他尝试了系统 libc 而不是我的（使用 ldd 和 gdb 检查）。
我的问题很简单，我正在尝试的这种方法很糟糕，因为它不能解决递归依赖问题。因此，我的问题是“这样做的更好方法是什么？还是我应该在我的安装程序中编写递归依赖解决方案？”
为了击败解决方案：“改用本机 Python”，我们还准备了一些带有 Linux（和 Bash 访问权限）的硬件设备（想想 2~4U），我们也想在其中运行它。当我们可以对它进行 cx_freeze 并与库一起发布时，移植整个 python（及其动态链接等）似乎是一项很重要的工作。
【问题讨论】：
-
我想说明我已经阅读了link
-
在 2021 年仍然是一个问题......使用 gcc 我们可以确定我们在编译时选择的 GLIBC 版本（已经安装了几个 GLIBC 版本），以便我们为旧版 linux 制作可执行文件）但我没有在 CX_Freeze 上找不到此选项。