Re: Packages not found by setup 2.873

[Warren Young]

On Mar 31, 2016, at 2:57 AM, EMMANUELLE FOURNIER 
 wrote:
> 
> I've changed in tar.bz2, because in the x86 version of program, they were in 
> tar.bz2.

You’ve misdiagnosed the cause of the change.  Cygwin changed from distributing 
bz2-packed tarballs to xz-packed tarballs many months ago for both x86 and 
x86_64.

> But if you mean that is not a cause, I will modify this.

I’d want better proof than what you’ve provided to decide that xz is causing 
your problems.

> - I've modified setup in order to find packages in tar.bz2 instead of tar.xz.
> 
> - There were errors for each packages, a pop-up came each time with the 
> following message  : "Can't open (null) for readind : no such file”

Try your setup with a fresh set of .xz packages and an unmodified setup.exe 
binary, downloaded from cygwin.com.  Then if that fails, get back to us.

> 2016/03/25 16:21:28 Selected local directory: 
> C:\D3IPARAM\setup_cygwin\cygwin-setup\http%3a%2f%2fcygwin.gicm.net%3a8080%2f

It seems you’re using bogus domain names in your setup.ini file.  
http://cygwin.gicm.net doesn’t resolve:

  http://downforeveryoneorjustme.com/cygwin.gicm.net

I don’t know if this is the primary problem or just a contributing error, but 
you shouldn’t have setup.exe chasing after things that don’t exist.  At best, 
it will cause it to do a bunch of work with no useful effect.

> And I can try without "-C base”.

I verified that guess after I posted it: -C base is indeed not necessary.

> A final information : I've made it with x86 setup on x64 target machine. Is 
> it a problem ? I don't think so, but I still wonder.

If you mean that you’re installing 32-bit Cygwin on a 64-bit machine, that’s 
fine.  The other direction is not fine.


--
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: [attention p7zip maintainer] p7zip 15.14 is out

[Jon Turney]

On 31/03/2016 13:54, Gerrit Haase wrote:

2016-03-19 15:12 GMT+01:00 Achim Gratz wrote:


You might also want to add 'DEPEND="nasm"', since the build needs it
(probably other stuff too, but I already had that installed).


Hello Achim,

is is common sense nowadays, to add packages required to build from
source to the executable runtime dependencies?


DEPEND [1] is not the same as REQUIRES [2]

[1] https://cygwinports.github.io/cygport/check_funcs_cygpart.html#robo905
[2] https://cygwinports.github.io/cygport/pkg_pkg_cygpart.html#robo424

--
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: [attention p7zip maintainer] p7zip 15.14 is out

[Andrey Repin]

Greetings, Gerrit Haase!

>> You might also want to add 'DEPEND="nasm"', since the build needs it
>> (probably other stuff too, but I already had that installed).

> Hello Achim,

> is is common sense nowadays, to add packages required to build from
> source to the executable runtime dependencies?

It's often an oversight/backlash.


-- 
With best regards,
Andrey Repin
Friday, April 1, 2016 02:11:37

Sorry for my terrible english...


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

rsync performance degradation? Could be a windows issue?

[Greg Freemyer]

All,

I'm not sure this is on-topic, but at least I'm in cygwin when I
notice the below:

I do a lot of large data transfers between USB drives.  Often I get
great speeds (70MB/sec or more).

Sometimes it falls way off to closer to 20MB/sec with the same class
of hardware.

I experienced the "slow" transfer speed today, so I thought I'd ask if
anyone knew a way to resolve it?

The PC I'm running on is spec'ed for data processing so a 6 core (12
thread) setup with 128GB or RAM.

No significant data processing is going on.  Basically the machine is
currently dedicated to running rsync (as below).

I have 2 USB drives hooked up.  Both are USB-3 and should be able to
do 70MB/sec with no issue.

Neither drive has any unrelated I/O going on that I know of.  (I don't
see any in the Windows Performance Monitor.)

I have a folder with almost 200 4GB files ( 750GB total and all the
files are large).

I'm using "rsync -av" to copy files from the source to the destination
and the folder on the destination started out empty

Using Windows "Resource Monitor" I normally would see both drives
hitting over 70 MB/sec.  Today I'm seeing the source drive jump all
the way up to 125 MB/sec or so, but the destination is down around 20
MB/sec

When the 4GB source file completes reading, the source drive basically
goes idle for a while until the file is written out.

Then the source drive jumps back to 125 MB/sec until it finishes
reading the next file.  The destination drive on the other hand is
stuck down around 20 MB/sec.

I really don't think this is caused by slow hardware.  Could the
destination drive be dropping down to USB-2 mode?

===
And now that I've written up the above, the system has returned to a
more normal 75 MB/sec consistently on the output drive.

I'm still curious what might be going on.  As I say I move a lot of
data around as part of my work, and much of the time it is big groups
of either 1.5GB or 4GB files.

Thanks
Greg
--
Greg Freemyer
www.IntelligentAvatar.net

--
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: strange cygwin sshd user generated (user name includes machine name)

[Pete Moore]

RESOLVED! =)

I’m happy to report Brian McGeorge found a solution, which was kindly
passed on to me via Ben Stragnell. The answer is to set the
environment variable LOGONSERVER to \\%COMPUTERNAME%.

This works by not executing the body of the if statement in:
https://cygwin.com/git/gitweb.cgi?p=cygwin-csih.git;a=blob;f=cygwin-service-installation-helper.sh;h=10ab4fb6d47803c9ffabdde51923fc2c3f0496bb;hb=7ca191bebb52ae414bb2a2e37ef22d94f2658dc7#l2884

(lines 2884 to 2890)

My working user data now looks like this (note - you need to see both
links for context - different parts of the same user data file).

   * 
https://github.com/taskcluster/generic-worker/blob/b0786db002921d3ec7d40053ac2e6799679ab290/worker_types/win2012r2/userdata#L4
   * 
https://github.com/taskcluster/generic-worker/blob/b0786db002921d3ec7d40053ac2e6799679ab290/worker_types/win2012r2/userdata#L81-L101

The addition to the powershell script was simply:

   $env:LOGONSERVER = "\\" + $env:COMPUTERNAME

I can confirm this fix works! Thanks again to Brian and Ben. =)

Pete

--
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: strange cygwin sshd user generated (user name includes machine name)

[Peter Moore]

RESOLVED! =)

I’m happy to report Brian McGeorge found a solution, which was kindly passed on 
to me via Ben Stragnell. The answer is to set the environment variable 
LOGONSERVER to \\%COMPUTERNAME%.

This works by not executing the body of the if statement in: 
https://cygwin.com/git/gitweb.cgi?p=cygwin-csih.git;a=blob;f=cygwin-service-installation-helper.sh;h=10ab4fb6d47803c9ffabdde51923fc2c3f0496bb;hb=7ca191bebb52ae414bb2a2e37ef22d94f2658dc7#l2884

(lines 2884 to 2890)

My working user data now looks like this (note - you need to see both links for 
context - different parts of the same user data file).

* 
https://github.com/taskcluster/generic-worker/blob/b0786db002921d3ec7d40053ac2e6799679ab290/worker_types/win2012r2/userdata#L4
* 
https://github.com/taskcluster/generic-worker/blob/b0786db002921d3ec7d40053ac2e6799679ab290/worker_types/win2012r2/userdata#L81-L101

The addition to the powershell script was simply:

$env:LOGONSERVER = "\\" + $env:COMPUTERNAME

I can confirm this fix works! Thanks again to Brian and Ben. =)

Pete



