Just had some useful discussion with @angerman on Reddit. This revealed the following useful information from cabal build -v3:
Searching for pkg-config in path.
Found pkg-config at /home/bradrn/Documents/wayland/wlhs/pkg-config
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --version
/home/bradrn/Documents/wayland/wlhs/pkg-config is version 2.1.0
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --variable pc_path pkg-config
[…omitted…]
Searching for pkg-config in path.
Found pkg-config at /home/bradrn/Documents/wayland/wlhs/pkg-config
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --version
/home/bradrn/Documents/wayland/wlhs/pkg-config is version 2.1.0
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --list-all
[…omitted…]
/home/bradrn/Documents/wayland/wlhs/pkg-config returned ExitFailure 141
/home/bradrn/Documents/wayland/wlhs/pkg-config returned ExitFailure 141
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: output of /home/bradrn/Documents/wayland/wlhs/pkg-config:
hGetContents: invalid argument (invalid byte sequence)
So this is weird: hGetContents is reporting an invalid byte sequence, of all things. As an experiment I made a wrapper script which teed the output of pkg-config to a file, then checked the encoding:
$ file pkg-config-out
pkg-config-out: ISO-8859 text
So pkg-config is outputting text in ISO-8859… which, apparently, hGetContents can’t handle. Resetting the locale to C didn’t help, though.
Upon further investigating the pkg-config output, the following line sticks out to me:
vpl Intel® Video Processing Library - Accelerated video decode, encode, and frame processing capabilities o n Intel® GPUs
Could the ® be the culprit here? What’s more, pacman logs show that libvpl was installed a week ago, so the timing is suspicious. But I don’t know, yet.