On Sun, Apr 23, 2017 at 02:18:22PM -0700, Michael Deutschmann wrote: > (Not trimming because of the delay between this response and the original > discussion): > On Sun, 29 Jan 2017, you wrote: > > On 25 January 2017 at 05:03, Michael Deutschmann <[email protected]> wrote: > > > On my system, a vanilla build of texinfo 6.3 frequently outputs a message: > > > > > > sh: 1: locale: not found > > > Couldn't set UTF-8 character type in locale. > > > > > > In turn, this causes a dozen "make check" tests to FAIL. > > > > > > The problem is one chunk of code that badly wants to find and change to a > > > locale with the wanted character set. This is futile on my system as I > > > am running uClibc with locales compiled out. There is no locale utility > > > and setlocale() is a constant function. > > > > I've deleted the error message "Couldn't set UTF-8 character type in > > locale." because it's easy to do so. I think the tests will still fail > > on your system with the error message from "sh" ("locale: not found") > > because I think that popen doesn't do anything with standard error. I > > haven't researched how to fix this; suggestions welcome. > > > > Presumably Perl has its own UTF-8 support and doesn't need to use that > > of libc, so the fallback module can still work correctly. > > Sorry it took so long for me to get back to you... > > I think the proper way to handle this is to check for the existence of a > "locale" command-line utitity at *configure* time. > > The utility peeks behind the C library's abstraction barrier, so if > present it is going to be in the same "package" as the C library. So it > is unlikely "locale" could be absent while compiling texinfo but present > later, or vice versa.
It doesn't do any harm to check for "locale" at run-time, does it? Maybe it's true that "locale" will never be installed (or uninstalled) after Texinfo is built, but it seems more flexible to do the check at run-time, just in case.
