Re: Error: unknown type name ‘pthread_attr_t’ in signal.h

[Jeffrey Walton <noloader@gmail.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