[macOS/Darwin users: I have a libc question toward the end of this message.]
Hi Alexis, At 2026-02-23T21:19:16+0100, Alexis (surryhill) wrote: > > I bumped into this commit log message and thought it might amuse you. > > Thanks for sharing =) I knew it was a land mine when I planted it. It's now gone off. :-O > > Any luck re-running the command with the corrected environment > > variable name? > > First of all let me say that I should've caught the LC_CALL typo, but > most of my open source / groff work happens in the evening I might not > be the most attentive after a long day, apologies. No worries; we're all human. Well, except for LLM chat bots... > Here's the output of the commands as requested: > > /usr/bin/env LC_ALL=C printf 'Eat at the caf\351.\n' | /usr/bin/od -x > 0000000 6145 2074 7461 7420 6568 6320 6661 2ee9 > 0000020 000a > 0000021 > > /usr/bin/env LC_ALL=C printf 'Eat at the caf\351.\n' | /usr/bin/od -c > 0000000 E a t a t t h e c a f 351 . > 0000020 \n > 0000021 Okay. Your system does not use glibc but _does_ use Latin-1 as the character encoding for the "C" locale. That's a foot pressing squarely on the land mine I set. > In a previous email you said: > > This automated test needs to both (1) set up the locale and (2) use > > a portable incantation of printf(1). If we can achieve that on your > > system, then I think we have a path to resolving this test failure. > > So the (hopefully) good news is that while nixpkgs on Darwin uses > libSystem.dylib for its libc it does use printf from GNU's coreutils, > which seems more predictable / familiar in the context of a groff > build environment: > > which printf > /nix/store/hf6y9njhfwvigr25kzrwmsvmv6jpni5n-coreutils-9.9/bin/printf > > Does this help to open up a path to resolving this test failure? Partly. What I need to know at this point is an easy way from a shell script to ask the system what its libc implementation is, when it's "libSystem.dylib" in particular. I don't know if there's any such thing as running an alternative libc on a macOS/Darwin system--maybe the system crashes; maybe Apple activates a kill switch in your Mac; or maybe things work more or less fine. I'd prefer not to do a simple file existence test for wherever "libSystem.dylib" is installed, because that doesn't directly answer the question "what is my libc?" Theoretically, you could have more than one libc on the system. But that may have to do if there's no better way of getting this information. Other libcs make this easy.[1] I can then update the logic in the test script[2] to handle this case. Regards, Branden [1] For example, you can run GNU libc as an executable. $ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Debian GLIBC 2.31-13+deb11u13) stable release version 2.31. Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 10.2.1 20210110. libc ABIs: UNIQUE IFUNC ABSOLUTE For bug reporting instructions, please see: <http://www.debian.org/Bugs/>. [2] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/preconv/tests/smoke-test.sh?h=1.24.0.rc4#n97 has_glibc= if command -v locale > /dev/null then has_glibc=yes fi # Fall back to the locale. # # On glibc systems, the 'C' locale uses "ANSI_X3.4-1968" for the # character set, but preconv assumes Latin-1 instead of US-ASCII. # # On non-glibc systems, who knows? But at least some use UTF-8. if [ -n "$has_glibc" ] then charset=ISO-8859-1 else charset=UTF-8 fi
signature.asc
Description: PGP signature
