On Sat, Feb 21, 2026 at 01:53:01PM +0100, G. Branden Robinson wrote:
> [please don't email info-groff@gnu with feedback; it's not a big
> problem, but it makes work for the list moderators]
Apologies for that and to the list moderators, I seem to have been
unattentive with regards to the addresses when replying.
Thanks for the notes on the build log, quite insightful!
If there's anything you'd like me to try out or test, just let me know.
> These warnings happen because groff's installation directory gets
> interpolated into man page text, and under the nixpkgs regime, these
> directory names are what Mike Myers would call "frickin' 'uge".
Yes, the nixpkgs output paths are rather long, here's an example
snippet from groff(7):
/nix/store/rjhh3wgj39lr6vvnxyd5ld7y70x9vlj4-groff-1.24.0.rc4/lib/X11/
app-defaults
Application defaults directory for gxditview(1).
> Okay, please run that printf(1) command in your build environment and
> tell me what you get. The script `export LC_ALL=C`'s earlier, so you
> should do similar.
>
> $ LC_CALL=C printf 'Eat at the caf\351.\n'
/usr/bin/env LC_CALL=C printf 'Eat at the caf\351.\n' | /usr/bin/od -x
0000000 6145 2074 7461 7420 6568 6320 6661 2ee9
0000020 000a
0000021
To ensure that my MUA doesn't mess with any character encodings from
the shell I decided to pipe the output to od(1).
Please find attached print.log which contains the output from
/usr/bin/script printf.log /usr/bin/env LC_CALL=C printf 'Eat at the caf\351.\n'
Both of which will hopefully provide you with the necessary information.
> I don't know what to expect from your system's libc. I'd like to.
>
> What _is_ your libc vendor, by the way? Is there an idiomatic way to
> test for its identity?
In my previous message I wrote I was testing on Darwin using nixpkgs
25.11 and I should've been more precise. Darwin is the build name
in nixpkgs for macOS and I'm on macOS 26.2, so that would make
Apple the libc (or rather libSystem.dylib) vendor.
Hopefully this is useful to diagnose the issue and find the cause.
Alexis
