Замораживание общих объектов с помощью cx_freeze в Linux

Я пытаюсь CX_Freeze приложение для платформы Linux. Установщик Windows MSI работает отлично, но контрагент Linux на самом деле не работает так, как я хочу.

Когда пакет собран, он отлично работает в исходной системе, но при портировании в другую систему (хотя и с той же архитектурой) он генерирует segfault. Первым делом я проверил библиотеки, и между 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 кажется, что динамические библиотеки играют там роль и прекрасно перехватывают вызовы. Хотя сейчас я нахожусь в той части, где pthread segfaults из-за того, что он пробует системы libc вместо моей (проверено с помощью ldd и gdb).

Мой вопрос довольно прост, этот метод, который я пробую, ужасен, так как он не решает рекурсивные зависимости. Поэтому мой вопрос был бы "как лучше это сделать? Или я должен написать рекурсивное решение зависимостей в моем инсталляторе?"

И для того, чтобы превзойти Решение: "Вместо этого используйте собственный Python", мы получили несколько аппаратных устройств (например, 2~4U) с Linux (и доступом к Bash), где мы хотим запустить это также. портирование всего Python (с его динамическими ссылками и т. д.) показалось мне способом много работать, когда мы можем cx_freeze и отправлять библиотеки с ним.

1 ответ

Решение

Я не знаю о ваших других проблемах, но доставка libc.so.6 для другой системы способ, которым вы это делаете, не может работать, как описано здесь.

Другие вопросы по тегам