fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

After upgrading to Windows 10 TH2 (ver 1511, build 10586), any attempt to launch a cygwin64 process from 32bit native app (for example, C:\windows\syswow64\cmd.exe) *always* results in a fork error. To be precise, I can execute 64bit bash.exe from 32bit cmd.exe. However, this bash process never

Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2

There must be a bug in the new CMD somewhere. But, anyway, I'll look into it when I finally managed to update my W10 test machine. No, cmd.exe is just an example. Any 32bit process can be an trigger. I guess something has changed in TH2 kernel regarding process memory management or something

Re: build library libmad

. I can only see .lo files and one libmad.la Has anyone there had experience with getting a dll available for use? You have to add -no-undefined to libmad_la_LDFLAGS in Makefile.am. Alternatively, you can try this: https://github.com/nu774/libmad -- Problem reports: http

Re: Unable to compile python 3.3 [Was: Re: Python 3.3 coming soon?]

Installing libffi-devel will let python pick system libffi, so you can skip that libffi building part you are currently stuck. (2013/10/15 10:10), Ryan Johnson wrote: /usr/src/python3-3.3.2-3/src/Python-3.3.2/Lib/distutils/command/build_ext.py, line 463, in build_extensions

Re: openssl man pages

(2013/10/07 1:15), Stan Moore wrote: I did a quick google with no joy so I'll throw this out here. Is there a reason the man pages for openssl install in /usr/ssl/man instead of the system /usr/share/man? It's not really a problem; it came up while doing some long overdue maintenance on my shell

Re: i686-w64-mingw32-gcc of cygwin64 is broken

Hi, These have been updated: mingw64-*-headers-3.0.0-1 mingw64-*-runtime-3.0.0-1 w32api-{headers,runtime}-3.0.0-1 Thanks, but it seems I'm already using those version. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

git-svn is broken

Currently, git-svn of Cygwin is unusable because of this: http://git.661346.n2.nabble.com/Git-pm-with-recent-File-Temp-fail-td7580381.html FYI, it was fixed on git 1.8.3: https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.3.txt -- Problem reports:

wget, OpenSSL and root CA certificates

Currently, root CA certificates of Cygwin are installed via ca-certificates package, and at least libcurl sees it. However, wget on https URL always results in verify error, since wget relies on SSL_CTX_set_default_verify_paths() of OpenSSL, but OpenSSL doesn't see certificates installed via

c++11 threading support in mingw-w64 package

It seems that mingw64-*-gcc-g++ package is not compiled with --enable-pthread, that results in no c++11 threading support. Is it intentional, or is it possible to enable it? As far as I understand, c++11 threading support can be enabled by libwinpthread of mingw-w64 project + gcc configuration

Re: Problem installing Cygwin 1.7.25 64 bit on W7 and W8

Same experience here. I once pushed continue on the incomplete download error dialog by mistake, that resulted in uninstalling of the selected packages for updates, including cygwin (except for cygwin1.dll). (2013/09/01 22:17), Helmut Billig wrote: Hello, I tried to update a well running

Re: c++11 threading support in mingw-w64 package

If it's intentional, that's OK. Thanks for response. You can enable it yourself, however this means all code will require libwinpthread, regardless of whether you actually used any pthread code. I'm not sure if users will appreciate it. Please rebuild it yourself. Keep in mind that it is not

wish(Tk) crashes without fontconfig, but fontconfig is not installed as a dependency

Hi, Without fontconfig, wish(Tk) seems to crash on the attempt to create widgets (which requires some fonts to render text) like the following: $ DISPLAY=localhost:0.0 wish % label .l -text foo --- crash It seems that libfontconfig is already installed; but is there any reason not to install

Re: shell-init: error retrieving current directory

, and if Cygwin's getcwd() implementation complies requirement by bash, HAVE_GETCWD should be enabled. As far as I can see, HAVE_GETCWD enabled bash.exe is working fine here. (2013/08/22 20:11), Corinna Vinschen wrote: On Aug 22 11:27, nu774 wrote: Hi, Thanks, I see. And I noticed bash.exe

Re: shell-init: error retrieving current directory

Thanks, 4.1.11-2 is now working fine. (2013/08/22 23:12), Corinna Vinschen wrote: Since our bash maintainer Eric is currently extremly busy, I took a stab at it and created a new bash-4.1.11-2 64-bit package. It picked up the Cygwin getcwd and didn't have the reported problem in my quick test.

Re: shell-init: error retrieving current directory

Hi, I've experienced the same issue. From what I can see: Current bash.exe of cygwin64 seems to be improperly built with HAVE_GETCWD disabled, which result in using it's own getcwd implementation in the bash source package. This can be indirectly observed by inspecting bash.exe with dependency

Re: shell-init: error retrieving current directory

Hi, Thanks, I see. And I noticed bash.exe of cygwin32 is also using it's own getcwd WITHOUT issue. (2013/08/22 11:21), LRN wrote: 1) It's not improperly disabled. Cygwin's getcwd does not behave the way bash wants it to (when called with 0 buffer and 0 buffer length, it fails, instead of