Почему статические приложения X11 не работают на других машинах?

Question

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

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

Когда я бег Трассирования, кажется, пытаются открыть 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 LIBS , Если все, что необходимо для запуска приложения, должно быть включено через статическое связывание (за исключением, конечно, любых системных вызовов Linux, создаваемых приложением, которые необходимо обрабатывать извне).

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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