[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.11

[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.11

[Yaakov Selkowitz]

Hi Cygwin friends and users,


Corinna just released a new Cygwin TEST version 2.5.0-0.11.

If things are not going very wrong, this is basically what you'll
get as 2.5.0-1 release (really, we mean it this time).  Please, please 
test and report regressions.

Refresh with the following changes:

- Declare BSD finite/isinf/isnan functions in <math.h>.

- The isinf/isinff/isinfl functions are now signed, returning -1 for 
negative infinity for compatibility with glibc.

- Update sysconf(3) for recent feature additions.

- Fix getconf(1) supported specifications on 64-bit.

- Applied feature test macros in <pthread.h> and <tar.h>.

- Added <cpio.h>.

- fexcept_t is now an integral type for source compatibility with glibc 
and other systems.

- Fixes for compiling with G++ 6.


User-visible changes compared to 2.4.1:


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

- Full set of POSIX.1e ACL API functions now implemented.
   New APIs: acl_add_perm, acl_calc_mask, acl_clear_perms, acl_copy_entry,
   acl_copy_ext, acl_copy_int, acl_create_entry, acl_delete_def_file,
   acl_delete_entry, acl_delete_perm, acl_dup, acl_free, acl_from_text,
   acl_get_entry, acl_get_fd, acl_get_file, acl_get_permset, 
acl_get_qualifier,
   acl_get_tag_type, acl_init, acl_set_fd, acl_set_file, acl_set_permset,
   acl_set_qualifier, acl_set_tag_type, acl_size, acl_to_text, acl_valid.

- Most libacl extensions now implemented, too:
   New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
   acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
   acl_from_mode, acl_get_perm, acl_to_any_text.

- First implementation of pthread_barrier/pthread_barrierattr functions.
   New APIs: pthread_barrierattr_init, pthread_barrierattr_setpshared,
   pthread_barrierattr_getpshared, pthread_barrierattr_destroy,
   pthread_barrier_init, pthread_barrier_destroy, pthread_barrier_wait.

- Enabled console reports requested by escape sequences: Requesting primary
   and secondary device attributes, requesting cursor position report;
   see https://cygwin.com/ml/cygwin-patches/2012-q3/msg00019.html

- New APIs: clog10, clog10f, nexttoward, nexttowardf, nexttowardl.

- Add missing long double functions.  New APIs:
   acoshl, acosl, asinhl, asinl, atan2l, atanhl, atanl, cacoshl, cacosl, 
cargl,
   casinhl, casinl, catanhl, catanl, ccoshl, ccosl, ceill, cexpl, clog10l,
   clogl, conjl, copysignl, coshl, cosl, cpowl, cprojl, csinhl, csinl, 
csqrtl,
   ctanhl, ctanl, dreml, erfcl, erfl, exp10l, exp2l, expl, expm1l, fabsl,
   fdiml, floorl, fmal, fmaxl, fminl, fmodl, frexpl, ilogbl, isinfl, isnanl,
   ldexpl, lgammal, lgammal_r, llroundl, log10l, log1pl, log2l, logbl, logl,
   lroundl, modfl, nearbyintl, nextafterl, pow10l, powl, remainderl, 
remquol,
   roundl, scalbl, scalblnl, scalbnl, sincosl, sinhl, sinl, tanhl, tanl,
   tgammal, truncl.

- New header: cpio.h.


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

- Including <sys/acl.h> now *only* includes the POSIX ACL API.  To include
   the old Solaris API, include <cygwin/acl.h>.

- In calls to chmod treat ACLs with extra ACEs *only* for Admins and
   SYSTEM like a trivial ACL.

- Bump POSIX option macros to POSIX.1-2008.

- Profiling data, specifically pc sampling, now covers all threads of a
   program and not just the main thread.  Environment variable 
GMON_OUT_PREFIX
   enables multiple gmon.out files to preserve profiling data after fork or
   from multiple program runs.

- Feature test macros, which control which symbols are exposed in the 
standard headers, have been completely overhauled for compatibility with 
glibc.

- The isinf, isinff, and isinfl functions are signed, returning -1 for 
negative infinity for compatibility with glibc.


Bug Fixes
---------

- Fix potential hang when using LoadLibraryEx(LOAD_LIBRARY_SEARCH_SYSTEM32).
   Reported and tested via IRC.

- Fix a bug in ACL handling which might result in a spurious extra entry
   for the primary group.  Self-observed.

- printf(3): Handle multibyte decimal point in field size computation.
   Addresses: https://cygwin.com/ml/cygwin/2016-02/msg00014.html

- cygwin_conv_path: Always preserve trailing backslashes in conversion
   to POSIX paths.
   Addresses: https://cygwin.com/ml/cygwin/2016-01/msg00480.html

- Make buffered console characters visible to select().
   Addresses: https://cygwin.com/ml/cygwin/2014-12/msg00118.html

- Always report relocation problems, not only in debug DLL.
   Addresses: https://cygwin.com/ml/cygwin/2016-02/msg00147.html

- Don't spill network credentials of privileged user changing the user
   context via setuid method 1
   (https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1) into
   user session.
   Addresses: https://cygwin.com/ml/cygwin/2016-02/msg00101.html

- Fix bug in setvbuf resulting in overwriting data in line buffered IO
   when writing after reading.
   Addresses: https://cygwin.com/ml/cygwin/2016-03/msg00180.html

- Fix typo in code converting Windows ACL to POSIX ACL, potentially
   resulting in incorrect group permissions.  Self-observed.

- Fix reading/writing ACLs on Samba shares when using RFC2307 mapped uid/gid
   values.  Self-observed.

- Fix a wrong error code returned when trying to execute a file which can't
   be read for any reason.
   Addresses: https://cygwin.com/ml/cygwin/2016-03/msg00364.html

- Only allow enabled groups from the user token's group list as primary
   token.
   Addresses: https://cygwin.com/ml/cygwin/2016-03/msg00477.html

- Fix implementation of finitel.
   Addresses: https://cygwin.com/ml/cygwin-apps/2016-03/msg00152.html

- Fix strtold return value for +/-infinity.
   Addresses: https://cygwin.com/ml/cygwin-apps/2016-03/msg00152.html

- Fix accepted specifications with `getconf -v' on 64-bit.  Self-observed.

-- 
Yaakov

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

[Mark Geisert]

I am running into a problem building Cygwin 2.5.0-0.11 from source on Windows 7 
64-bit.  This is not new with the latest test release but I believe it is new 
with 2.5.0 over 2.4.1.

When building in winsup/utils, I hit this:

c++wrap -pipe -march=haswell -fno-exceptions -fno-rtti -O2 -g -fno-rtti 
-fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings 
-fno-common -pipe -fbuiltin -fmessage-length=0 -c -o cygwin-console-helper.o 
/oss/src/winsup/utils/cygwin-console-helper.cc
i686-w64-mingw32-g++  -o cygwin-console-helper.exe cygwin-console-helper.o -static
cygwin-console-helper.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
Makefile:153: recipe for target 'cygwin-console-helper.exe' failed
make[3]: *** [cygwin-console-helper.exe] Error 1
make[3]: Leaving directory '/oss/build/x86_64-unknown-cygwin/winsup/utils'
Makefile:83: recipe for target 'utils' failed
make[2]: *** [utils] Error 1
make[2]: Leaving directory '/oss/build/x86_64-unknown-cygwin/winsup'
Makefile:8947: recipe for target 'all-target-winsup' failed
make[1]: *** [all-target-winsup] Error 2
make[1]: Leaving directory '/oss/build'
Makefile:853: recipe for target 'all' failed
make: *** [all] Error 2

I found that the generated winsup/utils/Makefile has
MINGW_CXX      := i686-w64-mingw32-g++
even though I am building on 64-bit.

I'm not deeply familiar with autoconf but something about the configuring seems 
wrong.  configure.ac checks for the existence of ${target_cpu}-w64-mingw32-g++ 
but config.status shows target_cpu isn't initialized until after MINGW_CXX is 
initialized.  I have compilers for both arches installed, if that matters.

..mark

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

[Yaakov Selkowitz]

On 2016-04-05 00:54, Mark Geisert wrote:
> When building in winsup/utils, I hit this:
[snip]
> I found that the generated winsup/utils/Makefile has
> MINGW_CXX      := i686-w64-mingw32-g++
> even though I am building on 64-bit.

I can't reproduce this with git master.  Are you sure you have both a 
clean clone and a clean build directory?

-- 
Yaakov

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

[Mark Geisert]

Yaakov Selkowitz wrote:
> On 2016-04-05 00:54, Mark Geisert wrote:
>> When building in winsup/utils, I hit this:
> [snip]
>> I found that the generated winsup/utils/Makefile has
>> MINGW_CXX      := i686-w64-mingw32-g++
>> even though I am building on 64-bit.
>
> I can't reproduce this with git master.  Are you sure you have both a clean
> clone and a clean build directory?

I'm obtaining the source via setup-x86_64.exe, not git clone.  Then going to the 
download directory under /usr/src and doing 'cygport cygwin.cygport prep'.  Then 
setting up /oss tree like the FAQ suggests, with /oss/src symlinked to the right 
level of the download tree.  cd to /oss/build, configure and make like the FAQ 
demonstrates.

I'll try it with a git clone and report back.
Thanks,

..mark

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

[Mark Geisert]

Mark Geisert wrote:
> Yaakov Selkowitz wrote:
>> On 2016-04-05 00:54, Mark Geisert wrote:
>>> When building in winsup/utils, I hit this:
>> [snip]
>>> I found that the generated winsup/utils/Makefile has
>>> MINGW_CXX      := i686-w64-mingw32-g++
>>> even though I am building on 64-bit.
>>
>> I can't reproduce this with git master.  Are you sure you have both a clean
>> clone and a clean build directory?
>
> I'm obtaining the source via setup-x86_64.exe, not git clone.  Then going to the
> download directory under /usr/src and doing 'cygport cygwin.cygport prep'.  Then
> setting up /oss tree like the FAQ suggests, with /oss/src symlinked to the right
> level of the download tree.  cd to /oss/build, configure and make like the FAQ
> demonstrates.
>
> I'll try it with a git clone and report back.

I'm getting the same error.  FYI this is with /oss tree per the FAQ with 
/oss/src symlinked to root of the cloned tree, then building in /oss/build.

Do you have both i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++ installed?

..mark


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

[Ismail Donmez]

Hi,

On Tue, Apr 5, 2016 at 12:29 AM, Yaakov Selkowitz <yselkowitz@cygwin.com> wrote:
> Hi Cygwin friends and users,
>
>
> Corinna just released a new Cygwin TEST version 2.5.0-0.11.
>
> If things are not going very wrong, this is basically what you'll
> get as 2.5.0-1 release (really, we mean it this time).  Please, please test
> and report regressions.

This results in a very interesting regression for me. Running zsh in
login mode with zsh --login fails and turns out that it hangs at

/etc/zprofile line 56 which basically says:

USER="$(/usr/bin/id -un)"

I tried running the same command under zsh (without login mode) and
fair enough it works fine, so I went ahead and commented that line and
it now hangs at line 145:

HOSTNAME="$(/usr/bin/hostname)"

and well it seems that running any subcommand inside a zsh script
seems to hang. I confirmed this with a script of mine which hung at a
"cat" command.

Reverting back to cygwin1-20160330.dll did fix the issue for me. This
is on Win7 x64.

Thanks,
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.5.0-0.11

[Thorsten Kampe]

* Yaakov Selkowitz (Mon, 4 Apr 2016 16:29:11 -0500)
> Corinna just released a new Cygwin TEST version 2.5.0-0.11.
> 
> If things are not going very wrong, this is basically what you'll
> get as 2.5.0-1 release (really, we mean it this time).  Please, please 
> test and report regressions.

As reported by Ismail: I can't get an interactive Zsh with the newest 
snapshot. It hangs at

    eval $(dircolors -b ~/.dir_colors)
    eval $(ssh-pageant -qr -a $TMP/.ssh-pageant)

...and afterwards at line 106 in compdump (an internal function).

Thorsten


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

[Corinna Vinschen]

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

On Apr  5 10:51, Ismail Donmez wrote:
> Hi,
> 
> On Tue, Apr 5, 2016 at 12:29 AM, Yaakov Selkowitz <yselkowitz@cygwin.com> wrote:
> > Hi Cygwin friends and users,
> >
> >
> > Corinna just released a new Cygwin TEST version 2.5.0-0.11.
> >
> > If things are not going very wrong, this is basically what you'll
> > get as 2.5.0-1 release (really, we mean it this time).  Please, please test
> > and report regressions.
> 
> This results in a very interesting regression for me. Running zsh in
> login mode with zsh --login fails and turns out that it hangs at
> 
> /etc/zprofile line 56 which basically says:
> 
> USER="$(/usr/bin/id -un)"
> 
> I tried running the same command under zsh (without login mode) and
> fair enough it works fine, so I went ahead and commented that line and
> it now hangs at line 145:
> 
> HOSTNAME="$(/usr/bin/hostname)"
> 
> and well it seems that running any subcommand inside a zsh script
> seems to hang. I confirmed this with a script of mine which hung at a
> "cat" command.

Confirmed.  The culprit is apparently commit 0008bde.  I reverted it
and create a -0.12 ASAP.


Thanks,
Corinna

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

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

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

[Corinna Vinschen]

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

On Apr  5 00:18, Mark Geisert wrote:
> Mark Geisert wrote:
> >Yaakov Selkowitz wrote:
> >>On 2016-04-05 00:54, Mark Geisert wrote:
> >>>When building in winsup/utils, I hit this:
> >>[snip]
> >>>I found that the generated winsup/utils/Makefile has
> >>>MINGW_CXX      := i686-w64-mingw32-g++
> >>>even though I am building on 64-bit.
> >>
> >>I can't reproduce this with git master.  Are you sure you have both a clean
> >>clone and a clean build directory?
> >
> >I'm obtaining the source via setup-x86_64.exe, not git clone.  Then going to the
> >download directory under /usr/src and doing 'cygport cygwin.cygport prep'.  Then
> >setting up /oss tree like the FAQ suggests, with /oss/src symlinked to the right
> >level of the download tree.  cd to /oss/build, configure and make like the FAQ
> >demonstrates.
> >
> >I'll try it with a git clone and report back.
> 
> I'm getting the same error.  FYI this is with /oss tree per the FAQ with
> /oss/src symlinked to root of the cloned tree, then building in /oss/build.
> 
> Do you have both i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++ installed?

I can't reproduce this either.  I built in two variations, with
i686-w64-mingw32-g++ installed and not installed, and in both cases
MINGW_CXX was set to x86_64-w64-mingw32-g++

I built manually from git master in a parallel build dir using this
simple script:

#!/bin/sh
SRCDIR=../cygwin-newlib
PREFIX=/usr
SYSCONFDIR=/etc
${SRCDIR}/configure \
        --prefix=${PREFIX} \
        --sysconfdir=${SYSCONFDIR} \
        $@

Care to inspect the config logs to see what happened?


Corinna

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

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

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

[Mark Geisert]

Corinna Vinschen wrote:
> On Apr  5 00:18, Mark Geisert wrote:
>> Mark Geisert wrote:
>>> Yaakov Selkowitz wrote:
>>>> On 2016-04-05 00:54, Mark Geisert wrote:
>>>>> When building in winsup/utils, I hit this:
>>>> [snip]
>>>>> I found that the generated winsup/utils/Makefile has
>>>>> MINGW_CXX      := i686-w64-mingw32-g++
>>>>> even though I am building on 64-bit.
>>>>
>>>> I can't reproduce this with git master.  Are you sure you have both a clean
>>>> clone and a clean build directory?
>>>
>>> I'm obtaining the source via setup-x86_64.exe, not git clone.  Then going to the
>>> download directory under /usr/src and doing 'cygport cygwin.cygport prep'.  Then
>>> setting up /oss tree like the FAQ suggests, with /oss/src symlinked to the right
>>> level of the download tree.  cd to /oss/build, configure and make like the FAQ
>>> demonstrates.
>>>
>>> I'll try it with a git clone and report back.
>>
>> I'm getting the same error.  FYI this is with /oss tree per the FAQ with
>> /oss/src symlinked to root of the cloned tree, then building in /oss/build.
>>
>> Do you have both i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++ installed?
>
> I can't reproduce this either.  I built in two variations, with
> i686-w64-mingw32-g++ installed and not installed, and in both cases
> MINGW_CXX was set to x86_64-w64-mingw32-g++
>
> I built manually from git master in a parallel build dir using this
> simple script:
>
> #!/bin/sh
> SRCDIR=../cygwin-newlib
> PREFIX=/usr
> SYSCONFDIR=/etc
> ${SRCDIR}/configure \
>          --prefix=${PREFIX} \
>          --sysconfdir=${SYSCONFDIR} \
>          $@
>
> Care to inspect the config logs to see what happened?

Oh, flock.  As Yaakov suspected, an issue in my build environment.  Stale 
environment vars from the initial 64-bit Cygwin port days, that I had forgotten 
about.  Removed those from my .bashrc and the whole build runs from start to 
completion now.
Sheepishly,

..mark


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