> On 03 Oct 2015, at 20:27, Peter Moore  wrote:
> 
> After a little bit more digging, I think the cygwin name is coming from the 
> output of getent here:
> 
> https://cygwin.com/git/gitweb.cgi?p=cygwin-csih.git;a=blob;f=cygwin-service-installation-helper.sh;h=10ab4fb6d47803c9ffabdde51923fc2c3f0496bb;hb=7ca191bebb52ae414bb2a2e37ef22d94f2658dc7#l2705
> 
> At this point, I’m not sure what causes getent to return different values 
> when run in automation, and when run manually. I wonder if there is some kind 
> of race condition, such that some subsystem is still updating at the point I 
> install cygwin sshd.
> 
> For reference, this is the powershell script, see lines 77 onwards:
> https://hg.mozilla.org/try/file/4905af7c52e5/testing/taskcluster/worker_types/win2012r2/aws_userdata
> 
> Thanks!
> Pete
> 
> 
> 
>> On 03 Oct 2015, at 19:12, Peter Moore  wrote:
>> 
>> Hi,
>> 
>> I have a powershell script for installing cygwin and setting up sshd which I 
>> am using as UserData when firing up a Windows 2012 R2 instance in AWS EC2.
>> 
>> The same command succeeds when run manually, but fails when called from 
>> automation. I’m trying to understand what it is that is different, so I can 
>> fix it in automation.
>> 
>> The command called is:
>> 
>> ssh-host-config -y -c 'ntsec mintty' -u 'cygwinsshd' -w 'qwe123QWE!@#'
>> 
>> When I run manually, logged in as Administrator, I get a log line like this 
>> (notice the correct “Cygwin name”):
>> 
>> *** Query: Create new privileged user account 'WIN-EFPDIM0SAUP\cygwinsshd' 
>> (Cygwin name: ‘cygwinsshd')? (yes/no) yes
>> 
>> When I run from automation, the log line looks like this (notice the 
>> incorrect “Cygwin name”):
>> 
>> *** Query: Create new privileged user account 'WIN-EFPDIM0SAUP\cygwinsshd' 
>> (Cygwin name: 'win-efpdim0saup+cygwinsshd')? (yes/no) yes
>> 
>> It seems the extended “Cygwin name” which I get in automation causes 
>> ssh-host-config to fail. I’m trying to establish what causes the cygwin name 
>> to get the prefix of the machine name, since this seems to cause the problem.
>> 
>> For reference, below I’ve put the logs in both the successful (manual) case, 
>> and the failing (automated) case.
>> 
>> If anyone can point me to the source code of ssh-host-config I’m also happy 
>> to dig - I couldn’t find it online. So if you’re not sure, but know where 
>> the source is, I’m happy to look.
>> 
>> Many thanks in advance!
>> Pete
>> 
>> 
>> 
>> SUCCESSFUL run (when executed manually):
>> 
>> *** Query: Create new privileged user account 'WIN-EFPDIM0SAUP\cygwinsshd' 
>> (Cygwin name: ‘cygwinsshd')? (yes/no) yes
>> *** Info: User ‘cygwinsshd' has been created with password 'qwe123QWE!@#'.
>> *** Info: If you change the password, please remember also to change the
>> *** Info: password for the installed services which use (or will soon use)
>> *** Info: the ‘cygwinsshd' account.
>> 
>> *** Info: The sshd service has been installed under the ‘cygwinsshd'
>> *** Info: account.  To start the service now, call `net start sshd' or
>> *** Info: `cygrunsrv -S sshd'.  Otherwise, it will start automatically
>> *** Info: after the next reboot.
>> *** Info: Host configuration finished. Have fun!
>> 
>> 
>> FAILED run (when called in automation):
>> 
>> *** Query: Create new privileged user account 'WIN-EFPDIM0SAUP\cygwinsshd' 
>> (Cygwin name: 'win-efpdim0saup+cygwinsshd')? (yes/no) yes
>> *** Info: User 'win-efpdim0saup+cygwinsshd' has been created with password 
>> 'qwe123QWE!@#'.
>> *** Info: If you change the password, please remember also to change the
>> *** Info: password for the installed services which use (or will soon use)
>> *** Info: the 'win-efpdim0saup+cygwinsshd' account.
>> 
>> *** Warning: Setting password expiry for user 'win-efpdim0saup+cygwinsshd' 
>> failed!
>> *** Warning: Please check that password never expires or set it to your 
>> needs.
>> No 

Re: windows exit codes truncated to 1 Byte

[Eric Blake]

On 03/31/2016 12:50 PM, Corinna Vinschen wrote:
> On Mar 31 09:24, Eric Blake wrote:
>> On 03/31/2016 07:30 AM, Björn Stabel wrote:
>>> Am 31.03.2016 um 15:01 schrieb Cristian:
 I noted that exit codes returned by CMD and other apps (msiexec) are 
 truncated to 1 byte (0 .. 255).
>>
>> This matches Linux, but not POSIX.
> 
> Why?  Does bash use waitid?

Not yet, but with the link I referred to below, the thought is that
eventually bash WILL use waitid(), based on the direction POSIX is
headed in.

> But...
> 
>>> POSIX specifies that the lower 8 bits of the exit status be made
>>> available to the caller of wait/waitpid:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
>>
>> Correct: wait() and waitpid() can only return 8 bits; but POSIX states
>> that waitid() MUST be able to access all 32-bits untruncated; this is
>> where Linux gets it wrong (Linux truncates during exit(), so waitid()
>> can only return 8 bits; other operating systems do NOT truncate during
>> exit, but preserve all 32 bits; if you use wait() or waitpid() you only
>> get 8 bits, but if you use waitid() you can see the full 32 bits).
> 
> ...that only makes sense if we implement waitid at all.  SHTDI and all
> that...

Right - without waitid(), it's fairly obvious that cygwin isn't quite up
to POSIX compliance yet :)  And indeed, patches are welcome, if someone
who cares enough about more than 8 bits wants to step up and write it
(personally, I don't care enough as long as Linux is still truncating
early during exit()).

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



signature.asc
Description: OpenPGP digital signature

Re: windows exit codes truncated to 1 Byte

[Corinna Vinschen]

On Mar 31 09:24, Eric Blake wrote:
> On 03/31/2016 07:30 AM, Björn Stabel wrote:
> > Am 31.03.2016 um 15:01 schrieb Cristian:
> >> I noted that exit codes returned by CMD and other apps (msiexec) are 
> >> truncated to 1 byte (0 .. 255).
> 
> This matches Linux, but not POSIX.

Why?  Does bash use waitid?

> >> Windows exit codes are represented using 32 bits, so is this limitation 
> >> intentional?
> 
> Part intentional (we do what Linux does), and part accidental (Cygwin
> handles the return status slightly different than Windows, and that
> handling makes it impossible to easily preserve all 32-bits, even if
> Linux were to be patched to obey POSIX).

I don't quite understand this.  Right now the exitcode value is
truncated to 8 bits to fit into the 32 bit status value as defined
for wait/waitpid, but this is not set in stone.  We could change
the communication between parent and child to allow preserving the
full 32 bit value for waitid.

But...

> > POSIX specifies that the lower 8 bits of the exit status be made
> > available to the caller of wait/waitpid:
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html
> 
> Correct: wait() and waitpid() can only return 8 bits; but POSIX states
> that waitid() MUST be able to access all 32-bits untruncated; this is
> where Linux gets it wrong (Linux truncates during exit(), so waitid()
> can only return 8 bits; other operating systems do NOT truncate during
> exit, but preserve all 32 bits; if you use wait() or waitpid() you only
> get 8 bits, but if you use waitid() you can see the full 32 bits).

...that only makes sense if we implement waitid at all.  SHTDI and all
that...


Corinna

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


signature.asc
Description: PGP signature

[PATCH 4/4] Update autoconf for doc/lsaauth/utils

[Peter Foley]

Don't use obsolete LIB_AC_PROG_CC.
Run autoupdate.

winsup/ChangeLog:
doc/aclocal.m4: delete
lsaauth/aclocal.m4: ditto
doc/configure.ac: refactor and update
lsaauth/configure.ac: ditto
utils/configure.ac: ditto
doc/configure: regenerate
lsaauth/configure: regenerate
utils/configure: regenerate

Signed-off-by: Peter Foley 
---
 winsup/doc/aclocal.m4   | 875 
 winsup/doc/configure|  95 -
 winsup/doc/configure.ac |   5 +-
 winsup/lsaauth/aclocal.m4   | 875 
 winsup/lsaauth/configure|  95 -
 winsup/lsaauth/configure.ac |   7 +-
 winsup/utils/configure.ac   |   8 +-
 7 files changed, 11 insertions(+), 1949 deletions(-)
 delete mode 100644 winsup/doc/aclocal.m4
 delete mode 100644 winsup/lsaauth/aclocal.m4

diff --git a/winsup/doc/aclocal.m4 b/winsup/doc/aclocal.m4
deleted file mode 100644
index ecef424..000
--- a/winsup/doc/aclocal.m4
+++ /dev/null
@@ -1,875 +0,0 @@
-dnl aclocal.m4 generated automatically by aclocal 1.4-p6
-
-dnl Copyright (C) 1994, 1995-8, 1999, 2001 Free Software Foundation, Inc.
-dnl This file is free software; the Free Software Foundation
-dnl gives unlimited permission to copy and/or distribute it,
-dnl with or without modifications, as long as this notice is preserved.
-
-dnl This program is distributed in the hope that it will be useful,
-dnl but WITHOUT ANY WARRANTY, to the extent permitted by law; without
-dnl even the implied warranty of MERCHANTABILITY or FITNESS FOR A
-dnl PARTICULAR PURPOSE.
-
-# lib-prefix.m4 serial 4 (gettext-0.14.2)
-dnl Copyright (C) 2001-2005 Free Software Foundation, Inc.
-dnl This file is free software; the Free Software Foundation
-dnl gives unlimited permission to copy and/or distribute it,
-dnl with or without modifications, as long as this notice is preserved.
-
-dnl From Bruno Haible.
-
-dnl AC_LIB_ARG_WITH is synonymous to AC_ARG_WITH in autoconf-2.13, and
-dnl similar to AC_ARG_WITH in autoconf 2.52...2.57 except that is doesn't
-dnl require excessive bracketing.
-ifdef([AC_HELP_STRING],
-[AC_DEFUN([AC_LIB_ARG_WITH], [AC_ARG_WITH([$1],[[$2]],[$3],[$4])])],
-[AC_DEFUN([AC_][LIB_ARG_WITH], [AC_ARG_WITH([$1],[$2],[$3],[$4])])])
-
-dnl AC_LIB_PREFIX adds to the CPPFLAGS and LDFLAGS the flags that are needed
-dnl to access previously installed libraries. The basic assumption is that
-dnl a user will want packages to use other packages he previously installed
-dnl with the same --prefix option.
-dnl This macro is not needed if only AC_LIB_LINKFLAGS is used to locate
-dnl libraries, but is otherwise very convenient.
-AC_DEFUN([AC_LIB_PREFIX],
-[
-  AC_BEFORE([$0], [AC_LIB_LINKFLAGS])
-  AC_REQUIRE([AC_PROG_CC])
-  AC_REQUIRE([AC_CANONICAL_HOST])
-  AC_REQUIRE([AC_LIB_PREPARE_PREFIX])
-  dnl By default, look in $includedir and $libdir.
-  use_additional=yes
-  AC_LIB_WITH_FINAL_PREFIX([
-eval additional_includedir=\"$includedir\"
-eval additional_libdir=\"$libdir\"
-  ])
-  AC_LIB_ARG_WITH([lib-prefix],
-[  --with-lib-prefix[=DIR] search for libraries in DIR/include and DIR/lib
-  --without-lib-prefixdon't search for libraries in includedir and libdir],
-[
-if test "X$withval" = "Xno"; then
-  use_additional=no
-else
-  if test "X$withval" = "X"; then
-AC_LIB_WITH_FINAL_PREFIX([
-  eval additional_includedir=\"$includedir\"
-  eval additional_libdir=\"$libdir\"
-])
-  else
-additional_includedir="$withval/include"
-additional_libdir="$withval/lib"
-  fi
-fi
-])
-  if test $use_additional = yes; then
-dnl Potentially add $additional_includedir to $CPPFLAGS.
-dnl But don't add it
-dnl   1. if it's the standard /usr/include,
-dnl   2. if it's already present in $CPPFLAGS,
-dnl   3. if it's /usr/local/include and we are using GCC on Linux,
-dnl   4. if it doesn't exist as a directory.
-if test "X$additional_includedir" != "X/usr/include"; then
-  haveit=
-  for x in $CPPFLAGS; do
-AC_LIB_WITH_FINAL_PREFIX([eval x=\"$x\"])
-if test "X$x" = "X-I$additional_includedir"; then
-  haveit=yes
-  break
-fi
-  done
-  if test -z "$haveit"; then
-if test "X$additional_includedir" = "X/usr/local/include"; then
-  if test -n "$GCC"; then
-case $host_os in
-  linux* | gnu* | k*bsd*-gnu) haveit=yes;;
-esac
-  fi
-fi
-if test -z "$haveit"; then
-  if test -d "$additional_includedir"; then
-dnl Really add $additional_includedir to $CPPFLAGS.
-CPPFLAGS="${CPPFLAGS}${CPPFLAGS:+ }-I$additional_includedir"
-  fi
-fi
-  fi
-fi
-dnl Potentially add $additional_libdir to $LDFLAGS.
-dnl But don't add it
-dnl   1. if it's the standard /usr/lib,
-dnl   2. if it's already present in $LDFLAGS,
-dnl   3. if it's /usr/local/lib and we 

[PATCH 3/4] Remove remnants of never-defined MALLOC_DEBUG and NEWVFORK

[Peter Foley]

MALLOC_DEBUG and NEWVFORK haven't been defined since 2008 (46162537516c5e5fbb).
Remove all references to tem.

winsup/cygwin/ChangeLog:
acconfig.h: delete
dcrt0.cc (dll_crt0_1): remove NEWVFORK code.
dcrt0.cc (do_exit): ditto.
debug.h: ditto.
dtable.h: ditto.
winsup.h: ditto.
globals.cc: ditto.
malloc_wrapper.cc: ditto.
malloc_wrapper.cc (malloc_init): ditto.
spawn.cc (spawnve): ditto.
syscalls.cc (setsid): ditto.

Signed-off-by: Peter Foley 
---
 winsup/cygwin/acconfig.h|  5 -
 winsup/cygwin/config.h.in   |  5 -
 winsup/cygwin/dcrt0.cc  | 14 --
 winsup/cygwin/debug.h   |  9 -
 winsup/cygwin/dtable.h  |  6 --
 winsup/cygwin/globals.cc|  3 ---
 winsup/cygwin/malloc_wrapper.cc |  4 
 winsup/cygwin/spawn.cc  | 18 --
 winsup/cygwin/syscalls.cc   | 15 ---
 winsup/cygwin/winsup.h  |  2 --
 10 files changed, 81 deletions(-)
 delete mode 100644 winsup/cygwin/acconfig.h

diff --git a/winsup/cygwin/acconfig.h b/winsup/cygwin/acconfig.h
deleted file mode 100644
index ffe9f81..000
--- a/winsup/cygwin/acconfig.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* Define if MALLOC_DEBUGGING support is requested.  */
-#undef MALLOC_DEBUG
-
-/* Define if using new vfork functionality. */
-#undef NEWVFORK
diff --git a/winsup/cygwin/config.h.in b/winsup/cygwin/config.h.in
index 32f191a..5ddff24 100644
--- a/winsup/cygwin/config.h.in
+++ b/winsup/cygwin/config.h.in
@@ -1,9 +1,4 @@
 /* config.h.in.  Generated from configure.ac by autoheader.  */
-/* Define if MALLOC_DEBUGGING support is requested.  */
-#undef MALLOC_DEBUG
-
-/* Define if using new vfork functionality. */
-#undef NEWVFORK
 
 /* Define if DEBUGGING support is requested. */
 #undef DEBUGGING
diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 94f7bf8..aaa8c44 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -902,11 +902,6 @@ dll_crt0_1 (void *)
  Need to do this before any helper threads start. */
   debug_init ();
 
-#ifdef NEWVFORK
-  cygheap->fdtab.vfork_child_fixup ();
-  main_vfork = vfork_storage.create ();
-#endif
-
   cygbench ("pre-forkee");
   if (in_forkee)
 {
@@ -1197,15 +1192,6 @@ do_exit (int status)
 {
   syscall_printf ("do_exit (%d), exit_state %d", status, exit_state);
 
-#ifdef NEWVFORK
-  vfork_save *vf = vfork_storage.val ();
-  if (vf != NULL && vf->pid < 0)
-{
-  exit_state = ES_NOT_EXITING;
-  vf->restore_exit (status);
-}
-#endif
-
   lock_process until_exit (true);
 
   if (exit_state < ES_EVENTS_TERMINATE)
diff --git a/winsup/cygwin/debug.h b/winsup/cygwin/debug.h
index 627c77e..602ab93 100644
--- a/winsup/cygwin/debug.h
+++ b/winsup/cygwin/debug.h
@@ -7,16 +7,7 @@ This software is a copyrighted work licensed under the terms 
of the
 Cygwin license.  Please consult the file "CYGWIN_LICENSE" for
 details. */
 
-#ifndef MALLOC_DEBUG
 #define MALLOC_CHECK do {} while (0)
-#else
-#include 
-#include 
-#define MALLOC_CHECK ({\
-  debug_printf ("checking malloc pool");\
-  mallinfo ();\
-})
-#endif
 
 #if !defined(_DEBUG_H_)
 #define _DEBUG_H_
diff --git a/winsup/cygwin/dtable.h b/winsup/cygwin/dtable.h
index 34e975b..fb44c95 100644
--- a/winsup/cygwin/dtable.h
+++ b/winsup/cygwin/dtable.h
@@ -25,9 +25,6 @@ class suffix_info;
 class dtable
 {
   fhandler_base **fds;
-#ifdef NEWVFORK
-  fhandler_base **fds_on_hold;
-#endif
   fhandler_base **archetypes;
   unsigned narchetypes;
   unsigned farchetype;
@@ -77,9 +74,6 @@ public:
   void stdio_init ();
   void get_debugger_info ();
   void set_file_pointers_for_exec ();
-#ifdef NEWVFORK
-  bool in_vfork_cleanup () {return fds_on_hold == fds;}
-#endif
   fhandler_base *find_archetype (device& dev);
   fhandler_base **add_archetype ();
   void delete_archetype (fhandler_base *);
diff --git a/winsup/cygwin/globals.cc b/winsup/cygwin/globals.cc
index 990158e..7dfe74d 100644
--- a/winsup/cygwin/globals.cc
+++ b/winsup/cygwin/globals.cc
@@ -88,9 +88,6 @@ int NO_COPY __isthreaded = 0;
 int __argc_safe;
 int __argc;
 char **__argv;
-#ifdef NEWVFORK
-vfork_save NO_COPY *main_vfork;
-#endif
 
 _cygtls NO_COPY *_main_tls /* !globals.h */;
 
diff --git a/winsup/cygwin/malloc_wrapper.cc b/winsup/cygwin/malloc_wrapper.cc
index 0db5de8..8098952 100644
--- a/winsup/cygwin/malloc_wrapper.cc
+++ b/winsup/cygwin/malloc_wrapper.cc
@@ -18,9 +18,7 @@ details. */
 #include "perprocess.h"
 #include "miscfuncs.h"
 #include "cygmalloc.h"
-#ifndef MALLOC_DEBUG
 #include 
-#endif
 extern "C" struct mallinfo dlmallinfo ();
 
 /* we provide these stubs to call into a user's
@@ -281,7 +279,6 @@ malloc_init ()
 {
   mallock.init ("mallock");
 
-#ifndef MALLOC_DEBUG
   /* Check if malloc is provided by application. If so, redirect all
  calls to malloc/free/realloc to application provided. This may
  happen if some other dll calls cygwin's malloc, but main code provides
@@ -296,7 +293,6 @@ malloc_init ()
   malloc_printf 

[PATCH 1/4] Remove leftover cruft from config.h.in

[Peter Foley]

HAVE_BUILTIN_MEMTEST and AC_ALLOCA were removed in 4bd8eb7d1b.
Cleanup leftover references.

winsup/cygwin/ChangeLog
acconfig.h: remove HAVE_BUILTIN_MEMTEST
config.h.in: regenerate

Signed-off-by: Peter Foley 
---
 winsup/cygwin/acconfig.h  |  3 ---
 winsup/cygwin/config.h.in | 31 ---
 2 files changed, 4 insertions(+), 30 deletions(-)

diff --git a/winsup/cygwin/acconfig.h b/winsup/cygwin/acconfig.h
index 0c1dc66..2f8d58c 100644
--- a/winsup/cygwin/acconfig.h
+++ b/winsup/cygwin/acconfig.h
@@ -1,9 +1,6 @@
 /* Define if DEBUGGING support is requested.  */
 #undef DEBUGGING
 
-/* Define if GCC supports builtin memset.  */
-#undef HAVE_BUILTIN_MEMSET
-
 /* Define if MALLOC_DEBUGGING support is requested.  */
 #undef MALLOC_DEBUG
 
diff --git a/winsup/cygwin/config.h.in b/winsup/cygwin/config.h.in
index 32cba72..39eb968 100644
--- a/winsup/cygwin/config.h.in
+++ b/winsup/cygwin/config.h.in
@@ -1,31 +1,13 @@
-/* config.h.in.  Generated from configure.in by autoheader.  */
+/* config.h.in.  Generated from configure.ac by autoheader.  */
 /* Define if DEBUGGING support is requested.  */
 #undef DEBUGGING
 
-/* Define if GCC supports builtin memset.  */
-#undef HAVE_BUILTIN_MEMSET
-
 /* Define if MALLOC_DEBUGGING support is requested.  */
 #undef MALLOC_DEBUG
 
 /* Define if using new vfork functionality. */
 #undef NEWVFORK
 
-/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
-   systems. This function is required for `alloca.c' support on those systems.
-   */
-#undef CRAY_STACKSEG_END
-
-/* Define to 1 if using `alloca.c'. */
-#undef C_ALLOCA
-
-/* Define to 1 if you have `alloca', as a function or macro. */
-#undef HAVE_ALLOCA
-
-/* Define to 1 if you have  and it should be used (not on Ultrix).
-   */
-#undef HAVE_ALLOCA_H
-
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
@@ -38,13 +20,8 @@
 /* Define to the one symbol short name of this package. */
 #undef PACKAGE_TARNAME
 
+/* Define to the home page for this package. */
+#undef PACKAGE_URL
+
 /* Define to the version of this package. */
 #undef PACKAGE_VERSION
-
-/* If using the C implementation of alloca, define if you know the
-   direction of stack growth for your system; otherwise it will be
-   automatically deduced at run-time.
-   STACK_DIRECTION > 0 => grows toward higher addresses
-   STACK_DIRECTION < 0 => grows toward lower addresses
-   STACK_DIRECTION = 0 => direction of growth unknown */
-#undef STACK_DIRECTION
-- 
2.8.0

[PATCH 2/4] Don't use deprecated acconfig.h for DEBUGGING

[Peter Foley]

Use the 3-arg form of AC_DEFINE.

winsup/cygwin/ChangeLog:
acconfig.h: Remove DEBUGGING define.
configure.ac: Add description to DEBUGGING define.
config.h.in: Regenerate.
configure: Ditto.

Signed-off-by: Peter Foley 
---
 winsup/cygwin/acconfig.h   | 3 ---
 winsup/cygwin/config.h.in  | 6 +++---
 winsup/cygwin/configure| 3 ++-
 winsup/cygwin/configure.ac | 2 +-
 4 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/winsup/cygwin/acconfig.h b/winsup/cygwin/acconfig.h
index 2f8d58c..ffe9f81 100644
--- a/winsup/cygwin/acconfig.h
+++ b/winsup/cygwin/acconfig.h
@@ -1,6 +1,3 @@
-/* Define if DEBUGGING support is requested.  */
-#undef DEBUGGING
-
 /* Define if MALLOC_DEBUGGING support is requested.  */
 #undef MALLOC_DEBUG
 
diff --git a/winsup/cygwin/config.h.in b/winsup/cygwin/config.h.in
index 39eb968..32f191a 100644
--- a/winsup/cygwin/config.h.in
+++ b/winsup/cygwin/config.h.in
@@ -1,13 +1,13 @@
 /* config.h.in.  Generated from configure.ac by autoheader.  */
-/* Define if DEBUGGING support is requested.  */
-#undef DEBUGGING
-
 /* Define if MALLOC_DEBUGGING support is requested.  */
 #undef MALLOC_DEBUG
 
 /* Define if using new vfork functionality. */
 #undef NEWVFORK
 
+/* Define if DEBUGGING support is requested. */
+#undef DEBUGGING
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/winsup/cygwin/configure b/winsup/cygwin/configure
index 8e69354..5f67d1f 100755
--- a/winsup/cygwin/configure
+++ b/winsup/cygwin/configure
@@ -4429,7 +4429,8 @@ fi
 # Check whether --enable-debugging was given.
 if test "${enable_debugging+set}" = set; then :
   enableval=$enable_debugging; case "${enableval}" in
-yes)$as_echo "#define DEBUGGING 1" >>confdefs.h
+yes)
+$as_echo "#define DEBUGGING 1" >>confdefs.h
  ;;
 no) ;;
 esac
diff --git a/winsup/cygwin/configure.ac b/winsup/cygwin/configure.ac
index efef76f..88e9694 100644
--- a/winsup/cygwin/configure.ac
+++ b/winsup/cygwin/configure.ac
@@ -66,7 +66,7 @@ AC_PROG_MAKE_SET
 AC_ARG_ENABLE(debugging,
 [ --enable-debugging   Build a cygwin DLL which has more consistency 
checking for debugging],
 [case "${enableval}" in
-yes)AC_DEFINE(DEBUGGING) ;;
+yes)AC_DEFINE([DEBUGGING],[1],[Define if DEBUGGING support is requested.]) 
;;
 no) ;;
 esac
 ])
