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 that interferes cygwin's fork(). -- 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
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 succeeds in forking a child (ls or something). Also, I cannot launch 64bit mintty.exe from 32bit cmd.exe. It always fails in a error dialog saying that: mintty: could not detach from caller Try '--help' for more information. When launching from 64bit app, this issue doesn't happen. -- 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: build library libmad
(2013/11/15 1:01), d.henman wrote: > Building libmad > > I download an attempted to build libmad-0.15.1b. with the build shared > option set. > > Options to --force-mem and addr were deleted as unneccessary anymore. > > The configure and make process proceed without 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://github.com/nu774/libmad -- 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: 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_extension(ext) File "/usr/src/python3-3.3.2-3/src/Python-3.3.2/setup.py", line 279, in build_extension if not self.configure_ctypes(ext): File "/usr/src/python3-3.3.2-3/src/Python-3.3.2/setup.py", line 1807, in configure_ctypes exec(f.read(), globals(), fficonfig) File "", line 33, in KeyError: 'X86_WIN64' Makefile:505: recipe for target 'sharedmods' failed At this point I'm stuck... any advice from the gurus out there would be appreciated. -- 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: 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 profiles. Cygwin's layout of OPENSSLDIR(/usr/ssl) is simply the same as default OpenSSL installation. So I think there's no special intention on Cygwin side. -- 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: 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: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
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.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
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-certificate package. As far as I can see (using strings cygcrypto-1.0.0.dll | grep or something), default store file for OpenSSL is configured as /usr/ssl/cert.pem and directory is /usr/ssl/certs/. Therefore I tried ln -s /usr/ssl/certs/ca-bundle.crt /usr/ssl/cert.pem and it works. Now I can use wget without --no-check-certificate. Is it possible to link ca-bundle.crt to /usr/ssl/cert.pem like above on ca-certificates package installation? -- 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: 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 compatible with > the other mingw-w64 binary packages. > > Alternatively, you can just use boost. -- 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: 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 cygwin installation from Cygwin 1.7.24 (64 bit release) to Cygwin 1.7.25 on W7. Setup (most recent version from cygwin.com) didn't succeed because of "incomplete download". I tried severel different mirrors, everytime the same problem. Then I removed the cygwin installation, i.e. deleted the folder, tried to install again and got the same error. Disabeling all Virusscanner and Firewall software didn't help. Defenitely it is not a problem of lack of discspace or something like that. A test with the 32 bit release (Cygwin 1.7.24) worked fine without any issue. On W8 i had exactely the same behaviour. Regards Helmut -- 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
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 switch. Since libwinpthread is already included in mingw64 package, I think --enable-pthread --enable-libstdcxx-threads --enable-libstdcxx-time=yes will be enough to support c++11 threading. -- 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
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 fontconfig package as a dependency of Tk? -- 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: 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. Please give it a try as soon as it hits your favorite mirror. Thanks, Corinna -- 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: shell-init: error retrieving current directory
Hi, It seems that getcwd() of bash continues the following approach until it reaches /. 1) readdir() on the parent directory. 2) for each dirent returned by readdir(), find the entry that matches the current dirctory (by comparing inode or something). 3) set parent dir as current, and continue from 1). When you call getcwd() not under / (that is, C:/cygwin64), say /c/foo/bar (here I assume C drive is mounted on /c), step 2) will fail when current is /c, since readdir() on / doesn't return c as a dirent. In short, getcwd() of bash doesn't work as expected in this situation, 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 of cygwin32 is also using it's own getcwd WITHOUT issue. Still, why does it fail on 64 bit but not on 32 bit? Cygwin's path handling code is identical for both platforms. Corinna -- 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: 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 allocating buffer). At least that is my understanding after observing the source code. 2) Also, this happens if you cross-compile bash (because this can't be autodetected when cross-compiling, and configure assumes the worst). -- 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: 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 walker or something. You can easily see that bash.exe has it's own getcwd symbol, and it's not imported from cygwin1.dll. Therefore, I downloaded bash source package from setup-x86_64.exe anyway to see what's happening, and built bash with cygport. Surprisingly, I got working bash.exe with HAVE_GETCWD enabled, without patching anything. This one, of course, imports getcwd from cygwin1.dll, and is free from the issue. So I don't know why the HAVE_GETCWD was disabled on the official build, but I think simple re-building and re-distributing of bash.exe will solve this issue. -- 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
