[ANNOUNCEMENT] Updated: openssl-1.0.2d-1
Hi folks, I've updated the version of OpenSSL to 1.0.2d-1. This is a security bugfix release. OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html Peace, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: tcsh-6.19.00-2
I've updated the tcsh package to 6.19.00-2. This package is ideentical to 6.19.00-1, except for a fix to the default completion for `ln'. For a description of the problem see https://cygwin.com/ml/cygwin/2015-07/msg00037.html This affects the file /etc/profile.d/complete.tcsh. If you changed it, the new file will not overwrite the old file. In this case, and if you're actually utilizing the tcsh completions, please copy over the new file manually like this: $ cp /etc/defaults/etc/profile.d/complete.tcsh /etc/profile.d/complete.tcsh Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SIGINT generated by Control-C, is not delivered in mintty
Ronald Fischer mm.st> writes: > Using Cygwin 64 on Windows 7: > > In a bash or zsh running inside mintty, pressing Control-C has no > effect. In a bash or zsh running in a Windows Console, it works fine. > > This can be verified in two ways: > > (1) Using 'trap': > > In the shell, we do a > > trap 'echo trapped' INT > > Now whenever we hit Control-C, we expect "trapped" to be printed on > stdout. This is not the case when the shell runs inside mintty. > > (2) Using 'cat': > > In the shell, we do a > > cat > > which has the effect that cat reads from stdin. A control-C should abort > it. Again, this doesn't work when we run inside mintty. WJFFM. Make sure that the stuff in GW (GNUwin?) and Linux64 does not interfer. Also, you have multiple cygwin1.dll on your path (p/nano), fix that and see if it makes any difference. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Norton Business Suite identifies minntty as malware
On 7/14/2015 5:21 AM, Brent wrote: On my work computer today, I ran cygwin's setup-x86_64.exe in order to get the latest and greatest code. Soon afterwards, Norton Business Suite autoran, and claimed that the new mintty is malware (to be precise: WS.Malware.2). This has never happened before: both Norton and cygwin (including mintty) have been on my computer for a long time. I assume that mintty has not gotten infected with malware, and that this is probably a Norton bug, like what has been seen in the past: https://cygwin.com/faq/faq.html#faq.using.bloda https://sourceware.org/ml/cygwin/2013-11/msg00205.html That said, I thought that I would report it anyways. Details: --Win 7 64 bit pro host --Norton Business Suite version 21.7.0.11 --latest cygwin and mintty (version 2.0.3-0) --I have screenshots if anyone wants more details, but I cannot send them as attachments to this mailing list, right? Hi Brenat, please open a false positive report with Norton Likely they will recognize the mistake and amend their database Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin "cp" changes ACLs on files accessed via CIFS
- Original Message - > From: "Andrey Repin" > To: "Andrew Martin" , cygwin@cygwin.com > Sent: Wednesday, June 24, 2015 8:52:55 PM > Subject: Re: Cygwin "cp" changes ACLs on files accessed via CIFS > > Greetings, Andrew Martin! > > > Performing the same operation from Windows Explorer or using the GnuWin32 > > version of cp preserves the correct permissions. Has anyone observed this > > incorrect behavior when using cygwin cp, or do you have any ideas on how to > > fix > > this problem? I have also tried "cp -p" as well as "cp --no-preserve=all" > > but > > the problem still exists. > > If you're not using Cygwin's 'noacl' mount flag for your NFS's, this is to be > expected. > You can force that flag for all directories outside Cygwin root by > /etc/fstab: > > none /cygdrive cygdrive noacl,binary,posix=0 0 0 > > Hi Andrey, Thanks for this helpful response - I added noacl to /etc/fstab and now cygwin's "cp" is working as expected on the share! Thanks again, Andrew -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: whois-5.2.9-1
The whois package has been updated to the latest upstream release 5.2.9. The change log can be found here: https://raw.github.com/rfc1036/whois/master/debian/changelog More information about whois can be found at https://github.com/rfc1036/whois DESCRIPTION: whois searches for an object in a RFC 3912 database. QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- David Rothenberger daver...@acm.org Aren't you glad you're not getting all the government you pay for now? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
On 7/3/2015 9:09 AM, Ken Brown wrote:
On 7/3/2015 6:47 AM, Corinna Vinschen wrote:
On Jul 2 15:25, Ken Brown wrote:
On 7/2/2015 8:20 AM, Corinna Vinschen wrote:
On Jul 2 14:13, Corinna Vinschen wrote:
On Jul 1 22:10, Ken Brown wrote:
I may have spoken too soon. As I repeat the experiment on a
different
computer, with a build from a slightly different snapshot of the
emacs
trunk, emacs crashes when I type 'C-x d' with the following stack
dump:
Stack trace:
FrameFunctionArgs
00100A3E240 00180071CC3 (0829630, 08296D0, 000,
082CE00)
0003002 001800732BE (000, 002, 00100A48C80,
002)
000 0006B40 (002, 00100A48C80, 002,
00100A48768)
000 213 (002, 00100A48C80, 002,
00100A48768)
End of stack trace
$ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg
/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175
$ addr2line 001800732BE -e /usr/lib/debug/usr/bin/cygwin1.dbg
/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exceptions.cc:1639
That points to a crash while setting up the alternate stack. This is
always a possibility because, in contrast to the kernel signal handler
in a real POSIX system, the Cygwin exception handler is still
running on
the stack which triggered the crash up to the point where we call the
signal handler function. Dependent on how the stack overflow occured,
this additional stack usage may be enough to kill the process for
good.
Out of curiosity, can you add this to the init_sigsegv() function:
#include
[...]
init_sigsegv (void)
{
[...]
SetThreadStackGuarantee (65536);
Of course this only works "per thread", so if init_sigsegv is called
for the main thread, only the main thread gets this treatment. For
testing this should be enough, though.
That didn't make any difference.
It should have. If you don't also tweak STACK_DANGER_ZONE accordingly,
handle_sigsegv should fail to call siglongjmp. Either way, I tested
it locally as well, and it doesn't work.
In the meantime I found that there's another problem. Assuming you
longjmp out of handle_sigsegv, the stack will still be "broken".
It doesn't have the usual guard pages anymore, and the next time
you have a stack overflow, NTDLL will simply terminate the process.
I create a wrapper function which resets the stack so it has valid guard
pages again and then the stack overflow can be handled repeatedly.
While I was at it, I found that the setup for pthread stacks is not
quite right, either, so right now I'm hacking on this stuff to make
it behave as expected in the usual cases.
But I do have a little more information.
I tried running emacs under gdb with a breakpoint at handle_sigsegv.
The
breakpoint is hit when I deliberately trigger the stack overflow.
Then I
continue, emacs says it has recovered from the stack overflow, and I
type
'C-x d'. At this point there's a second SIGSEGV and handle_sigsegv is
called again. But this time garbage collection is in progress, and
handle_sigsegv just gives up.
Sounds right to me.
I don't know what caused the second SIGSEGV but I'll try to figure
that out
when I next have a chance to look at this. I also don't know why the
stack
dump pointed to a crash while setting up the alternate stack, since the
fatal crash actually seems to have happened later. But maybe the
stack was
just completely messed up after the second SIGSEGV and the stack dump
can't
be trusted.
I think I found the cause of that second SIGSEGV, and, if I'm right, it
has nothing to do with Cygwin. I think the problem was that in my
testing, I forgot to reset max-specpdl-size and max-lisp-eval-depth to
reasonable values after the recovery from stack overflow. If I do that,
then I can no longer reproduce the crash.
Just for the sake of the archives, it turned out that I could reproduce
that second crash after all. But it was an emacs bug, which has now
been fixed:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20996
So there are no loose ends; everything I know how to test involving the
alternate stack works.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
Hi Ken, On Jul 14 15:09, Ken Brown wrote: > On 7/3/2015 9:09 AM, Ken Brown wrote: > >I think I found the cause of that second SIGSEGV, and, if I'm right, it > >has nothing to do with Cygwin. I think the problem was that in my > >testing, I forgot to reset max-specpdl-size and max-lisp-eval-depth to > >reasonable values after the recovery from stack overflow. If I do that, > >then I can no longer reproduce the crash. > > Just for the sake of the archives, it turned out that I could reproduce that > second crash after all. But it was an emacs bug, which has now been fixed: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20996 > > So there are no loose ends; everything I know how to test involving the > alternate stack works. Nice to know, thanks a lot. I'm planning to release 2.1.0 tomorrow if nothing gets in the way. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp36v2pEmqm9.pgp Description: PGP signature
Re: Return codes over 1 byte
On 07/09/2015 05:30 PM, Michael DePaulo wrote: > mark06 mentioned this on IRC today and then left the channel about 1 hour > later: > > has anyone ever discussed exit codes above one byte? they are > valid on modern windows, but cygwin's bash will mess them POSIX requires that all sizeof(int) bytes in exit() be visible to calling apps that use waitid(); however, while Solaris has implemented this, Linux has not (Linux intentionally truncates exit() values to 1 byte before storing it in the kernel task information, so later waitid() has no way to reconstruct the three truncated bytes). Since Cygwin is emulating Linux, we can also get by with truncating exit status to one byte, although it would be nice for POSIX reasons to eventually reach the point where waitid() can return all four bytes. > mike@executor ~ > $ ./return.exe > > mike@executor ~ > $ echo $? > 0 Most shells (bash included) are NOT using waitid() internally, but are still sticking to the older wait() and waitpid() interfaces. Per POSIX, those older interfaces MUST truncate the exit status into just 8 bits, because it is being combined with other pieces of information (hence the WIFEXITED() macro and friends). It is only waitid() that can return more than 8 bits, but that in turn requires the kernel to track more than 8 bits. And therein lies a bootstrap problem: since Linux doesn't yet track more than 8 bits in the kernel, most open source shell authors have no incentive to try and use newer interfaces; but until someone actively complains that the newer interfaces are not following POSIX, the kernel authors have no incentive to change the kernel process information. And even if shell authors did switch to waitid(), current POSIX is vague enough to state that a shell's $? will reflect only the lower 8 bits even if the shell were wired to use waitid() internally - that is, there is no requirement that exit(256) be mapped to a non-zero $? rather than the normal 0 you'd get from 8-bit truncation (although there has at least been a discussion of whether a future version of POSIX should add extensions to the shell to expose full 32-bit exit information [1]). [1] http://thread.gmane.org/gmane.comp.standards.posix.austin.general/11060 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Norton Business Suite identifies minntty as malware
On 7/14/2015 11:56 AM, Marco Atzeri wrote: On 7/14/2015 5:21 AM, Brent wrote: Hi Brenat, please open a false positive report with Norton Likely they will recognize the mistake and amend their database Regards Marco As Symantec Endpoint Protection had the same problem I opened a false positive report. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: TEST RELEASE: Cygwin 2.1.0-0.4
On 07/08/2015 01:39 PM, Warren Young wrote: >> - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, >> SS_DISABLE, >> MINSIGSTKSZ, SIGSTKSZ. > > Since these were entirely missing before, this can’t be tested without > rebuilding software, right? When rebuilt, existing Cygwin packages may > discover the new APIs via autoconf or similar. > > A search for "sigaltstack” on code.openhub.net found only 95 projects with > this string in their source code, almost entirely consisting of *receivers* > of that call, such as NetBSD, glibc, and a bunch of Linux forks. > libsigsegv is a cygwin package (currently 32-bit only) that has configure checks to use sigaltstack if present; I have not yet tested if it can be configured to work with the new API, but hope to do so in the near future. In fact, if sigaltstack works, it may finally be possible to port libsigsegv to 64-bit cygwin (the reason the current package is not ported to 64-bit is that libsigsegv is relying on raw assembly and Windows native calls to emulate the lack of sigaltstack; but if sigaltstack works, then we don't need to port the 64-bit counterpart for the 32-bit specific hacks). I'm not the cygwin packager for libsigsegv, but am one of the upstream contributors, and so this thread has piqued my interest. Sadly, I'm a bit late to the testing because I was on vacation last month, and am now trying to catch up with several things that happened during my (much-needed) downtime, such as a new upstream release of coreutils. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
ACL Hell
Hi, in the past several months or so, cygwin started giving me ACL pain in small surges which are gradually growing.. Here's a basic scenario that is slowly, but surely, driving me NUTZ: $ ln -s /cygdrive/c/tmp /tmp ln: failed to create symbolic link ‘/tmp’: Operation not permitted Some other examples (it doesn't matter which is the current working dir): $ touch x $ ls -l x -rw-rwxr--+ 1 sky None 0 Jul 15 00:46 x* $ getfacl x # file: x # owner: sky # group: None user::rw- group::r-- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:r-- $ ln -s x y ln: failed to create symbolic link ‘y’: Operation not permitted This didn't use to be like that. Cygwin's directory itself seems to be ok: $ ls -ld cygwin drwxrwx---+ 1 sky None 0 Jul 15 00:19 cygwin/ $ getfacl cygwin/ # file: cygwin/ # owner: sky # group: None user::rwx group::--- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::rwx default:user:sky:rwx default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- I found a thread that shows how to remove ACL... Avec Plaisir! I replaced the line in /etc/fstab with this one: none /cygdrive cygdrive binary,noacl,posix=0,user 0 0 Closed all cygwin terminals, reopened and issue: $ getfacl cygwin/ # file: cygwin/ # owner: sky # group: None user::rwx group::r-x other:r-x Much better for all I care. However, this didn't change anything. Touching x and linking y yielded the exact same results as above. Here's my cygwin details: $ uname -a CYGWIN_NT-6.3-WOW sky-pc 2.0.2(0.287/5/3) 2015-05-08 17:03 i686 Cygwin Looking at cygwin via Properties -> Security tab, the user (sky) is the owner of the directory and has Full Control (recursively). My main goal is not to get stuck on trivialities like soft linking of file creation. But what I would really like is to get rid of ACL altogether (towards that end I'll mention that I switched UAC off long time ago). I don't care about security, I just want to work and this is holding me back both at home and at my work place. Please.. Help... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
On 06/27/2015 08:52 AM, Corinna Vinschen wrote: > The problem is probably that there are still resources in use which > didn't get free'd. I'll check next week if I can do anything about it. > Ideally with a simple testcase than emacs :} Is libsigsegv an appropriate testcase? There are several other applications that then optionally use libsigsegv for stack overflow protection (such as m4 and awk), as well as for user-managed page faulting for garbage collection purposes (such as guile). In fact, I'm a bit surprised that emacs rolls its own protection instead of taking advantage of libsigsegv - it might be worth suggesting that to upstream emacs. Upstream libsigsegv comes with a fairly decent testsuite for low-level testing of what types of SIGSEGV handling is possible (regardless of whether that recovery was done by native windows hacks as in the current build, or via sigaltstack which is what I hope will happen when it is reconfigured against the new cygwin). And if those tests aren't enough it is also a fairly simple test case using (32-bit) m4 (when linked against a rebuilt libsigsegv) to do: echo 'define(a,a(a))a' | m4 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: ACL Hell
On Tue, Jul 14, 2015 at 5:15 PM, Sky Diver wrote: > $ touch x > > $ ls -l x > -rw-rwxr--+ 1 sky None 0 Jul 15 00:46 x* > > $ ln -s x y > ln: failed to create symbolic link ‘y’: Operation not permitted I just tried this on a pristine Windows 7 64-bit virtual machine without issue. You might want to check your system. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: TEST RELEASE: Cygwin 2.1.0-0.4
On 7/14/2015 6:03 PM, Eric Blake wrote: On 07/08/2015 01:39 PM, Warren Young wrote: - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE, MINSIGSTKSZ, SIGSTKSZ. Since these were entirely missing before, this can’t be tested without rebuilding software, right? When rebuilt, existing Cygwin packages may discover the new APIs via autoconf or similar. A search for "sigaltstack” on code.openhub.net found only 95 projects with this string in their source code, almost entirely consisting of *receivers* of that call, such as NetBSD, glibc, and a bunch of Linux forks. libsigsegv is a cygwin package (currently 32-bit only) that has configure checks to use sigaltstack if present; I have not yet tested if it can be configured to work with the new API, but hope to do so in the near future. In fact, if sigaltstack works, it may finally be possible to port libsigsegv to 64-bit cygwin (the reason the current package is not ported to 64-bit is that libsigsegv is relying on raw assembly and Windows native calls to emulate the lack of sigaltstack; but if sigaltstack works, then we don't need to port the 64-bit counterpart for the 32-bit specific hacks). I just did a quick test, and it looks promising. I removed all Cygwin-specific code from configure.ac and Makefile.am (see attached patch), and it then built on 64-bit Cygwin. Here's the result of 'make check': Entering directory '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests' Test passed. PASS: sigsegv1.exe Test passed. PASS: sigsegv2.exe Doing SIGSEGV pass 1. Stack overflow 1 caught. Doing SIGSEGV pass 2. Stack overflow 2 caught. Test passed. PASS: sigsegv3.exe SKIP: stackoverflow1.exe SKIP: stackoverflow2.exe == All 3 tests passed (2 tests were not run) == [...] Please send the following summary line via email to the main author Bruno Haible for inclusion into the list of successfully tested platforms (see PORTING file). libsigsegv: x86_64-unknown-cygwin | yes | no | 2.10 I'm not the cygwin packager for libsigsegv, No one is; it's orphaned. but am one of the upstream contributors, and so this thread has piqued my interest. So it seems that you would be the obvious person to maintain it, if you have the time. If you don't have the time, I'd be willing to ITA it just to get it into the 64-bit distro. But in that case I'd appreciate it if you would review my build after I send the ITA, since you actually know something about libsigsegv, and I don't. Sadly, I'm a bit late to the testing because I was on vacation last month, and am now trying to catch up with several things that happened during my (much-needed) downtime, such as a new upstream release of coreutils. Ken --- origsrc/libsigsegv-2.10/configure.ac2015-07-14 20:32:45.036228200 -0400 +++ src/libsigsegv-2.10/configure.ac2015-07-14 20:42:36.489057300 -0400 @@ -522,19 +522,6 @@ case "$host_os" in FAULT_CONTEXT_INCLUDE='#include ' CFG_FAULT=fault-win32.h # nonexistent, just a dummy ;; - cygwin*) -FAULT_CONTEXT='struct _CONTEXT' -# CONTEXT is defined in , but cygwin programs should not -# normally inspect the contents of CONTEXT, and the outright inclusion -# of pollutes the namespace. -FAULT_CONTEXT_INCLUDE='struct _CONTEXT;' -# Cygwin 1.7 uses fault-posix.h. Cygwin 1.5.x needs a hacky workaround. -if test -z "$CFG_FAULT"; then - CFG_FAULT=fault-cygwin-old.h - AC_DEFINE([OLD_CYGWIN_WORKAROUND], [1], -[Define to 1 on Cygwin versions older than 1.7.]) -fi -;; esac if test -n "$CFG_FAULT"; then sv_cv_have_sigsegv_recovery=yes @@ -861,7 +848,7 @@ AC_CACHE_CHECK([if the system supports c sv_cv_have_stack_overflow_recovery=yes else case "$host_os" in - mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;; + mingw*) sv_cv_have_stack_overflow_recovery=yes ;; *) if test "$CFG_LEAVE" != 'leave-none.c'; then if test "$sv_cv_sigaltstack" != no; then @@ -930,7 +917,7 @@ dnl Requires AC_CANONICAL_HOST, CFG_HAND dnl HAVE_SIGSEGV_RECOVERY, HAVE_STACK_OVERFLOW_RECOVERY. case "$host_os" in - mingw* | cygwin*) CFG_HANDLER=handler-win32.c ;; + mingw*) CFG_HANDLER=handler-win32.c ;; *) if test -z "$CFG_HANDLER"; then if test $sv_cv_have_sigsegv_recovery = no \ @@ -961,7 +948,6 @@ dnl should make the system call fail wit dnl the signal handler. dnl It is necessary on Cygwin: otherwise the cygwin1 test fails. case "$host_os" in - cygwin*) enable_EFAULT=yes ;; *) enable_EFAULT=no ;; esac if test $enable_EFAULT = yes; then --- origsrc/libsigsegv-2.10/tests/Makefile.am 2010-10-24 13:25:15.0 -0400 +++ src/libsigsegv-2.10/tests/Makefile.am 2015-07-14 21:37:25.864937900 -0400 @@ -29,11 +29,6 @@ DEFS = @DEFS@ LDADD = ../src/libsigsegv.la noinst_PROGRAMS = sigsegv1 sigsegv2 sigsegv3 stackoverflow1 stackoverflow2 -if CY
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
On 7/14/2015 6:18 PM, Eric Blake wrote: In fact, I'm a bit surprised that emacs rolls its own protection instead of taking advantage of libsigsegv - it might be worth suggesting that to upstream emacs. Good idea. I'll do that. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
