[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Corinna Vinschen]

Hi Cygwin friends and users,


I released TEST version 2.4.0-0.11 of Cygwin.

So 0.10 was *not* the last test release...

Anyway, compared to 0.10 there's only a single change:

- Fix a potential crash reading invalid passwd and group entries from
  /etc/passwd and /etc/group.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html

Since 0.10 was such a short-lived release, here's the list of changes
from 0.9 to 0.10 again:

- 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.

- A potential locking problem has been fixed in newlib, which may affect
  fclose and freopen calls under FSETLOCKING_BYCALLER conditions.

- Another potential deadlock problem has been fixed which could 
  occur in atexit handling under low memory conditions.

- A new mount type "usertemp" has been introduced, which allows to mount
  a POSIX directory to the Windows per-user temporary directory:

    none /tmp usertemp binary,posix=0 0 0


======================================================================

Due to the imminent holiday schedule, I postponed the official release
of Cygwin 2.4.0 to early 2016.

Testing is still highly appreciated...

======================================================================
 

This is the "new POSIX ACL handling reloaded" release.

In local testing I successfully integrated AuthZ into the current Cygwin
code to generate more correct user permissions by being able to generate
effective permissions for arbitrary users.

This success convinced me that it might be possible to pick up the POSIX
permission rewrite originally targeted for the 2.0.0 release and try to
update it using AuthZ and generally revamp it to reflect effective
permissions better.

My local testing looks good, but this is a major change, so this code
really needs a lot more testing in various scenarios.  Especially
some Windows ACLs created in corporate environments are often a hard
nut to crack, and the example from

https://cygwin.com/ml/cygwin/2015-04/msg00513.html

which was the ultimate downfall of the original implementation is
the stuff which needs some good testing.

There's, as usual, a downside: AuthZ leans a bit to the slow side.
Cygwin caches information already gathered once on a per-process basis,
but in locally crafted worst case scenarios (`ls' on lots of file owned
by lots of different users and groups) the slowdown may be up to 25%.
But that's really just a worst case, in the usual scenarios the slowdown
should be mostly unnoticable.

To alleviate the problem, the AuthZ code is fortunately only called for
non-Cygwin ACLs and Cygwin ACLs created before this release.  Within a
pure Cygwin environment (e.g., some build directory only used with
Cygwin tools) AuthZ should be practically unused.

Apart from the aforementioned code changes to "just do it right", there
are two additional changes I implemented for this new POSIX ACL revamp
release:

- I reverted the questionable change I added to 2.0.0-0.7 in terms of
  chmod group permission handling.  The original description of this
  change was:

    If you have a non-trivial ACL with secondary accounts and thus a
    mask value, chmod is supposed to change only the mask, not the
    permissions of the primary group.  However, if the primary group has
    few permissions to begin with, the result is really surprising.  ls
    -l would, e.g., show read/write perms for the group, but the group
    might still have only read perms.

    Personally I find this chmod behaviour really, really bad, so I took
    the liberty to change it in a way which gives a much less surprising
    result:  If you call chmod on a non-trivial ACL, the group
    permissions will be used for the primary group and the mask.

- setfacl(1) now accepts the combination of the -b and -k options, just as
  on Linux.

As for the description what this implementation strives for, please see
http://linux.die.net/man/5/acl

============================================================================

What's new:
-----------

- New, unified implementation of POSIX permission and ACL handling.  The
  new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and
  they allow to inherit the S_ISGID bit.  ACL inheritance now really
  works as desired, in a limited, but theoretically equivalent fashion
  even for non-Cygwin processes.

  To accommodate standard Windows ACLs, the POSIX permissions of the
  owner and all other users in the ACL are computed using the Windows
  AuthZ API.  This may slow down the computation of POSIX permissions
  noticably in some circumstances, but is generally more correct.  The
  new code also ignores SYSTEM and Administrators group permissions when
  computing the MASK/CLASS_OBJ permission mask on old ACLs, and it
  doesn't deny access to SYSTEM and Administrators group based on the
  value of MASK/CLASS_OBJ when creating the new ACLs.

  The new code now handles the S_ISGID bit on directories as on Linux:
  Setting S_ISGID on a directory causes new files and subdirs created
  within to inherit its group, rather than the primary group of the user
  who created the file.  This only works for files and directories
  created by Cygwin processes.

- New mount type "usertemp" which allows to mount a POSIX directory to
  the Windows per-user temporary directory.

- cygpath has a new -U option, which creates cygdrive paths using the
  unambiguous /proc/cygdrive prefix.

- New API: rpmatch.


What changed:
-------------

- setfacl(1) now allows to use the -b and -k option combined to allow reducing
  an ACL to only reflect standard POSIX permissions.

- Fix (numeric and monetary) decimal point and thousands separator in
  fa_IR and ps_AF locales to be aligned with Linux.


Bug Fixes
---------

- Not a bug fix as such, but a workaround for new behaviour in Windows 10
  version 1511 64 bit.  This version introduces a problem which existed in
  a similar variation (just vice versa) in XP and Server 2003 64 bit as well.
  An unexpected stack arrangement when starting a 64 bit Cygwin application
  from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00003.html

- Replaced old, buggy strtold implementation with well-tested gdtoa version
  from David M. Gay.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00205.html

- Fix handling of relative paths in native symlinks if the target is in a
  drive's root dir or one level below.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00277.html

- Fix a SEGV when calling `kill -l 0'.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00430.html

- Fix a race condition in signal handling.
  Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00387.html

- Fix a potential crash reading invalid passwd and group entries from
  /etc/passwd and /etc/group.
  Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html

============================================================================


Have fun,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Ismail Donmez]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> 
> Hi Cygwin friends and users,
> 
> I released TEST version 2.4.0-0.11 of Cygwin.
> 
> So 0.10 was *not* the last test release...
> 
> Anyway, compared to 0.10 there's only a single change:
> 
> - Fix a potential crash reading invalid passwd and group entries from
>   /etc/passwd and /etc/group.
>   Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00170.html

Works beautifully on Win 10 x64 10586.29.

Regards,
ismail



--
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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Ken Brown]

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]

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

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.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Ken Brown]

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.

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

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 :(


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Ken Brown]

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

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?
> 
> 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?

I'll raise this on the gnulib list, and we can come up with workarounds.
 But bypassing gnulib's sys/select.h probably won't work in general
(gnulib tends to always provide wrapper headers that use #include_next
to the system header, even if nothing is replaced, because it is easier
than trying to figure out when a wrapper header is needed).  Of course,
fixing it in gnulib won't help the myriad of projects that will be
bitten by this until they do a new release based on updated gnulib, so
maybe we can also find a way to make cygwin play nice without a gnulib
update required.  I'm still investigating.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.11

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]