From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-046.btinternet.com (mailomta23-re.btinternet.com [213.120.69.116]) by sourceware.org (Postfix) with ESMTPS id 0C3F53857C63 for ; Mon, 26 Apr 2021 12:01:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0C3F53857C63 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from re-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.54.5]) by re-prd-fep-046.btinternet.com with ESMTP id <20210426120102.PYUI3547.re-prd-fep-046.btinternet.com@re-prd-rgout-002.btmx-prd.synchronoss.net> for ; Mon, 26 Apr 2021 13:01:02 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-SNCR-Rigid: 5ED9C0CC306E932D X-Originating-IP: [81.153.98.246] X-OWM-Source-IP: 81.153.98.246 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduledrvddukedggeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepteejfffhheeuleeufeeiueduveeltdeiveejuddvgfegjeeuheefgeffgeffheefnecuffhomhgrihhnpegthihgfihinhdrtghomhenucfkphepkedurdduheefrdelkedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrudduudgnpdhinhgvthepkedurdduheefrdelkedrvdegiedpmhgrihhlfhhrohhmpeeojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhequceuqfffjgepkeeukffvoffkoffgpdhrtghpthhtohepoegthihgfihinhdqrghpphhssegthihgfihinhdrtghomheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (81.153.98.246) by re-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9C0CC306E932D for cygwin-apps@cygwin.com; Mon, 26 Apr 2021 13:01:02 +0100 Subject: Re: setup 2.906 release candidate - please test To: "cygwin-apps@cygwin.com" References: <0d8d39fd-0bf0-225a-6963-1fa94a2f5037@dronecode.org.uk> From: Jon Turney Message-ID: Date: Mon, 26 Apr 2021 13:00:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3571.0 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_EXEURI, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 12:01:09 -0000 On 17/03/2021 20:08, Jon Turney wrote: > On 17/03/2021 20:02, Jon Turney wrote: >> >> A new setup release candidate is available at: >> >>    https://cygwin.com/setup/setup-2.906.x86_64.exe (64 bit version) >>    https://cygwin.com/setup/setup-2.906.x86.exe    (32 bit version) >> >> Please test, and report any problems here. >> >> This is not the place for setup feature requests. > > Pretty late in preparing this release, I discovered that in Fedora 33, > the MinGW-w64 32-bit compiler has been changed from sjlj to dwarf2 > unwinding C++ exception handling. > > I believe this means that exceptions cannot propagate up through Windows > code, so the release needs to be delayed until the source code has been > inspected to see if there's any place where e.g. we throw an exception > from a Windows callback, but I'd like to get this out for some testing > already. I think that this does effect some error cases, where we throw an error and expect it to get propagated through a callback. So for the moment, I've added a configure time check that the x86 compiler is configured with sjlj exceptions, and dropped back to building on Fedora 32. Long term, I'm not sure what the best approach is. Using -fno-exceptions and adjusting the code not to use exceptions would be a start, but that just leaves us silently exiting if an exception is thrown from libstdc++...