[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11
Corinna Vinschen
corinna-cygwin@cygwin.com
Thu Dec 17 21:01:00 GMT 2015
On Dec 17 15:39, Ken Brown wrote:
> 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?
Because it's done exactly the same way on FreeBSD and OpenBSD:
# if __BSD_VISIBLE
#include <sys/select.h>
[...]
Gnulib should allow to work with this to be portable. So why does gnulib
provide its own sys/select.h? Is it configurable?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20151217/2ca43ad5/attachment.sig>
More information about the Cygwin
mailing list