On Dec 17 14:40, Eric Blake wrote: > On 12/17/2015 02:16 PM, Eric Blake wrote: > > On 12/17/2015 02:01 PM, Corinna Vinschen wrote: > > > >>> 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. > > > > Gnulib has been taught to work around early inclusion problems before; > > sounds like this will be another case where gnulib has to make sure the > > system header is complete before its own replacements kick in. > > > >>> > >>> 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? > > Another data point: POSIX does NOT allow <sys/types.h> to pollute the > namespace with symbols from <sys/select.h>. True, the use of > __BSD_VISIBLE says that POSIX is not in play, but I'm suspecting that > very few programs are written that use sys/select.h functionality but > were relying on the BSD headers to indirectly include it via > sys/types.h, since such programs would fail to compile on other systems > where the indirect include is not present (more likely, any clients of > sys/select.h are directly including it). > > So at this point, I'm leaning towards fixing the cygwin header to not > include sys/select.h from sys/types.h.
I agree. I reverted this part of the patch, despite being compatible with some of the BSDs. It very obviously breaks backward compat. I'm just building new developer snapshots (give them half an hour) and I'll upload a new cygwin test release probably tomorrow. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp5g2FIqXY3B.pgp
Description: PGP signature
