为什么静态 X11 应用程序在其他计算机上失败？
我在 32 位 Fedora Core 9 机器上静态构建了 X11R5 库。然后我构建了一个使用 X11 的应用程序并静态链接它。到目前为止，一切都很好。 ldd 报告它是一个静态链接的应用程序。我在本地运行就可以了。但是当我将其复制到 64 位 FC9 计算机时，它失败如下：
assistant.static: xcb_io.c:228: _XSend: Assertion `!dpy->xcb->request_extra' failed。
当我运行 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 系统调用除外，这些调用需要在外部处理）。
感谢您的任何解释！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
X11 动态加载库，并且可能加载 64 位库而不是 32 位版本。
在运行时加载模块是正常的 - 就像加载插件或驱动程序时一样。由于模块是动态链接到 X11 本身的，因此您会发现自己陷入了混乱。
就我个人而言，我从来没有运气静态链接 X11 - 你真的需要吗？
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?
我似乎遇到了同样的问题，并找到了最酷的黑客解决方案！问题是它只是尝试加载 libXcursor.so.1，最终会拖拽 libX11 和 libX11 。所有朋友也在。
我的解决方案：编辑 EXE 并将 libXcursor.so.1 或 libXfixes.so 重命名为 libREMOVED.so 或具有相同 # 字母的名称。然后它将跳过加载那些可选扩展。
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.
您使用的库之一是
dlopeninglibXfixes。这几天很流行。您可以dlopening/dlsyming 替换为常规函数调用，并链接到libXfixes的静态版本。/opt/yourappname/lib，并将所有.so放在该目录中。或者，如果您希望用户能够在任何地方安装，请使用设置 LD_LIBRARY_PATH 的启动 shell 脚本。断言失败可能与
libXfixes有关，也可能无关，您可以通过将libXfixes.so复制到目标机器来快速检查。One of the libraries you use is
dlopeninglibXfixes. This is quite popular these days. You maydlopening/dlsyming with regular function calls, and link against a static version oflibXfixes./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 setsLD_LIBRARY_PATH.The assertion failure may or may not be related to
libXfixes, you may check it quickly by copyinglibXfixes.soto your target machine.