On Mar 22 08:32, Ken Brown wrote:
> On 3/22/2016 5:30 AM, Corinna Vinschen wrote:
> >On Mar 21 10:13, Ken Brown wrote:
> >>On 3/21/2016 9:06 AM, Corinna Vinschen wrote:
> >>>Hi Ken,
> >>>
> >>>On Mar 21 08:05, Ken Brown wrote:
> >>>>On 3/20/2016 4:24 PM, Yaakov Selkowitz wrote:
> >>>>>On 2016-03-20 12:29, Ken Brown wrote:
> >>>>>>>>Never mind.  I just sent a report to bug-gnulib, so you can follow up
> >>>>>>>>there.
> >>>>>>
> >>>>>>http://lists.gnu.org/archive/html/bug-gnulib/2016-03/msg00054.html
> >>>>>>
> >>>>>>Please check what I wrote in response to Paul and correct any mistakes I
> >>>>>>might have made.
> >>>>>
> >>>>>Treating Cygwin just like glibc should generally be the solution.
> >>>>
> >>>>The problem is now fixed in upstream Gnulib.
> >>>
> >>>I just read the thread and it occured to me that this doesn't only
> >>>affect Cygwin, but all systems using newlib starting with the next
> >>>version of newlib.
> >>>
> >>>That reminds me that we have to bump newlib's version about now.
> >>>
> >>>Would you mind to follow up with that problem on bug-gnulib?  The test
> >>>should probably look like this, more or less:
> >>>
> >>>#!((defined __GLIBC__ \
> >>>     || (defined __NEWLIB__ \
> >>>     && ((__NEWLIB__ == 2 && __NEWLIB_MINOR__ >= 4) || __NEWLIB__ >= 3))) \
> >>>  && !defined __UCLIBC__)
> >>>
> >>>As for the actual version number to test I have to talk to Jeff if we
> >>>can change the version to 2.4 or at least 2.3.1.  2.4 would simplify the
> >>>test in gnulib, otherwise the test gets a bit more complicated.
> >>
> >>Sure, I'll follow up on bug-gnulib as soon as you settle on the version
> >>number.
> >
> >Thank you.  From the thread I take it the version number isn't that
> >important anymore?
> 
> That's right.

FYI, we bumped newlib to 2.4.0 anyway.


Corinna

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