Why are static X11 apps failing on other machines? - x11

Question

I built X11R5 libs statically on a 32-bit Fedora Core 9 machine. Then I built an app which uses X11 and linked it statically. So far, so good. ldd reports it's a statically-linked app. I can run it locally just fine. But when I copy it over to a 64-bit FC9 machine, it fails as follows:
assistant.static: xcb_io.c:228: _XSend: Assertion `!dpy->xcb->request_extra' failed.
Aborted
When I run strace, it seems to be trying to open 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.
I don't understand why a statically-linked application would be trying to open shared X libs. Shouldn't everything needed to run the app be included via static linking (except of course for any Linux system calls the app makes, which need to be handled externally).
Thanks for any explanations!

Answer 1

I seem to be having the same problem and found the coolest hack around this! The problem is that it's only trying to load libXcursor.so.1, which ends up dragging libX11 & all friends in too.
My solution: edit the EXE and rename libXcursor.so.1 or libXfixes.so to libREMOVED.so or something with the same # letters. Then it will skip loading those optional extensions.

Answer 2

One of the libraries you use is dlopening libXfixes. This is quite popular these days. You may
Track it down, replace dlopening/dlsyming with regular function calls, and link against a static version of libXfixes.
Link your program dynamically, make sure its runtime library search path consists of your own directory, e.g. /opt/yourappname/lib, and place all your .sos in that directory. Or alternatively, if you want the users to be able to install anywhere, use a startup shell script that sets LD_LIBRARY_PATH.
The assertion failure may or may not be related to libXfixes, you may check it quickly by copying libXfixes.so to your target machine.

Answer 3

X11 dynamically loads libraries and it's may be loading the 64 bits libraries instead of the 32 bits version.
It's normal to load modules at runtime - like when loading plugins or drivers. And since the modules are dynamically linked to X11 itself, you're going to find yourself in a mess.
Personally, I never had luck linking X11 statically - is is really needed for you?