-- 
2.8.0

Re: wget seemingly modifies file access permissions on XP

[Herbert Stocker]

Hi mihau,

On 30.03.2016 16:39, mihau wrote:
> hello,
>
> (my setup is latest cygwin 32bit on Win XP SP3, logged in as
> Administrator)
>
> I have just updated my cygwin installation after a year or so and
> stumbled upon weird behavior with its wget build. it seems to
> screw file access permissions on downloaded files, rendering e.g.
> downloaded exe files unusable (because even the administrator
> doesnt have the rights to execute them).
>
> this hasn't happened before today, but unfortunately I cannot tell
> a. whether wget was updated today at all and if it was, b. which
> version I had installed before.
>

And on 30.03.2016 19:55, mihau wrote:
> any idea why wget cygwin interferes with those things though?
> in my understanding it should just copy/save a file from a remote
> server to a local computer, without even touching file permissions or
> such. several windows batch files which I use now, either have to be
> edited and "chmod +x" added in all of them - or I'll just stick with
> wget mingw.

i just tried wget on a Linux box, and it also does not add x flags to
an .exe downloaded.

What wget does is downloading a file from an HTTP server and storing it
with default permissions. These seam to be 666 (rw-rw-rw-) with some of
the bits removed by your umask setting. (There is no x flag in (rw-rw-rw-).

We are talking about 666 or rwxrwxrwx style permissions because that's
the POSIX way of expressing permissions (untless ACLs are used).

And wget for Cygwin is a POSIX program and Cygwin translates the POSIX
system calls from wget (which are create file, write data to file,
close file, etc) to Win32 system calls that Windows can process. It
tries hard to provide a perfect POSIX environment to its applications.

On HTTP a file is just a bunch of bytes with a last modified time stamp
and a content type. HTTP does not transfer permission bits.
So if you say
> it should just copy/save a file from a remote server
> to a local computer, without even touching file permissions or such.
then this is what wget does. It downloads the file and stores it with 
default permissions.


i also find it a bit inconvenient to use chmod +x but that's correct
behaviour for wget.

And i just found out that a chmod +x is also necessary when extracting
ZIP files with unzip.


hth,

Herbert Stocker



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

[ANNOUNCEMENT] free42 1.5.7-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* free42-1.5.7-1

Free42 is a re-implementation of the HP-42S calculator and the HP-82240 
printer. It is a complete rewrite, not using any HP code, and it does not 
require an HP-42S ROM image.

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

[ANNOUNCEMENT] idfpml 2.0.1-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* idfpml-devel-2.0.1-1

Software implementation of the IEEE 754-2008 Decimal Floating-Point 
Arithmetic specification, aimed at financial applications, especially in 
cases where legal requirements make it necessary to use decimal, and not 
binary floating-point arithmetic.

These libraries are, per upstream, static-only and therefore there is
no runtime package.

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

free42 1.5.7-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* free42-1.5.7-1

Free42 is a re-implementation of the HP-42S calculator and the HP-82240 
printer. It is a complete rewrite, not using any HP code, and it does not 
require an HP-42S ROM image.

--
Yaakov

idfpml 2.0.1-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* idfpml-devel-2.0.1-1

Software implementation of the IEEE 754-2008 Decimal Floating-Point 
Arithmetic specification, aimed at financial applications, especially in 
cases where legal requirements make it necessary to use decimal, and not 
binary floating-point arithmetic.

These libraries are, per upstream, static-only and therefore there is
no runtime package.

--
Yaakov

Re: Cross compiling for cygwin under Linux.

[Michel Van den Bergh]

On 31/03/16 18:03, Yaakov Selkowitz wrote:

On 2016-03-31 10:29, Yaakov Selkowitz wrote:

On 2016-03-31 09:40, Michel Van den Bergh wrote:

Unfortunately the gcc for CentOS appears not to work...

/usr/bin/i686-pc-cygwin-gcc-4.9.3 -c test.c

*** buffer overflow detected ***:
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as
terminated

That sounds like a problem we had with mingw-binutils on EL6; we never
figured out why this only happened there, but we did find a fix.  I'll
try to have an update to cygwin-binutils later today.

Please yum update; this should be working now.


Yes it now works!

Thx,
Michel

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

[PATCH] Add without-library-checks

[Peter Foley]

When cross-compiling a toolchan targeting cygwin, building cygwin1.dll
requires libgcc.
However, building libgcc requires the cygwin headers to be
installed.
Configuring cygwin requries the mingw-crt libraries, which require the
cygwin headers to be installed.
Work around this circular dependency by adding a
--without-library-checks configure option to skip cygwin's configure checks
for valid mingw-crt libraries.
Since the mingw-crt libraries only require the cygwin headers to be
installed, this allows us to successfully configure cygwin so that we
can only install the headers without trying to build any
libraries.

winsup/ChangeLog
configure.ac: add without-library-checks option
configure: regenerate
winsup/cygserver/ChangeLog
configure.ac: don't check AC_WINDOWS_LIBS when using without-library-checks
configure: regenerate
winsup/cygwin/ChangeLog
configure.ac: don't check AC_WINDOWS_LIBS when using without-library-checks
configure: regenerate

Signed-off-by: Peter Foley 
---
 winsup/configure  | 14 ++
 winsup/configure.ac   |  5 -
 winsup/cygserver/configure|  2 ++
 winsup/cygserver/configure.ac |  9 ++---
 winsup/cygwin/configure   |  2 ++
 winsup/cygwin/configure.ac| 11 +++
 6 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/winsup/configure b/winsup/configure
index 541c81b..5abf793 100755
--- a/winsup/configure
+++ b/winsup/configure
@@ -666,6 +666,7 @@ ac_subst_files=''
 ac_user_opts='
 enable_option_checking
 with_mingw_progs
+with_library_checks
 with_windows_headers
 with_windows_libs
 '
@@ -1297,6 +1298,9 @@ Optional Packages:
   --without-PACKAGE   do not use PACKAGE (same as --with-PACKAGE=no)
   --without-mingw-progs   do not build programs using the mingw toolchain
   (useful for cross-compiling)
+  --without-library-checks
+  do not check for valid w32api libraries (useful for
+  bootstraping a cross-compiler)
   --with-windows-headers=DIR
   specify where the windows includes are located
   --with-windows-libs=DIR specify where the windows libraries are located
@@ -3370,6 +3374,14 @@ else
 fi
 
 
+# Check whether --with-library_checks was given.
+if test "${with_library_checks+set}" = set; then :
+  withval=$with_library_checks;
+else
+  with_library_checks=yes
+fi
+
+
 
 
 # Check whether --with-windows-headers was given.
@@ -3379,6 +3391,7 @@ if test "${with_windows_headers+set}" = set; then :
 fi
 
 
+if test "x$with_library_checks" != "xno"; then
 
 
 # Check whether --with-windows-libs was given.
@@ -3397,6 +3410,7 @@ fi
 
 
 
+fi
 
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
diff --git a/winsup/configure.ac b/winsup/configure.ac
index b04f044..3c27674 100644
--- a/winsup/configure.ac
+++ b/winsup/configure.ac
@@ -26,9 +26,12 @@ AC_PROG_CXX
 AC_PROG_CPP
 AC_LANG(C)
 AC_ARG_WITH([mingw-progs],[AS_HELP_STRING([--without-mingw-progs],[do not 
build programs using the mingw toolchain (useful for 
cross-compiling)])],[],[with_mingw_progs=yes])
+AC_ARG_WITH([library_checks],[AS_HELP_STRING([--without-library-checks],[do 
not check for valid w32api libraries (useful for bootstraping a 
cross-compiler)])],[],[with_library_checks=yes])
 
 AC_WINDOWS_HEADERS
-AC_WINDOWS_LIBS
+if test "x$with_library_checks" != "xno"; then
+AC_WINDOWS_LIBS
+fi
 
 AC_LANG(C++)
 
diff --git a/winsup/cygserver/configure b/winsup/cygserver/configure
index 37caf57..c2112ed 100755
--- a/winsup/cygserver/configure
+++ b/winsup/cygserver/configure
@@ -3381,6 +3381,7 @@ if test "${with_windows_headers+set}" = set; then :
 fi
 
 
+if test "x$with_library_checks" != "xno"; then
 
 
 # Check whether --with-windows-libs was given.
@@ -3399,6 +3400,7 @@ fi
 
 
 
+fi
 
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
diff --git a/winsup/cygserver/configure.ac b/winsup/cygserver/configure.ac
index 5d1464b..3c96a57 100644
--- a/winsup/cygserver/configure.ac
+++ b/winsup/cygserver/configure.ac
@@ -9,7 +9,7 @@ dnl details.
 dnl
 dnl Process this file with autoconf to produce a configure script.
 
-AC_PREREQ(2.59)
+AC_PREREQ([2.59])
 AC_INIT([Cygwin 
Cygserver],[0],[cyg...@cygwin.com],[cygwin],[https://cygwin.com])
 AC_CONFIG_SRCDIR(cygserver.cc)
 AC_CONFIG_AUX_DIR(..)
@@ -26,7 +26,9 @@ AC_PROG_CPP
 AC_LANG(C)
 
 AC_WINDOWS_HEADERS
-AC_WINDOWS_LIBS
+if test "x$with_library_checks" != "xno"; then
+  AC_WINDOWS_LIBS
+fi
 
 AC_LANG(C++)
 
@@ -65,4 +67,5 @@ esac
 ])
 
 AC_CONFIGURE_ARGS
-AC_OUTPUT(Makefile)
+AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
diff --git a/winsup/cygwin/configure b/winsup/cygwin/configure
index aa26015..8e69354 100755
--- a/winsup/cygwin/configure
+++ b/winsup/cygwin/configure
@@ -3392,6 +3392,7 @@ if test "${with_windows_headers+set}" = set; then :
 fi
 
 
+if test "x$with_library_checks" != "xno"; then
 
 
 # Check whether --with-windows-libs was given.
@@ -3410,6 +3411,7 @@ fi
 
 
 
+fi
 
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'

[PATCH v2] Refactor to avoid nonnull checks on "this" pointer.

[Peter Foley]

G++ 6.0 asserts that the "this" pointer is non-null for member functions.
Refactor methods that check if this is non-null to be static where
necessary, and remove the check where it is unnecessary.

winsup/cygwin/ChangeLog
external.cc (cygwin_internal): Call _pinfo::cmdline staticly
cygheap.h (fcwd_access_t::Free): Make static
fhandler_dsp.cc (Audio_in::buf_info): Ditto.
fhandler_dsp.cc (Audio_out::buf_info): Ditto.
pinfo.h (_pinfo::fd): Ditto.
pinfo.h (_pinfo::fds): Ditto.
pinfo.h (_pinfo::root): Ditto.
pinfo.h (_pinfo::cwd): Ditto.
pinfo.h (_pinfo::cmdline): Ditto.
pinfo.h (_pinfo::kill): Ditto.
pinfo.h (_pinfo::exists): Ditto.
pinfo.h (_pinfo::exists): Use __reg2, as a consequence of the added
argument.
pinfo.h (_pinfo::kill): Use __reg3, as a consequence of the added
argument.
fhandler_dsp.cc (Audio_out::buf_info): Refactor method to take object
explicity, rather then relying on potentially null "this" pointer.
fhandler_dsp.cc (Audio_in::buf_info): Ditto.
path.cc (fcwd_access_t::Free): Ditto.
pinfo.cc (_pinfo::exists): Ditto.
pinfo.cc (_pinfo::fd): Ditto.
pinfo.cc (_pinfo::fds): Ditto.
pinfo.cc (_pinfo::root): Ditto.
pinfo.cc (_pinfo::cwd): Ditto.
pinfo.cc (_pinfo::cmdline): Ditto.
signal.cc (_pinfo::kill): Ditto.
pinfo.cc (_pinfo::exists): Use __reg2, as a consequence of the added
argument.
signal.cc (_pinfo::kill): Use __reg3, as a consequence of the added
argument.
pinfo.cc (_pinfo::commune_request): remove non-null check on "this", as
this method is only called from pinfo.cc after null checks
pinfo.cc (_pinfo::pipe_fhandler): remove non-null check on "this", as
this method is only called from pipe.cc (fhandler_pipe::open) after a null 
check.
fhandler_dsp.cc (Audio_in::buf_info): Move blockSize call inside
conditional.
fhandler_dsp.cc (fhandler_dev_dsp::_ioctl): Call Audio_out::buf_info staticly.
fhandler_dsp.cc (fhandler_dev_dsp::_ioctl): Call Audio_in::buf_info staticly.
fhandler_process.cc (format_process_fd): Call _pinfo::fds staticly.
fhandler_process.cc (format_process_fd): Call _pinfo::fd staticly.
fhandler_process.cc (format_process_root): Call _pinfo::root staticly.
fhandler_process.cc (format_process_cwd): Call _pinfo::cwd staticly.
fhandler_process.cc (format_process_cmdline): Call _pinfo::cmdline staticly.
fhandler_termios.cc (tty_min::kill_pgrp): Call _pinfo::exists staticly.
fhandler_termios.cc (tty_min::is_orphaned_process_group): Call _pinfo::exists 
staticly.
signal.cc (kill0): Call _pinfo::kill staticly.
signal.cc (kill_pgrp): Call _pinfo::exists staticly.
signal.cc (kill_pgrp): Call _pinfo::kill staticly.
sigproc.cc (pid_exists): Call _pinfo::exists staticly.
sigproc.cc (remove_proc): Call _pinfo::exists staticly.
times.cc (clock_gettime): Call _pinfo::exists staticly.
times.cc (clock_getcpuclockid): Call _pinfo::exists staticly.

Signed-off-by: Peter Foley 
---

I'm not 100% sure that the __reg1/2->__reg2/3 changes are necessary,
but i'm pretty confident about everything else.

 winsup/cygwin/cygheap.h   |  2 +-
 winsup/cygwin/external.cc |  2 +-
 winsup/cygwin/fhandler_dsp.cc | 36 
 winsup/cygwin/fhandler_process.cc | 10 +++
 winsup/cygwin/fhandler_termios.cc |  4 +--
 winsup/cygwin/path.cc | 10 +++
 winsup/cygwin/pinfo.cc| 58 +++
 winsup/cygwin/pinfo.h | 14 +-
 winsup/cygwin/signal.cc   | 28 +--
 winsup/cygwin/sigproc.cc  |  4 +--
 winsup/cygwin/times.cc|  4 +--
 11 files changed, 87 insertions(+), 85 deletions(-)

diff --git a/winsup/cygwin/cygheap.h b/winsup/cygwin/cygheap.h
index c394e7f..75c27f0 100644
--- a/winsup/cygwin/cygheap.h
+++ b/winsup/cygwin/cygheap.h
@@ -281,7 +281,7 @@ class fcwd_access_t {
 
 public:
   void CopyPath (UNICODE_STRING );
-  void Free (PVOID heap);
+  static void Free (fcwd_access_t *cwd, PVOID heap);
   void FillIn (HANDLE dir, PUNICODE_STRING name, ULONG old_dismount_count);
   static void SetDirHandleFromBufferPointer (PWCHAR buf_p, HANDLE dir);
   static void SetVersionFromPointer (PBYTE buf_p, bool is_buffer);
diff --git a/winsup/cygwin/external.cc b/winsup/cygwin/external.cc
index 02335eb..8bcadc4 100644
--- a/winsup/cygwin/external.cc
+++ b/winsup/cygwin/external.cc
@@ -342,7 +342,7 @@ cygwin_internal (cygwin_getinfo_types t, ...)
  size_t n;
  pid_t pid = va_arg (arg, pid_t);
  pinfo p (pid);
- res = (uintptr_t) p->cmdline (n);
+ res = (uintptr_t) _pinfo::cmdline (p, n);
}
break;
   case CW_CHECK_NTSEC:
diff --git a/winsup/cygwin/fhandler_dsp.cc b/winsup/cygwin/fhandler_dsp.cc
index 9fa2c6e..52d3e59 100644
--- a/winsup/cygwin/fhandler_dsp.cc
+++ b/winsup/cygwin/fhandler_dsp.cc
@@ -116,7 +116,7 @@ class fhandler_dev_dsp::Audio_out: public Audio
   bool start ();
   void stop (bool immediately = false);
   int write (const char *pSampleData, int nBytes);
-  void buf_info (audio_buf_info 

Re: Cross compiling for cygwin under Linux.

[Yaakov Selkowitz]

On 2016-03-31 10:29, Yaakov Selkowitz wrote:

On 2016-03-31 09:40, Michel Van den Bergh wrote:

Unfortunately the gcc for CentOS appears not to work...

/usr/bin/i686-pc-cygwin-gcc-4.9.3 -c test.c

*** buffer overflow detected ***:
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as
terminated


That sounds like a problem we had with mingw-binutils on EL6; we never
figured out why this only happened there, but we did find a fix.  I'll
try to have an update to cygwin-binutils later today.


Please yum update; this should be working now.

--
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: Cross compiling for cygwin under Linux.

[Yaakov Selkowitz]

On 2016-03-31 09:40, Michel Van den Bergh wrote:

On 03/30/2016 06:19 PM, Yaakov Selkowitz wrote:

On 2016-03-30 10:24, Michel Van den Bergh wrote:

I am one of the authors of an application (
https://sourceforge.net/projects/icsdrone/ ) written for POSIX and I
would like to provide a Windows binary.

As I do not use Windows I would like to cross compile on Linux.

I cannot use Mingw as our application relies heavily on the select()
call.

So my question is: is it possible to cross compile a Cygwin binary on
Linux?


Yes it is.  Packages for Fedora and RHEL/CentOS are available here:

https://copr.fedorainfracloud.org/coprs/yselkowitz/cygwin/


Unfortunately the gcc for CentOS appears not to work...

/usr/bin/i686-pc-cygwin-gcc-4.9.3 -c test.c

*** buffer overflow detected ***:
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as
terminated


That sounds like a problem we had with mingw-binutils on EL6; we never 
figured out why this only happened there, but we did find a fix.  I'll 
try to have an update to cygwin-binutils later today.


--
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: windows exit codes truncated to 1 Byte

[Eric Blake]

On 03/31/2016 07:30 AM, Björn Stabel wrote:
> Am 31.03.2016 um 15:01 schrieb Cristian:
>> I noted that exit codes returned by CMD and other apps (msiexec) are 
>> truncated to 1 byte (0 .. 255).

This matches Linux, but not POSIX.

>> Windows exit codes are represented using 32 bits, so is this limitation 
>> intentional?

Part intentional (we do what Linux does), and part accidental (Cygwin
handles the return status slightly different than Windows, and that
handling makes it impossible to easily preserve all 32-bits, even if
Linux were to be patched to obey POSIX).

> POSIX specifies that the lower 8 bits of the exit status be made
> available to the caller of wait/waitpid:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html

Correct: wait() and waitpid() can only return 8 bits; but POSIX states
that waitid() MUST be able to access all 32-bits untruncated; this is
where Linux gets it wrong (Linux truncates during exit(), so waitid()
can only return 8 bits; other operating systems do NOT truncate during
exit, but preserve all 32 bits; if you use wait() or waitpid() you only
get 8 bits, but if you use waitid() you can see the full 32 bits).

> Maybe there's another way to get the entire status value, but this looks
> like a POSIX limitation to me.
> Cygwin is conformant here.

Cygwin is only partially conformant here.

See also: http://austingroupbugs.net/view.php?id=947

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



signature.asc
Description: OpenPGP digital signature

Re: GCC package missing sanitize helper libraries

[Yaakov Selkowitz]

On 2016-03-31 09:08, Peter Foley wrote:

The cygwin gcc package appears to be missing the helper libraries for
the -fsanitize series of options.


These are only supported on x86-linux.

--
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: Cross compiling for cygwin under Linux.

[Michel Van den Bergh]

On 03/30/2016 06:19 PM, Yaakov Selkowitz wrote:

On 2016-03-30 10:24, Michel Van den Bergh wrote:

I am one of the authors of an application (
https://sourceforge.net/projects/icsdrone/ ) written for POSIX and I
would like to provide a Windows binary.

As I do not use Windows I would like to cross compile on Linux.

I cannot use Mingw as our application relies heavily on the select() 
call.


So my question is: is it possible to cross compile a Cygwin binary on
Linux?


Yes it is.  Packages for Fedora and RHEL/CentOS are available here:

https://copr.fedorainfracloud.org/coprs/yselkowitz/cygwin/


Unfortunately the gcc for CentOS appears not to work...

/usr/bin/i686-pc-cygwin-gcc-4.9.3 -c test.c

*** buffer overflow detected ***: 
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as 
terminated

=== Backtrace: =
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f3c5d31e567]
/lib64/libc.so.6(+0x100450)[0x7f3c5d31c450]
/lib64/libc.so.6(__strncpy_chk+0x17b)[0x7f3c5d31b71b]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x442454]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x4429ee]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x45c3db]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x445fd1]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x417ab0]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x4059a0]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x4bb747]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x4bb7f6]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x40563c]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7f3c5d23ad5d]
/usr/lib/gcc/i686-pc-cygwin/4.9.3/../../../../i686-pc-cygwin/bin/as[0x402b19]
=== Memory map: 


test.c:

int main(){
return 0;
}

Is there any hope left?

Best regards,
Michel




--
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: wget seemingly modifies file access permissions on XP

[Corinna Vinschen]

On Mar 30 19:55, mihau wrote:
> >Btw., if you wget a file it's *supposed* to be non-executable.  Assuming
> >your umask is 0022, the file will be create with 0644 permissions.  The
> >default ACL created in this case explicitely disables execution for the
> >admin user if the admin user is part of the ACL.  Just run `chmod +x'
> >afterwards if that's the only problem.
> 
> I specifically meant exe as in windows executables, files w/ .exe suffix;
> just tried "chmod +x" and you are correct, it works, my helloworld.exe
> became executable indeed. thank you for that.
> 
> any idea why wget cygwin interferes with those things though?
> in my understanding it should just copy/save a file from a remote server
> to a local computer, without even touching file permissions or such.

That's not how it works.  Consider that the file wget downloads
doesn't exist yet on your side.  When creating the file on your
local machine, wget has to call open(2) with a set of permisssions.
The set of permissions given by wget does *not* contain an execute
bit.

The old permission implementation in Cygwin ignored this fact for
ACEs inherited from the parent directory.  This, however, leads to
incorrect POSIX permission bits if implemanted correctly.  The
recent versions of Cygwin starting with version 2.4.0 strive to
implement the POSIX permission and ACL handling as correct as possible.
And this in turn requires to reflect the correct execute permission
setting also in the ACEs inherited from the parent dir.

That's why a file downloaded with wget does not have execute permissions
at all by default.  wget doesn't request them, and for the ACEs inherited
from the parent dir Cygwin removes the execute permissions to follow suit.

Bottom line, either use rsync if possible, or when using wget try if
the --preserve-permissions option fixes your problem.  Alternatively,
fall back to chmod +x.


HTH,
Corinna

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


signature.asc
Description: PGP signature

GCC package missing sanitize helper libraries

[Peter Foley]

The cygwin gcc package appears to be missing the helper libraries for
the -fsanitize series of options.

$ gcc -fsanitize=address a.c
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lasan
collect2: error: ld returned 1 exit status

Ditto for -fsanitize=undefined (-lubsan), -fsanitize=thread (-ltsan),
and -fsanitize-leak (-llsan)

On my linux box, these libraries are at paths like
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/liblsan.so

Is this simply a packaging oversight, or are these flags broken on cygwin?

Thanks,

Peter Foley

--
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: windows exit codes truncated to 1 Byte

[Björn Stabel]

Am 31.03.2016 um 15:01 schrieb Cristian:
> I noted that exit codes returned by CMD and other apps (msiexec) are 
> truncated to 1 byte (0 .. 255).
>
> Steps to reproduce:
>
> 1) Create a batch with this content:
> $ cat ./test.bat 
> @echo off 
> rem  
> echo Test exit code 266 
> exit /B 266 
> rem  
>
> 2) run the batch file:
> $ ./test.bat 
> Test exit code 266 
>
> 3) check exit code
> $ echo $? 
> 10 
>
>
> I would expect 266 but I got 10 instead. I checked for other codes and the 
> result is the same. 
> Windows exit codes are represented using 32 bits, so is this limitation 
> intentional?
POSIX specifies that the lower 8 bits of the exit status be made
available to the caller of wait/waitpid:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html

"WEXITSTATUS(stat_val) - If the value of WIFEXITED(stat_val) is
non-zero, this macro evaluates to the low-order 8 bits of the status
argument that the child process passed to _exit() or exit(), or the
value the child process returned from main()."

Maybe there's another way to get the entire status value, but this looks
like a POSIX limitation to me.
Cygwin is conformant here.

The more interesting problem is what happens if you do "exit /B 256" in
your batch.
In that case, bash would show a return status of zero.
That's what the WIFEXITED macro is used for. Not sure how you'd get that
from bash, though.

>
>
> Best regards,
> Cristi
>
> --
> 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
>
>


--
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: [attention p7zip maintainer] p7zip 15.14 is out

[Gerrit Haase]

2016-03-19 15:12 GMT+01:00 Achim Gratz wrote:
>
> You might also want to add 'DEPEND="nasm"', since the build needs it
> (probably other stuff too, but I already had that installed).

Hello Achim,

is is common sense nowadays, to add packages required to build from
source to the executable runtime dependencies?


Regards,
Gerrit
=^..^=

--
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: Upcoming change to TeX Live on Cygwin

[Ken Brown]

On 3/30/2016 5:16 PM, Ken Brown wrote:

I am in the process of discussing this with Norbert Preining[2],
starting at http://tug.org/pipermail/tldistro/2016q1/000259.html.  We
have arrived at an agreement as to how to modify tlmgr to do what I
want.  (The modification may or may not make it into upstream TeX Live,
but Norbert has indicated that he might use it in Debian.)


Update: The modification has just been installed in the TeX Live trunk 
as a documented way for distros to include a restricted tlmgr that 
doesn't interfere with package managers.


Ken

Re: Packages not found by setup 2.873

[EMMANUELLE FOURNIER]

Good Morning,

First of all, thank you for answering me.

 - For packages format, I'm not an expert,  so I've changed in tar.bz2, because 
in the x86 version of program, they were in tar.bz2.
But if you mean that is not a cause, I will modify this.

 - I've modified setup in order to find packages in tar.bz2 instead of tar.xz.

 - There were errors for each packages, a pop-up came each time with the 
following message  : "Can't open (null) for readind : no such file"

 - I really think that this command work, but I don't know where can be the 
error, so I'm searching everywhere.



$INSTDIR doesn't include a network drive letter : " InstallDir 
"C:\D3IPARAM\setup_cygwin" "

I will try again, without changed format. I really have to download first, then 
install, because it will be deployed.


var/log/setup.log, in my two last try :

2016/03/25 16:21:03 Starting cygwin install, version 2.873
2016/03/25 16:21:03 User has backup/restore rights
2016/03/25 16:21:03 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No 
such file or directory
2016/03/25 16:21:03 Current Directory: C:\D3IPARAM\setup_cygwin\cygwin-setup
2016/03/25 16:21:03 Could not open service McShield for query, start and stop. 
McAfee may not be installed, or we don't have access.
2016/03/25 16:21:09 source: from local dir
2016/03/25 16:21:10 root: c:\cygwin system
2016/03/25 16:21:12 Selected local directory: 
C:\D3IPARAM\setup_cygwin\cygwin-setup
2016/03/25 16:21:12 io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 
No such file or directory
2016/03/25 16:21:28 Selected local directory: 
C:\D3IPARAM\setup_cygwin\cygwin-setup\http%3a%2f%2fcygwin.gicm.net%3a8080%2f
2016/03/25 16:21:39 mbox note: Can't open (null) for reading: No such file
2016/03/25 16:25:33 Changing gid back to original
2016/03/25 16:25:33 Changing gid to Administrators
2016/03/25 16:25:46 mbox note: Can't open (null) for reading: No such file
2016/03/25 16:55:39 mbox note: Can't open (null) for reading: No such file
2016/03/25 16:55:40 Changing gid back to original
2016/03/25 16:55:40 Changing gid to Administrators
2016/03/25 16:56:41 mbox note: Can't open (null) for reading: No such file
2016/03/30 08:44:04 mbox note: Can't open (null) for reading: No such file
2016/03/30 08:44:05 mbox note: Can't open (null) for reading: No such file
2016/03/30 08:44:06 Changing gid back to original
2016/03/30 08:44:06 Changing gid to Administrators
2016/03/30 08:44:08 note: Nothing needed to be installed
2016/03/30 08:44:08 Ending cygwin install


And I can try without "-C base".


That's my new try :

- I've downloaded
- Next, I've copied my fresh repository in $INSTDIR
- I've recompiled NSIS to create my new setup.exe
- On my target computer, I've executed setup.exe : files have been copied, but 
no packages installed

New setup.log :


2016/03/31 09:51:37 Starting cygwin install, version 2.873
2016/03/31 09:51:37 User has backup/restore rights
2016/03/31 09:51:37 Current Directory: C:\D3IPARAM\setup_cygwin\cygwin-setup
2016/03/31 09:51:37 Could not open service McShield for query, start and stop. 
McAfee may not be installed, or we don't have access.
2016/03/31 09:51:37 root: c:\cygwin system
2016/03/31 09:51:37 Selected local directory: 
C:\D3IPARAM\setup_cygwin\cygwin-setup
2016/03/31 09:51:38 Changing gid back to original
2016/03/31 09:51:38 Changing gid to Administrators
2016/03/31 09:51:38 Ending cygwin install


A final information : I've made it with x86 setup on x64 target machine. Is it 
a problem ? I don't think so, but I still wonder.


Thank you by advance.


Regards,

Emmanuelle FOURNIER
E-mail : emmanuelle.fourn...@partnre.com

--
Ce message et  toutes les pieces jointes (ci-apres  le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute  utilisation ou  diffusion  non autorisee  est interdite.   Tout
message  etant  susceptible  d'alteration,  l'emetteur  decline  toute
responsabilite au titre de  ce message  s'il a  ete altere, deforme ou
falsifie.
---
This message and any  attachments (the "message") are confidential and
intended  solely   for  the   addressees.  Any  unauthorised   use  or
dissemination is prohibited. As e-mails are susceptible to alteration,
the issuer shall  not be  liable for  the  message if altered, changed
or falsified.

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

[ANNOUNCEMENT] ttfautohint 1.5-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* ttfautohint-1.5-1
* ttfautohint-gui-1.5-1

ttfautohint provides a 99% automated hinting process and a platform for 
finely hand-hinting the last 1%. It is ideal for web fonts and supports 
many scripts.

This is an update to the latest upstream release.

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

ttfautohint 1.5-1

[Yaakov Selkowitz]

The following packages have been uploaded to the Cygwin distribution:

* ttfautohint-1.5-1
* ttfautohint-gui-1.5-1

ttfautohint provides a 99% automated hinting process and a platform for 
finely hand-hinting the last 1%. It is ideal for web fonts and supports 
many scripts.

This is an update to the latest upstream release.

--
Yaakov