Почему статические приложения X11 не работают на других компьютерах? - PullRequest
1 голос
/ 17 июля 2010

Я статически собирал библиотеки X11R5 на 32-битной машине Fedora Core 9. Затем я создал приложение, которое использует X11, и связал его статически. Все идет нормально. ЛДД сообщает, что это статически связанное приложение. Я могу запустить его на месте просто отлично. Но когда я копирую его на 64-битную машину FC9, происходит сбой следующим образом:

assistant.static: xcb_io.c: 228: _XSend: утверждение `! Dpy-> xcb-> request_extra 'не выполнено.
Отменено

Когда я запускаю strace, он пытается открыть libXfixes.so:

...
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libXfixes.so", O_RDONLY)     = -1 ENOENT (No such file or directory)
open("/usr/lib/libXfixes.so", O_RDONLY) = -1 ENOENT (No such file or directory)
munmap(0xf7bf9000, 123447)              = 0
open("libXfixes", O_RDONLY)             = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 8
fstat64(0x8, 0xff86a9e8)                = 0
mmap2(NULL, 123447, PROT_READ, MAP_PRIVATE, 8, 0) = 0xfffffffff7bf9000
close(8)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libXfixes", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/usr/lib/libXfixes", O_RDONLY)    = -1 ENOENT (No such file or directory)
munmap(0xf7bf9000, 123447)              = 0
open("libXfixes.so.4", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 8
fstat64(0x8, 0xff86a9e8)                = 0
mmap2(NULL, 123447, PROT_READ, MAP_PRIVATE, 8, 0) = 0xfffffffff7bf9000
close(8)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libXfixes.so.4", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/usr/lib/libXfixes.so.4", O_RDONLY) = -1 ENOENT (No such file or directory)
munmap(0xf7bf9000, 123447)              = 0
open("libXfixes", O_RDONLY)             = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 8
fstat64(0x8, 0xff86a9e8)                = 0
mmap2(NULL, 123447, PROT_READ, MAP_PRIVATE, 8, 0) = 0xfffffffff7bf9000
close(8)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libXfixes", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/usr/lib/libXfixes", O_RDONLY)    = -1 ENOENT (No such file or directory)
munmap(0xf7bf9000, 123447)              = 0
write(2, "assistant.static: xcb_io.c:228: "..., 85assistant.static: xcb_io.c:228: _XSend: Assertion `!dpy->xcb->request_extra' failed.

Я не понимаю, почему статически связанное приложение пытается открыть общие библиотеки X. Если все необходимое для запуска приложения не должно быть включено через статическое связывание (за исключением, разумеется, любых системных вызовов Linux, которые делает приложение, которые должны обрабатываться извне).

Спасибо за любые объяснения!

Ответы [ 3 ]

0 голосов
/ 21 июня 2013

Кажется, у меня возникла та же проблема, и я нашел самый крутой взлом вокруг этого! Проблема в том, что он только пытается загрузить libXcursor.so.1, что приводит к перетаскиванию libX11 и всех друзей тоже.

Мое решение: отредактируйте EXE-файл и переименуйте libXcursor.so.1 или libXfixes.so в libREMOVED.so или что-то с теми же # буквами. Затем он пропустит загрузку этих необязательных расширений.

0 голосов
/ 22 июня 2013

Одна из используемых вами библиотек: dlopen ing libXfixes. Это довольно популярно в наши дни. Вы можете

  1. Отследите его, замените dlopen ing / dlsym ing обычными вызовами функций и установите связь со статической версией libXfixes.
  2. Свяжите вашу программу динамически, убедитесь, что путь поиска библиотеки времени выполнения состоит из вашего собственного каталога, например, /opt/yourappname/lib и поместите все свои .so в этот каталог. Или же, если вы хотите, чтобы пользователи могли устанавливать в любом месте, используйте сценарий запуска оболочки, который устанавливает LD_LIBRARY_PATH.

Ошибка подтверждения может или не может быть связана с libXfixes, вы можете быстро проверить ее, скопировав libXfixes.so на целевой компьютер.

0 голосов
/ 17 июля 2010

X11 динамически загружает библиотеки и может загружать 64-битные библиотеки вместо 32-битной версии.

Нормально загружать модули во время выполнения - как при загрузке плагинов или драйверов.А поскольку модули динамически связаны с самим X11, вы окажетесь в беспорядке.

Лично мне никогда не везло связывать X11 статически - это действительно нужно для вас?

...