`pkg-config --static --libs x11` unusable for static linking?

xorg at pengaru.com xorg at pengaru.com
Wed Mar 15 21:12:16 UTC 2017

On Wed, Mar 15, 2017 at 02:01:06PM +0100, walter harms wrote:
> you are aware the glibc does not support static linking ?
> re,
>  wh

The glibc caveats surrounding static linking are completely orthogonal to
what is happening here.  The library order in the link phase matters and
`pkg-config --static --libs x11` is outputting options both incomplete and
ordered incorrectly.

The value of static linking in this case is producing a binary which
doesn't require graphical dependencies to be installed on what may
otherwise be headless systems having little more than glibc and ssh

Please note that the smoke test below passes, after using the fixed up link
command mentioned previously to produce the static binary, with glibc on
debian jessie amd64:

# mkdir /tmp/foo
# mkdir /tmp/foo/tmp
# mount --bind /tmp /tmp/foo/tmp # for X socket
# mkdir /tmp/foo/proc
# mount --bind /proc /tmp/foo/proc # what the program monitors
# mkdir /tmp/foo/home
# mount --bind /home /tmp/foo/home # for ~/.Xauthority and static test program
# chroot /tmp/foo /tmp/foo/home/vc/src/vmon-static

The program works just fine in that ad-hoc root with absolutely zero .so
dependencies present, there isn't an /etc/nsswitch.conf, this is desirable.
This program may be run on any amd64 linux box to successfully monitor it
without any concern for what is installed, even tunneled over `ssh -X`
provided the DISPLAY environment variable is amended to use
instead of localhost to avoid the name resolution glibc caveat.

There's also the musl-libc route for when glibc's dynamic dependencies are
unignorable, but this is all off-topic.  This is fundamentally about static
linking the X dependencies, not glibc.

It would be appreciated if `pkg-config --static --libs x11` actually output
a usable set of flags.  Playing libc roullette is completely orthogonal and
a decision left up to the user not us, and the current situation blocks
users from even taking a spin.  It turns out the odds of winning are
actually in the user's favor, why are we interfering?  Is it so difficult
to make pkg-config output the correct things?  Isn't this the whole point
of pkg-config?

Vito Caputo

More information about the xorg mailing list