From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19848 invoked by alias); 15 Oct 2013 21:14:08 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 19825 invoked by uid 89); 15 Oct 2013 21:14:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_NEUTRAL autolearn=ham version=3.3.2 X-HELO: bureau85.ns.utoronto.ca Received: from bureau85.ns.utoronto.ca (HELO bureau85.ns.utoronto.ca) (128.100.132.185) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 15 Oct 2013 21:14:06 +0000 Received: from [192.168.1.111] (184-175-18-108.dsl.teksavvy.com [184.175.18.108] (may be forged)) (authenticated bits=0) by bureau85.ns.utoronto.ca (8.13.8/8.13.8) with ESMTP id r9FLE0TF003146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Oct 2013 17:14:01 -0400 Message-ID: <525DB015.1010707@cs.utoronto.ca> Date: Tue, 15 Oct 2013 21:14:00 -0000 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: siginfo_t missing member si_band References: <525D55B3.3050002@cs.utoronto.ca> <20131015194242.GA2368@ednor.casa.cgf.cx> In-Reply-To: <20131015194242.GA2368@ednor.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00211.txt.bz2 On 15/10/2013 3:42 PM, Christopher Faylor wrote: > On Tue, Oct 15, 2013 at 10:48:19AM -0400, Ryan Johnson wrote: >> Hi all, >> >> While trying to build python3 for cygwin, I kept encountering the >> following error message: >> >> ./Modules/signalmodule.c: In function ?fill_siginfo?: >> ./Modules/signalmodule.c:745:60: error: ?siginfo_t? has no member named >> ?si_band? >> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band)); >> ^ >> Include/tupleobject.h:62:75: note: in definition of macro >> ?PyTuple_SET_ITEM? >> #define PyTuple_SET_ITEM(op, i, v) (((PyTupleObject *)(op))->ob_item[i] >> = v) >> ^ >> ./Modules/signalmodule.c:745:5: note: in expansion of macro >> ?PyStructSequence_SET_ITEM? >> PyStructSequence_SET_ITEM(result, 6, PyLong_FromLong(si->si_band)); >> >> As far as I can tell, siginfo_t::si_band is mandated by POSIX.1-2001, >> and required for proper handling of SIGPOLL. The latter seems to >> correspond to async I/O with poll(2). I'm pretty sure cygwin doesn't >> support async I/O, but shouldn't the struct member at least exist, to >> avoid breaking code that assumes its existence? The alternative is to >> patch python3 locally so its os.sigwaitinfo function no longer touches >> si_band, or to file a bug upstream so that the module's configury tests >> for its existence before using it. >> >> Thoughts? > Sure. I question the utility of lying in a structure about the > availability of an unimplemented feature. If something is specifically > expecting the structure member to exist it seems like it would be > expecting it to do something. So that would be a vote for filing a bug upstream with python's FFI interface to signal handling? Fair enough. Ryan -- 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