This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Error: unknown type name ‘pthread_attr_t’ in signal.h
- From: Jeffrey Walton <noloader at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 16 Oct 2017 04:39:53 -0400
- Subject: Re: Error: unknown type name ‘pthread_attr_t’ in signal.h
- Authentication-results: sourceware.org; auth=none
- References: <CAH8yC8=eY+bFd=t_4-UKFk+JnfamzQspzxFVpRdVT571LjBERQ@mail.gmail.com>
- Reply-to: noloader at gmail dot com
On Mon, Oct 16, 2017 at 3:12 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> Hi Everyone,
>
> I'm trying to build Emacs on Cygwin. I use the platform as a test bed
> because of Newlib. Emacs is failing with:
>
> gcc -DHAVE_CONFIG_H -I. -I../lib -I../src -I../src
> -I/usr/local/include -DNDEBUG -pthread -D_XOPEN_SOURCE=600 -m64 -MT
> close-stream.o -MD -MP -MF .deps/close-stream.Tpo -c -o close-stream.o
> close-stream.c
> In file included from /usr/include/sys/signal.h:22:0,
> from /usr/include/signal.h:6,
> from ./signal.h:52,
> from ./sys/select.h:107,
> from /usr/include/sys/time.h:47,
> from ./sys/time.h:39,
> from ./sys/select.h:86,
> from /usr/include/sys/types.h:68,
> from ./sys/types.h:28,
> from ./fcntl.h:50,
> from binary-io.h:23,
> from binary-io.c:3:
> /usr/include/cygwin/signal.h:175:3: error: unknown type name ‘pthread_attr_t’
> pthread_attr_t *sigev_notify_attributes; /* notification attributes */
> ^~~~~~~~~~~~~~
>
> Examining /usr/include/cygwin/signal.h around 175, I see:
>
> typedef struct sigevent
> {
> sigval_t sigev_value; /* signal value */
> int sigev_signo; /* signal number */
> int sigev_notify; /* notification type */
> void (*sigev_notify_function) (sigval_t); /* notification function */
> pthread_attr_t *sigev_notify_attributes; /* notification attributes */
> } sigevent_t;
>
> But I don't see an include for the pthread gear in the signal.h header file.
>
> I found one past message that's similar
> (https://cygwin.com/ml/cygwin/2016-06/msg00458.html), but its reported
> as an upstream bug. I don't think it applies here since the pthread
> data structure is used without an apparent declaration.
>
> Can anyone confirm things are (not?) working as expected? If things
> are working as expected, then hints to work around the failure would
> be appreciated.
I think something is borked with the Cygwin headers. If I am parsing
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html
and https://cygwin.com/ml/cygwin/2006-01/msg00642.html correctly, it
should be sufficient to define _XOPEN_SOURCE to 600. From the section
"The _XOPEN_SOURCE Feature Test Macro":
Since this volume of IEEE Std 1003.1-2001 is aligned with the ISO C
standard, and since all functionality enabled by _POSIX_C_SOURCE set
equal to 200112L is enabled by _XOPEN_SOURCE set equal to 600, there
should be no need to define _POSIX_C_SOURCE if _XOPEN_SOURCE is so
defined. Therefore, if _XOPEN_SOURCE is set equal to 600 and
_POSIX_C_SOURCE is set equal to 200112L, the behavior is the same as
if only _XOPEN_SOURCE is defined and set equal to 600...
Perhaps the Cygwin FAQ should say something about the macros to enable
features. Right now, the only discussion relates to __CYGWIN__ and
_WIN32. Confer, "6.39. What preprocessor macros do I need to know
about?" in https://www.cygwin.com/faq.html . It seems like there's a
lot more macros we need to know about.
I would still appreciate some help in working around the compile failures.
Jeff
--
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