fn foreign_libxcb() -> Option<String>Expand description
The libxcb this process’s libX11 calls, when that is another copy than the host’s
libxcb.so.1, which is the one the NVIDIA library calls. The manylinux policy leaves libX11 to
the host but lets a wheel bundle libxcb, and a wheel whose libraries load libX11 first binds the
host’s libX11 to its own copy (a pcmflux wheel whose libpulse carries libxcb does). NvFBC opens
its display through libX11 and then calls the host’s libxcb on that connection, whose structure
is laid out by the other build: a mutex read at a shifted offset makes glibc abort the process,
and a flag read at one leaves the library waiting forever.
Opening a display whose name carries no display number fails inside xcb_parse_display
before anything connects, which resolves libX11’s lazily bound libxcb imports through
libX11’s own scope, so the GOT slot then names the copy every later call of libX11 reaches.