From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112400 invoked by alias); 17 Dec 2015 20:39:41 -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 112391 invoked by uid 89); 17 Dec 2015 20:39:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=puzzled, belonged, encounter, H*f:sk:5673035 X-HELO: limerock04.mail.cornell.edu Received: from limerock04.mail.cornell.edu (HELO limerock04.mail.cornell.edu) (128.84.13.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Dec 2015 20:39:39 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id tBHKdb1R019230 for ; Thu, 17 Dec 2015 15:39:37 -0500 Received: from [192.168.1.7] (cpe-67-249-176-138.twcny.res.rr.com [67.249.176.138]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id tBHKdaKS010491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 17 Dec 2015 15:39:37 -0500 Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11 To: cygwin@cygwin.com References: <20151216164848.GM3507@calimero.vinschen.de> <5671EFF8.6030804@cornell.edu> <20151217093634.GP3507@calimero.vinschen.de> <56730350.1080002@cornell.edu> <20151217201709.GA28305@calimero.vinschen.de> From: Ken Brown Message-ID: <56731D8C.9020001@cornell.edu> Date: Thu, 17 Dec 2015 20:39:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151217201709.GA28305@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00195.txt.bz2 On 12/17/2015 3:17 PM, Corinna Vinschen wrote: > On Dec 17 13:47, Ken Brown wrote: >> Hi Corinna, >> >> On 12/17/2015 4:36 AM, Corinna Vinschen wrote: >>> Hi Ken, >>> >>> On Dec 16 18:12, Ken Brown wrote: >>>> On 12/16/2015 11:48 AM, Corinna Vinschen wrote: >>>>> - The header file layout has been cleaned up, mostly in terms of the >>>>> sys/select.h, sys/signal.h and sys/types.h files. This is a generic >>>>> change in newlib and aligns the affected headers more closely to >>>>> the FreeBSD layout. >>>> >>>> These changes are leading to lots of errors when building emacs: >>>> >>>> /usr/include/cygwin/signal.h:178:3: error: unknown type name ‘pthread_attr_t’ >>>> >>>> /usr/include/cygwin/signal.h:213:3: error: unknown type name ‘pid_t’ >>>> >>>> /usr/include/cygwin/signal.h:230:2: error: unknown type name ‘timer_t’ >>>> >>>> /usr/include/sys/signal.h:211:6: error: #error You need the winsup sources or a cygwin installation to compile the cygwin version of newlib. >>>> >>>> /usr/include/sys/signal.h:214:5: error: unknown type name ‘pthread_t’ >>>> >>>> /usr/include/sys/time.h:104:34: error: unknown type name ‘u_int’ >>>> >>>> [... and many more] >>> >>> This puzzles me. It looks like you're missing sys/types.h when >>> including sys/signal,h, but sys/signal.h includes sys/types.h by >>> itself, prior to including cygwin/signal.h. >>> >>> How can I reproduce this? An STC like this: >>> >>> #include >>> main () {} >>> >>> is definitely not sufficient. >> >> Sorry, I hadn't looked at what was happening closely enough before sending >> my mail. The errors occur while compiling some Gnulib modules in the emacs >> source tree. It may take me a while to sort this out. Maybe Gnulib will >> have to be patched to take Cygwin's new header layout into account. > > I'm still puzzled. The changes, especially to sys/signal.h and > cygwin/signal.h are rather minor. The really big thing is to move the > macros related to select(2) from sys/types.h, where they never really > belonged to, into sys/select.h, rather than including sys/types.h from > sys/select.h. Especially the changes to sys/signal.h and cygwin/signal.h > don't really add up to the error messages you encounter. I inspected > the files today and I really don't see how this could happen :( Here's what happens: One of the Gnulib modules includes sys/types.h, which includes sys/select.h because of the recent changes. This brings in Gnulib's sys/select.h, which includes signal.h. We then get the errors I posted because we haven't yet finished including sys/types.h. All the build errors disappear if I remove '#include ' from sys/types.h. You said above that the macros related to select don't really belong in sys/types.h. So why does the latter include sys/select.h? 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