From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11
Date: Thu, 17 Dec 2015 20:39:00 -0000 [thread overview]
Message-ID: <56731D8C.9020001@cornell.edu> (raw)
In-Reply-To: <20151217201709.GA28305@calimero.vinschen.de>
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 <signal.h>
>>> 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 <sys/select.h>'
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
next prev parent reply other threads:[~2015-12-17 20:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 16:48 Corinna Vinschen
2015-12-16 18:25 ` Ismail Donmez
2015-12-16 23:13 ` Ken Brown
2015-12-17 9:36 ` Corinna Vinschen
2015-12-17 18:47 ` Ken Brown
2015-12-17 20:17 ` Corinna Vinschen
2015-12-17 20:39 ` Ken Brown [this message]
2015-12-17 21:01 ` Corinna Vinschen
2015-12-17 21:16 ` Eric Blake
2015-12-17 21:41 ` Eric Blake
2015-12-17 21:56 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56731D8C.9020001@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).