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 t

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 su

Re: build library libmad

any errors. > > But, no dll is made. 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://gith

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

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: http://cygwin.com/problems.h

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

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

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

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 swit

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 f

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

tion, 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 noti

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 allo

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 wal