On Jan 19 11:40, Eric Blake wrote:
> On 01/18/2017 09:23 AM, Eric Blake wrote:
> > On 01/18/2017 06:12 AM, Dr. Volker Zell wrote:
> > 
> >>>>
> >>>> The source code can be found in the file (after unpacking of
> >>>> https://ftp.gnu.org/gnu/libidn/libidn-1.33.tar.gz)
> >>>>
> >>>>  o
> >>>> .../libidn-1.33-1.x86_64/src/libidn-1.33/lib/gltests/test-localename.c
> >>>
> >>> Do you have a self-contained testcase, by any chance?
> >>
> >> No, just the testcase from the testsuite in libidn.
> > 
> > The test comes from gnulib, so I'm familiar with ideas on how to try and
> > whittle it down to a smaller self-contained test.  I'll see if I can
> > spend a moment on it today.
> > 
> 
> After stepping through a debugger, it looks like this is a bug in gnulib
> and not cygwin.  Gnulib is trying to test that its own function
> gl_locale_name() can track the use of uselocale() to set a thread-local
> locale that overrides the global locale.  It has platform specific code
> for various platforms (glibc uses nl_langinfo(), BSD uses querylocale(),
> Sun uses getlocalename_l() - surprisingly none of the platforms use
> nl_langinfo_l()!), then falls back to probing the environment.  As long
> as cygwin lacked uselocale(), then probing the environment was correct.
> But now that cygwin supports uselocale(), the gnulib code needs to add a
> cygwin-specific clause to its list of various platform methods.
> 
> I'll propose a patch to upstream gnulib, and cc this list - any project
> using gnulib will have to backport that patch or wait for a new upstream
> release of that project that uses newer gnulib if it wants to work
> around the bug.

Thanks for letting us know!

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat