This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8
- From: Yaakov Selkowitz <yselkowitz at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 18 Mar 2016 18:29:20 -0500
- Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.8
- Authentication-results: sourceware.org; auth=none
- References: <announce dot 20160318203409 dot GA11113 at calimero dot vinschen dot de> <56EC6BDA dot 7050505 at cornell dot edu> <20160318214509 dot GD11113 at calimero dot vinschen dot de> <56EC8053 dot 40604 at cornell dot edu> <56EC89C2 dot 9010105 at cygwin dot com>
On 2016-03-18 18:05, Yaakov Selkowitz wrote:
On 2016-03-18 17:25, Ken Brown wrote:
On 3/18/2016 5:45 PM, Corinna Vinschen wrote:
On Mar 18 16:58, Ken Brown wrote:
On 3/18/2016 4:34 PM, Corinna Vinschen wrote:
I released a new Cygwin TEST version 2.5.0-0.8.
If things are not going very wrong, this is basically what you'll
get as 2.5.0-1 release. Please, please test and report regressions.
Does this release include Yaakov's overhaul of the feature test macros?
Sorry, I completely forgot to metion this in my release mail, which
is especially weird because I created this test release to allow testing
the new feature test macros in the first place. Sorry!
The problem I reported in
https://www.cygwin.com/ml/cygwin/2015-12/msg00183.html has reappeared.
It looks like your fix
(https://www.cygwin.com/ml/cygwin/2015-12/msg00199.html) got reverted.
The commit message for removing the include did not indicate what
prompted it. However, the include is necessary for BSD compatibility,
and other software fails to build without it.
I would look into emacs and see what feature test macro(s) they enable
on *Linux*, and use the same for Cygwin.
Might this be it?
There's some seriously hackish things going on in that file, some of
them Cygwin specific. As far as this is concerned, our headers should
be no different than glibc.
BTW, folks, I'm here to help deal with any fallout from these changes,
but this is going to be the first answer to such issues: others need to
stop making hackish, wrong, or outdated assumptions about Cygwin. Yes,
that means pushing some patches to undo this mistreatment, but nothing
new there. As of today's 2.5.0-0.8, it should only considered a bug in
our headers when something does not compile if and only if Cygwin is
treated identically to glibc.