GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

[Hans-Bernhard Bröker]

Am 24.08.2016 um 17:21 schrieb Eric Blake:
> On 08/22/2016 04:23 PM, Hans-Bernhard Bröker wrote:

>> Well, FWIW, the attached lift-autconf-version-restriction.diff bluntly
>> removes that restriction.  I won't guarante the absence of any adverse
>> effect, thoughe ;-)

> The strongest argument for insisting on an EXACT version is that you
> want the generated code checked into git, and for that code to not
> undergo a lot of churn if anyone regenerates it under a different
> autotool version.  Once you have generated files checked in, then
> developers that don't have the right autotools can get by with the
> checked in output from the tools.

Fair enough.  I took the liberty of counting things in current newlib git:

       2 # Generated by GNU Autoconf 2.66.
       2 configured by $0, generated by GNU Autoconf 2.66,
       3 # Generated by GNU Autoconf 2.69.
       4 # Generated by GNU Autoconf 2.64.
       4 configured by $0, generated by GNU Autoconf 2.64,
       4 generated by GNU Autoconf 2.66.  Invocation command line was
       7 # Generated by GNU Autoconf 2.68.
       8 generated by GNU Autoconf 2.64.  Invocation command line was
      10 configured by $0, generated by GNU Autoconf 2.69,
      20 generated by GNU Autoconf 2.69.  Invocation command line was
     102 # Generated by GNU Autoconf 2.68 for newlib 2.4.0.
     102 [m4_warning([this file was generated for autoconf 2.68.
     102 m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],,
     112 configured by $0, generated by GNU Autoconf 2.68,
     224 generated by GNU Autoconf 2.68.  Invocation command line was

How come that the vast majority of the autoconf-generated files 
currently show a version 2.68, instead of the one the restriction wants 
to enforce:

       1   [m4_define([_GCC_AUTOCONF_VERSION], [2.64])])

;-P

> As long as we rely on --cygnus, we rely on an exact version being
> checked in.  But if our goal is to get rid of --cygnus, it makes more
> sense to DROP the generated files from git, and to merely require that
> developers have new-enough tools installed locally,

Putting generated files into version control only really makes sense if 
the tools needed to generate them cannot really be expected to be 
present in every would-be user's tool box.

And frankly it would be very strange indeed for anyone to have a version 
of autoconf old enough to disqualify.  The version the restriction 
currently wants (but fails) to enforce is 2.64, from 7 years ago, and 
there hasn't been a new release since 2.69, 4 years ago.

> So I would favor a move towards dropping the generated files altogether
> from git (they would still be present in tarballs created by 'make
> dist', of course),

I would agree, but then again, I'm a newbie to this source tree.