Ghostscript goes GPL
Current development branch of ghostscript is now gpl [1], as well as the latest stable release, 8.54. Current cygwin version is 8.50. I will work on a new release as I have time available - hopefully within the next week or two. Jim Phillips [1] http://lwn.net/Articles/187902/rss
src/winsup/cygwin ChangeLog cygwin.din include ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2006-06-15 17:22:56 Modified files: winsup/cygwin : ChangeLog cygwin.din winsup/cygwin/include/cygwin: version.h Log message: * cygwin.din: Export __srget_r, __swbuf_r. * include/cygwin/version.h: Bump API minor number to 156. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3542r2=1.3543 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.160r2=1.161 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.229r2=1.230
Re: Open sockets non-overlapped?
On Jun 15 12:07, Lev Bishop wrote: Actually, it's very strange. It gets stuck on the setsockopt() in fhandler_socket::close(). There's a race with the parent (which is why it didn't happen under strace or sshd -d), but if the parent gets round to doing its select() before the child does the close(), then the setsockopt() does not return until after the select() returns. I attach a short testcase which reliably demonstrates the problem for me. It doesn't use privilege separation or non-blocking sockets, so that is not the problem. I haven't investigated whether it's something to do with the way the socket is duplicated into the child (WSADuplicateSocket() versus DuplicateHandle(), and such). Just to spell it out: the problem shown in my testcase, is only exibited with overlapped sockets. Non-overlapped don't have any problem. Which is strange to me, since MSDN makes no mention of situations where setsockopt() can block. Erm... I tested your testcase and I can reproduce the hang only when using NON-overlapped sockets created with WSASocket(..., 0). It works fine with overlapped sockets created with select or WSASocket(..., WSA_FLAG_OVERLAPPED). I assume the above is just a typo? I think that's as far as I'm going to go with persuing this issue. If I need native programs to use sockets, then I'll pipe them through socat. ACK. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Open sockets non-overlapped?
On 6/15/06, Corinna Vinschen wrote: On Jun 15 12:07, Lev Bishop wrote: Just to spell it out: the problem shown in my testcase, is only exibited with overlapped sockets. Non-overlapped don't have any problem. Which is strange to me, since MSDN makes no mention of situations where setsockopt() can block. Erm... I tested your testcase and I can reproduce the hang only when using NON-overlapped sockets created with WSASocket(..., 0). It works fine with overlapped sockets created with select or WSASocket(..., WSA_FLAG_OVERLAPPED). I assume the above is just a typo? Yes, a typo, sorry about that. L
Re: debug information
Brian, thanks for the lead and helpfull information regarding SIGSEGV. Henman On 6/2/06, Brian Dessent [EMAIL PROTECTED] ... Please search the archives for the many recent threads on this topic. What you are seeing is not an actual SIGSEGV, it is a bug/limitation in gdb related to how Cygwin works internally. Here is a starting point: .. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Uninstalling cygwin
* julien (2006-06-15 06:37 +) I got problems with cygwin under WinXP and I want to uninstall it completely to re-install it correctly. Cygwin is not in the Windows Configuration panel/Uninstall I first deleted the Cygwin root folder and all subfolders, then I re-installed Gygwin, but now, when doing a make to install a program, I fall into an endless loop. The FAQ to uninstall tells: you can list all services you have installed with cygrunsrv -L but when I type this command I get an Command not found message. How can I unstall Cygwin completely? http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Has anybody built emacs from the source package ?
Hello, everybody, I want to install emacs in my MontaVista environment, so I downloaded the Cygwin sources for it (I succeeded in installing rxvt in the same environment). I unpack it and there are two files, a build and installation script, and the complete sources as tar.gz. However, when I run the script, I always get the error ./emacs-21.3.50.install: line 3252: emacs-21.3.50-2.new/emacs-el/setup.hint: No such file or directory I get an extra directory 'emacs-21.3.50-2.new', containing a file 'emacs-21.3.50-2-src.tar.bz2' and a file 'setup.hint'. The tar.bz2 file again contains a tar.gz file and an install script with the same names as in the original package. Any experiences and advice in this area ? Bye, Jurgen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
On Jun 14 19:30, [EMAIL PROTECTED] wrote: On Wed, Jun 14, 2006 at 10:40:25PM +0200, Corinna Vinschen wrote: Thanks very much for your testcase. I applied a patch to Cygwin, please give the next developer snapshot from http://cygwin.com/snapshots/ a try. Corinna Thank you Corinna. This appears to work much better and expected. BTW: I think the same issue may also exist for both read() and write() and possibly any other read, write, send, recv variant when using multiple threads as opposed to single thread + select(). One thing I notice is that if a read() is in progress and one is currently sitting in select(), all other read()s in seperate select()s will then stall if the former read() times out or takes longer than expected. Your observation is correct, the same issue exists for recv/send and, FWIW, connect. I can fix the connect case, too, but there is no easy patch for the recv/send case, unfortunately. This has to do with the way WSAEventSelect is handled in WinSock. For now, if you want concurrency, either use non-blocking recv/send exclusively, or never spread handling of the same blocking socket over multiple threads. Hopefully I can come up with a solution for this problem at one point. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: listen/accept/fork behavior problem between cygwin1 1.5.18 and cygwin1.dll 1.5.19
On Thu, Jun 15, 2006 at 09:58:40AM +0200, Corinna Vinschen wrote: thread + select(). One thing I notice is that if a read() is in progress and one is currently sitting in select(), all other read()s in seperate select()s will then stall if the former read() times out or takes longer than expected. Your observation is correct, the same issue exists for recv/send and, FWIW, connect. I can fix the connect case, too, but there is no easy patch for the recv/send case, unfortunately. This has to do with the way WSAEventSelect is handled in WinSock. For now, if you want concurrency, either use non-blocking recv/send exclusively, or never spread handling of the same blocking socket over multiple threads. Hopefully I can come up with a solution for this problem at one point. Corinna Actually the behaviour I'm noticing is within the same calling thread. For instance, in almost all of my network functions I'm passing an fd and using that fd with select to handle timeouts (connect/read/write all NB). So in each case the same calling thread is doing the typical sequence: socket - connect - write - read - close. The fd returned by socket() is never used outside of that thread. So instead of a single thread w/ a single select and iterating over multiple fds, post-select(), I have a thread pool with only one fd-used-at-once-per-thread but multiple threads executing concurrently. When a seperate fd entirely exhibits a read() timeout, it appears to affect read/write in all other threads using different fds. Basically, as long as data is flowing in all threads, there is no issue - but the second any one fd stalls in any given thread - they all stall until I close that fd after read() times out (where select() is indicating the timeout). You can see the implementation of these network functions in the original test case. I basically have a thread pool with each thread calling those functions in the same order socket, connect, write, read, close. -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On 15 Jun 2006 at 00:44:05 -0400 Christopher Faylor wrote: On Wed, Jun 14, 2006 at 08:29:50PM -0700, Kyle McKay wrote: If you have ever tried to interrupt a program running under cygwin gdb, you have probably experienced some frustration. Especially if the program was built with -mno-cygwin. No I never have. In fact I often rely on CTRL-C interrupting the program. It doesn't matter whether the program is built with -mno-cygwin or not. In fact, I am sometimes frustrated when I actually want the CTRL-C to be propagated to the program but then I remember about the handle command. The only time that I can think of when a CTRL-C would not interrupt a program would be when you're running gdb under a cygwin pty or tty. But it's usually easy enough not to do that if you are debugging a problem. I'm happy for you that CTRL-C works for you. It does not work for me. I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Also, if you have tty in your CYGWIN variable it doesn't work even from a DOS command prompt. Finally, it NEVER works no matter what if you are debugging a program built with a different compiler such as m$ visual C++. And, of course, you say I have no reason to do that since the debugging symbols will not be compatible. However, the m$ visual C++ built program is then loading a cygwin/mingw built DLL. CTRL-C doesn't work in this case to interrupt the running program. Although if you are careful you can get breakpoints set, but if you change your mind after you start running the program again then you're out of luck. That's where the debugbreak utility comes in very handy. Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 01:20:40AM -0700, Kyle McKay wrote: I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Same here. Finally, it NEVER works no matter what if you are debugging a program built with a different compiler such as m$ visual C++. And, of course, you say I have no reason to do that since the debugging symbols will not be compatible. However, the m$ visual C++ built program is then loading a cygwin/mingw built DLL. CTRL-C doesn't work in this case to interrupt the running program. Although if you are careful you can get breakpoints set, but if you change your mind after you start running the program again then you're out of luck. That's where the debugbreak utility comes in very handy. Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. I find it does it to me 100% of the time if I'm using putty+ssh or putty+cygputty hack. There's no way I'm using the native cmd shell or the default cygwin cmd shell. It's extremely frustrating when one realizes they've just done a d b, c and realize they have no ability to now stop gdb or even stop anything without hitting up task manager and killing the process. BTW Kyle, you can extend your program greatly by using process enumeration coupled with strcmp on the image name to find the pid based on a string and automatically signal it. But honestly I don't think this program should be needed in the first place. -cl -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Unable to delete directory in Cygwin
Hi,
I have implemented some changes in the linker code for some intermediate
processing.
For that I need to create a temporary directory, generate some
intermediate
files in it, process those files by calling a function. After processing
of the
intermediate files, I delete the intermediate files and the temporary
directory.
While this logic works fine in the linux, the temporary directory does
not get
deleted in cygwin.
/* ldmain.c */
main()
{
.
.
my_function();
.
.
delete tmp_directory;//I have to delete the tmp_directory only here
}
/* myfile.c */
my_function()
{
create tmp directory tmp_directory;
.
create intermediate files in the above directory; .
my_process_function(intermediate files);//processes the intermediate
files .
return;
}
my_process_function(files)
{
.
process the intermediate files;
.
delete the intermediate files;// I cannot delete the tmp_directory here
return;
}
After debugging using gdb, I found that in cygwin, the intermediate
files still
had some handlers open for it inspite of reaching till the end of the
main()
function in linker. Due to this, the temporary files get deleted only
after
exiting from the main. Hence as the temporary drectory is not empty till
then,
it cannot get deleted.
This behaviour is not seen in linux. Care has been taken in the code for
correct
opening and closing of the intermediate files.
Is this a known behavior in cygwin? Any inputs will be appreciated.
Regards,
Gina Verlekar
KPIT Cummins InfoSystems Ltd.
Pune, India
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C
and M32C Series.
The following site also offers free technical support to its users.
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on June 1, 2006.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cygipc-1.13-2.tar.bz2 download
Rajendra S. Gad schrieb: Sir Igor, I am installing the DSpace application on the UBUNTU version 5.10 . Please inform me where I will have better instruction for installing and configuring DSpace on this plateform. Slightly off-topic, but for the sake of interest: I'm just crosscompiling libstdc++-3.3.5 with --host=cygwin for dSpace (not DSpace), a real-time i686-gnu-linux target, which runs on a special opteron hardware with custom IO boards, used by MATLAB - SimuLink as hardware platform. (octave not supported unfortunately, no simulink) Mainly used in the automobile and aviation industry as real-time simulation. So there are cases where you NEED cygwin for dSpace also. But never cygipc unless you are using a really old cygwin. Also let suggest me other linux plateform which will be user friendly for instyallinf DSpace( Specially which will have all the required supporting tools installed. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygdrive 'find' problem fixed in ver 4.3.0
Hi all, I had the cygdrive 'find' problem whereby the command cant traverse the mounted drived under /cygdrive properly, as described in these posts: http://sourceware.org/ml/cygwin/2005-11/msg00772.html http://sourceware.org/ml/cygwin/2006-04/msg00112.html http://www.cygwin.com/ml/cygwin/2005-10/msg00773.html It was a major pain because it also broke updatedb. I just forced the upgrade from 4.2.27 to 4.3.0 and now the problem is fixed, so there you go! Yours, Mark -- Dr. Mark Wright OneIT - BTExact Systems Analyst, Drone 512414 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
GPL Alert: Super
http://www.erightsoft.com/SUPER.html It's a GUI around a bunch of command-line video file editing tools. Installs both cygwin1.dll and cygz.dll in the System32 folder. Can't find any mention of source code on the web site. (I won't even mention that it distributes these open source command-line tools without any source code as well. Oops... looks like I just did.) - Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sshd connection reset by peer problem
Hi, I installed cygwin on xp and installed openssh and cygrunsrv. All worked well and I could ssh to my localhost. Today I get the following message when I ssh: Read from socket failed: Connection reset by peer I have tried to uninstall and reinstall cygwin but this has not corrected the problem. Here is a debug ssh if that helps: $ ssh -vvv localhost OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/identity type 0 debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_ rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_rsa ty pe 1 debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_ dsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_dsa ty pe 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[EMAIL PROTECTED],zlib debug2: kex_parse_kexinit: none,[EMAIL PROTECTED],zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit:
Re: cygdrive 'find' problem fixed in ver 4.3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 6/15/2006 4:32 AM: Hi all, I had the cygdrive 'find' problem whereby the command cant traverse the mounted drived under /cygdrive properly, as described in these posts: http://sourceware.org/ml/cygwin/2005-11/msg00772.html This is already a known problem, and another already known solution is to use a recent cygwin snapshot. In fact, if you were to use 4.3.0's oldfind, it would have the same problem as 4.2.27's find. It was a major pain because it also broke updatedb. I just forced the upgrade from 4.2.27 to 4.3.0 and now the problem is fixed, so there you go! The only reason I have not made 4.3.0 the current version is because it is alpha quality upstream, and 4.2.27 depends on cygwin 1.5.19; making 4.3.0 current would leave no fallback for users trying to revert to cygwin 1.5.18. But as soon as cygwin 1.5.20 comes out (whenever that might be), my story will change, since I will no longer have to worry about 1.5.18 compatibility. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin findutils maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkVR684KuGfSFAYARAq3DAJ49gNu5MYuDSrqcOjXBkCInly4rSgCfUBnm z2wAO8xbk7hBpiKPXICAFqA= =28f6 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Unable to delete directory in Cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gina Verlekar on 6/15/2006 3:53 AM:
Hi,
I have implemented some changes in the linker code for some intermediate
processing.
For that I need to create a temporary directory, generate some
intermediate
files in it, process those files by calling a function. After processing
of the
intermediate files, I delete the intermediate files and the temporary
directory.
While this logic works fine in the linux, the temporary directory does
not get
deleted in cygwin.
Windows is not Linux, and will not allow users to delete in-use
directories (where a directory is considered in-use if it contains files,
or if any process is using that directory as its current working
directory), nor the clean deletion of files that are still open. POSIX
allows this behavior, and cygwin cannot change Window's implementation of
deletion semantics. Just because Linux behaves nicer doesn't mean that it
is portable to remove in-use directories. Fix your code to first close
all outstanding file handles before trying to remove the files, and then
the directory.
That said, cygwin does try to emulate linux, and if someone were to
contribute a patch that would allow cygwin to emulate directory deletion
if it knows that all open handles have also been scheduled for unlinking
at process end, then http://cygwin.com/acronyms/#PTC.
/* ldmain.c */
main()
{
.
.
my_function();
.
.
delete tmp_directory;//I have to delete the tmp_directory only here
}
pseudocode like this is worthless when asking for help. Post a simple,
self-contained, compiling testcase if you want more help.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEkVYs84KuGfSFAYARAuREAJ9EnUBagCb2fXjvJ0y77GKkF+ZXCgCfdo4Y
l0H2f8Bd6sxUSEQ5mglS8Tw=
=YWk6
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: sshd connection reset by peer problem
This doesn't look like a cygwin problem to me at all. Look at the first 20 lines of your debug output again. -cl On Thu, Jun 15, 2006 at 04:46:23AM -0700, marct wrote: Read from socket failed: Connection reset by peer AKA you sent bunk data, try again. $ ssh -vvv localhost OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/identity type 0 debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_ rsa. debug2: key_type_from_name: unknown key type '-BEGIN' -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problems with NFS server
Hello, I am trying to export via NFS a cygwin directory as a root filesystem for an embedded Linux system (I hope it can work..), but I get problems. I installed the NFS services properly on Windows XP (nfsd, portmap, mountd). As indicated in the install script, they are running as an user that I created, member of the Administrators group. The Linux system can use an NFS root filesystem from a Linux PC without any problem, so my configuration should be OK. I use the NFS cygwin package version 2.3-4. My kernel command line is: console=ttyCL1 root=/dev/nfs nfsroot=172.16.20.245:/usr/src/buildroot-20060308/build_arm/root ip=172.16.7.65 At boot I get the following messages: (...) eth0: using half-duplex 10Base-T (RJ-45) IP-Config: Guessing netmask 255.255.0.0 IP-Config: Complete: device=eth0, addr=172.16.7.65, mask=255.255.0.0, gw=255.255.255.255, host=172.16.7.65, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=172.16.20.245, rootpath= Looking up port of RPC 13/2 on 172.16.20.245 Looking up port of RPC 15/1 on 172.16.20.245 VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device nfs or unknown-block(2,0) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) It waits for about 3 seconds after the Looking up... lines and then it gives this error. All I get in my logs on my server are these messages: 15:01:54: mountd: PID 4064: NFS mount request received (/usr/src/buildroot-20060308/build_arm/root, from 172.16.7.65). 15:01:58: mountd: PID 4064: NFS mount request completed (/usr/src/buildroot-20060308/build_arm/root, from 172.16.7.65). I am exporting a directory with correct permissions, my /etc/exports contains: /usr/src/buildroot-20060308/build_arm/root 172.16.7.65(rw,no_root_squash) What is strange is that I don't get any error from nfsd. If you have any idea... Thanks in advance for any help. Nicolas __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sysconf(_SC_PAGESIZE) set to 64k
I don't know if this is something I am doing wrong or an issue. When compiling under cygwin sysconf(_SC_PAGESIZE) returns 65536 (64k) memory page size. My understanding is that: sysconf(_SC_PAGESIZE) * sysconf(_SC_PHYS_PAGES) should yield the total physical memory size of the machine. However, when I do this it yields a very large number (actually overflows my long). However, if I multiply sysconf(_SC_PHYS_PAGES) * 4096 it yields the correct size. My code works properly under linux. Attached is my cygcheck.out. Thanks, Ehren cygcheck.out Description: cygcheck.out -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: sysconf(_SC_PAGESIZE) set to 64k
On 15 June 2006 14:56, Ehren Jarosek wrote: I don't know if this is something I am doing wrong or an issue. When compiling under cygwin sysconf(_SC_PAGESIZE) returns 65536 (64k) memory page size. My understanding is that: sysconf(_SC_PAGESIZE) * sysconf(_SC_PHYS_PAGES) should yield the total physical memory size of the machine. However, when I do this it yields a very large number (actually overflows my long). However, if I multiply sysconf(_SC_PHYS_PAGES) * 4096 it yields the correct size. Alas there is a problem with the definition of sysconf: it is supposed to be the size of the unit of granularity of mmap'ing, but it is also supposed to be the size of a single pageframe of memory. While it is a correct assumption on Linux that these things are one and the same, on 'doze you can only mmap pages in blocks of 64kB, but the pages themselves (the granularity of RWX access protection rather than of VAD mapping) are the standard 4kB size. This is a limitation of the underlying windows o/s. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sshd connection reset by peer problem
Thanks for the pointer. I removed all of my keys from the .ssh directory and then ran ssh-keygen.exe which created 3 new sets of keys but I still get connection reset by peer: $ ssh -vvv localhost OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/identity type 0 debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_ rsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_rsa ty pe 1 debug3: Not a RSA1 key file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_ dsa. debug2: key_type_from_name: unknown key type '-BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-END' debug3: key_read: missing keytype debug1: identity file /cygdrive/c/Documents and Settings/TordoffM/.ssh/id_dsa ty pe 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[EMAIL PROTECTED],zlib debug2: kex_parse_kexinit: none,[EMAIL PROTECTED],zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-c tr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED] ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[EMAIL PROTECTED] debug2: kex_parse_kexinit: none,[EMAIL
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, 15 Jun 2006, Kyle McKay wrote: On 15 Jun 2006 at 00:44:05 -0400 Christopher Faylor wrote: On Wed, Jun 14, 2006 at 08:29:50PM -0700, Kyle McKay wrote: If you have ever tried to interrupt a program running under cygwin gdb, you have probably experienced some frustration. Especially if the program was built with -mno-cygwin. No I never have. In fact I often rely on CTRL-C interrupting the program. It doesn't matter whether the program is built with -mno-cygwin or not. In fact, I am sometimes frustrated when I actually want the CTRL-C to be propagated to the program but then I remember about the handle command. The only time that I can think of when a CTRL-C would not interrupt a program would be when you're running gdb under a cygwin pty or tty. But it's usually easy enough not to do that if you are debugging a problem. I'm happy for you that CTRL-C works for you. It does not work for me. I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Also, if you have tty in your CYGWIN variable it doesn't work even from a DOS command prompt. That's what CGF said. Finally, it NEVER works no matter what if you are debugging a program built with a different compiler such as m$ visual C++. And, of course, you say I have no reason to do that since the debugging symbols will not be compatible. However, the m$ visual C++ built program is then loading a cygwin/mingw built DLL. CTRL-C doesn't work in this case to interrupt the running program. Although if you are careful you can get breakpoints set, but if you change your mind after you start running the program again then you're out of luck. That's where the debugbreak utility comes in very handy. Does kill -INT cygwin_pid work? Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. The workaround would be even better if you didn't need a separate program. How about submitting a patch for Cygwin's kill (with a new signal, SIGDBG or SIGDEBUG)? CGF, would you consider such a patch? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 01:20:40AM -0700, Kyle McKay wrote: On 15 Jun 2006 at 00:44:05 -0400 Christopher Faylor wrote: On Wed, Jun 14, 2006 at 08:29:50PM -0700, Kyle McKay wrote: If you have ever tried to interrupt a program running under cygwin gdb, you have probably experienced some frustration. Especially if the program was built with -mno-cygwin. No I never have. In fact I often rely on CTRL-C interrupting the program. It doesn't matter whether the program is built with -mno-cygwin or not. In fact, I am sometimes frustrated when I actually want the CTRL-C to be propagated to the program but then I remember about the handle command. The only time that I can think of when a CTRL-C would not interrupt a program would be when you're running gdb under a cygwin pty or tty. But it's usually easy enough not to do that if you are debugging a problem. I'm happy for you that CTRL-C works for you. It does not work for me. I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Also, if you have tty in your CYGWIN variable it doesn't work even from a DOS command prompt. Which is exactly what I theorized above. So, characterizing CTRL-C as not working in gdb is rather an overstatement without more details. Now you know that you can use a standard console window for debugging and all will be well. Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. Yep. Use a console window. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: FW: Need help to compile coreutils-5.96
Hi, What you say makes sense. I have run coreutils-5.96-1.sh first and it did not complete correctly because I did not have patch installed. I have downloaded patch and then executed the script again thinking that it would overwrite what the first attempt did. I will try to redo the whole process from scratch and If I still have the problem, I'll come back to report it. BTW, it is the first time I try to compile a cygwin package and I'm really amazed how easy it is. I used to have bad experiences with compiling stuff on Unix but with your package, everything went very smooth and flawlessly except for my small glitch. Nice job! Greetings, Olivier Langlois http://www.olivierlanglois.net -Original Message- When compiling this package, I receive this error message from the linker: gcc -std=gnu99 -g -O2 -o cp.exe cp.o copy.o cp-hash.o ../lib/libcoreutils.a ../lib/libcoreutils.a copy.o:copy.c:(.text+0xefd): undefined reference to `_cygwin_spelling' copy.o:copy.c:(.text+0x2b38): undefined reference to `_cygwin_spelling' collect2: ld returned 1 exit status Does someone have any idea about what is wrong? It sounds like you did not properly run the /usr/src/coreutils-5.96-1.sh script to prep the source with my downstream patches. cygwin_spelling() is a function I wrote, provided in lib/cygwin.c which is part of my patch, and should be linked in to lib/libcoreutils.a if the package is properly re-autotooled during the prep stage. -- Eric Blake volunteer cygwin coreutils maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Unable to delete directory in Cygwin
* Gina Verlekar (2006-06-15 10:53 +) I have implemented some changes in the linker code for some intermediate processing. For that I need to create a temporary directory, generate some intermediate files in it, process those files by calling a function. After processing of the intermediate files, I delete the intermediate files and the temporary directory. While this logic works fine in the linux, the temporary directory does not get deleted in cygwin. [...] After debugging using gdb, I found that in cygwin, the intermediate files still had some handlers open for it inspite of reaching till the end of the main() function in linker. Due to this, the temporary files get deleted only after exiting from the main. Hence as the temporary drectory is not empty till then, it cannot get deleted. This behaviour is not seen in linux. Care has been taken in the code for correct opening and closing of the intermediate files. Is this a known behavior in cygwin? Any inputs will be appreciated. mkdir test cd test rmdir ../test does work in Linux but not under Windows and therefor not under Cygwin. Cygwin can't break Windows rules. Under Linux you can name a file c:, under Windows and under Cygwin not. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygdrive flags / hiding cygdrive prefix directory (the old behavior)
Symlink? ln -s /cygdrive/c /c Charles Stepp Unix SA CYGWIN ROCKS!! -Original Message- From: kralius [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 11:26 PM To: cygwin@cygwin.com Subject: Re: cygdrive flags / hiding cygdrive prefix directory (the old behavior) Thanks for the reply. The only mention of cygdrive flags in the registry that i could find was at least 3 years old and got a reply to the effect of don't mess with the registry! (*sigh*) Which apparently didn't serve as a clue? The hint was written before the always-visible cygdrive ..feature.. came into play, so i figured it was worth asking again. Aside from that, though, notions like hands off and not possible strike me as a little bit out-of-place for cygwin, i have to admit. I imagine many of its users (like myself) are interested in how it works, and in playing around with it (even at the risk of breaking things). I'd certainly welcome getting pointed in the right direction to something like the bit definitions for cygdrive flags in the source... But, assuming cygdrive flags has nothing to do with the visibility issue, (it looks like it happened to /proc and others at the same time,) does anyone know/remember where the change was made to make these special directories visible? Thanks! - kral On 6/13/06, Christopher Faylor [EMAIL PROTECTED] wrote: On Tue, Jun 13, 2006 at 08:22:20PM -0500, kralius wrote: I'm trying to find a way to make the cygdrive prefix directory (default: /cygdrive) appear hidden within cygwin (for example, to ls or find). This was actually the old behavior in cygwin, but at some point it changed to become visible. The cygwin installer now also creates a real directory on the windows file system called cygdrive, but even if I delete this or change the cygdrive prefix to something non-default (like /mnt), it will still show up (with ls, find, etc.). For a while, i suspected this had something to do with the cygdrive flags parameter (in the registry under ...\cygwin\mounts v2 ), but i'm having no success playing with that now, and the cygwin faq and mailing list archives are all very quiet about the subject. The only mention of cygdrive flags in the registry that i could find was at least 3 years old and got a reply to the effect of don't mess with the registry! (*sigh*) Which apparently didn't serve as a clue? Does anyone have an idea how to get the old behavior back of hiding the cydrive prefix directory? And, whether or not it is related, does anyone know how the cygdrive flags parameter is defined, what options can be set with it, etc. ? The cygdrive prefix is controlled with the mount program. Anything that it is possible to do with it is mentioned there. It is not possible to hide it currently. As you have discovered, the cygdrive parameter isn't there for you to play with via regedit. It is really intended to be manipulated with the mount command. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygdrive flags / hiding cygdrive prefix directory (the old behavior)
Does the following do what you want? mount -u -b --change-cygdrive-prefix / You may want to change the -u and -b options to fit your circumstances. (I'm surprised that this wasn't mentioned previously, so I may have misunderstood and this may not be the solution to the problem.) - Barry Stepp, Charles wrote: Symlink? ln -s /cygdrive/c /c Charles Stepp Unix SA CYGWIN ROCKS!! -Original Message- From: kralius [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 11:26 PM To: cygwin@cygwin.com Subject: Re: cygdrive flags / hiding cygdrive prefix directory (the old behavior) Thanks for the reply. The only mention of cygdrive flags in the registry that i could find was at least 3 years old and got a reply to the effect of don't mess with the registry! (*sigh*) Which apparently didn't serve as a clue? The hint was written before the always-visible cygdrive ..feature.. came into play, so i figured it was worth asking again. Aside from that, though, notions like hands off and not possible strike me as a little bit out-of-place for cygwin, i have to admit. I imagine many of its users (like myself) are interested in how it works, and in playing around with it (even at the risk of breaking things). I'd certainly welcome getting pointed in the right direction to something like the bit definitions for cygdrive flags in the source... But, assuming cygdrive flags has nothing to do with the visibility issue, (it looks like it happened to /proc and others at the same time,) does anyone know/remember where the change was made to make these special directories visible? Thanks! - kral On 6/13/06, Christopher Faylor [EMAIL PROTECTED] wrote: On Tue, Jun 13, 2006 at 08:22:20PM -0500, kralius wrote: I'm trying to find a way to make the cygdrive prefix directory (default: /cygdrive) appear hidden within cygwin (for example, to ls or find). This was actually the old behavior in cygwin, but at some point it changed to become visible. The cygwin installer now also creates a real directory on the windows file system called cygdrive, but even if I delete this or change the cygdrive prefix to something non-default (like /mnt), it will still show up (with ls, find, etc.). For a while, i suspected this had something to do with the cygdrive flags parameter (in the registry under ...\cygwin\mounts v2 ), but i'm having no success playing with that now, and the cygwin faq and mailing list archives are all very quiet about the subject. The only mention of cygdrive flags in the registry that i could find was at least 3 years old and got a reply to the effect of don't mess with the registry! (*sigh*) Which apparently didn't serve as a clue? Does anyone have an idea how to get the old behavior back of hiding the cydrive prefix directory? And, whether or not it is related, does anyone know how the cygdrive flags parameter is defined, what options can be set with it, etc. ? The cygdrive prefix is controlled with the mount program. Anything that it is possible to do with it is mentioned there. It is not possible to hide it currently. As you have discovered, the cygdrive parameter isn't there for you to play with via regedit. It is really intended to be manipulated with the mount command. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: sysconf(_SC_PAGESIZE) set to 64k
On Jun 15 15:09, Dave Korn wrote: On 15 June 2006 14:56, Ehren Jarosek wrote: I don't know if this is something I am doing wrong or an issue. When compiling under cygwin sysconf(_SC_PAGESIZE) returns 65536 (64k) memory page size. My understanding is that: sysconf(_SC_PAGESIZE) * sysconf(_SC_PHYS_PAGES) should yield the total physical memory size of the machine. However, when I do this it yields a very large number (actually overflows my long). However, if I multiply sysconf(_SC_PHYS_PAGES) * 4096 it yields the correct size. Alas there is a problem with the definition of sysconf: it is supposed to be the size of the unit of granularity of mmap'ing, but it is also supposed to be the size of a single pageframe of memory. [...] _SC_PAGESIZE is only for indicating the page size as used in calls to mmap(2). POSIX does not demand that _SC_PAGESIZE is actually the physical page size. Two quotes from the Linux man pages: $ man getpagesize [...] The function getpagesize() returns the number of bytes in a page, where a page is the thing used where it says in the description of mmap(2) that files are mapped in page-sized units. The size of the kind of pages that mmap uses, is found using #include unistd.h long sz = sysconf(_SC_PAGESIZE); $ man sysconf [...] These values also exist, but may not be standard. - _SC_PHYS_PAGES The number of pages of physical memory. Note that it is possi- ble for the product of this value and the value of _SC_PAGE_SIZE to overflow. So, actually Ehren's application works on Linux just coincidentally, since it make invalid assumptions. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 01:28:59AM -0700, [EMAIL PROTECTED] wrote: On Thu, Jun 15, 2006 at 01:20:40AM -0700, Kyle McKay wrote: I'm almost never running gdb from a genuine DOS command prompt. Sometimes via ssh, sometimes via a terminal emulator. CTRL-C doesn't work in those. Same here. Then you should do so. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 10:43:23AM -0400, Igor Peshansky wrote: The workaround would be even better if you didn't need a separate program. How about submitting a patch for Cygwin's kill (with a new signal, SIGDBG or SIGDEBUG)? CGF, would you consider such a patch? No. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: FW: Need help to compile coreutils-5.96
Eric, I think that I have found the problem. In the file lib/Makefile.am, you have libcoreutils_a_SOURCES = \ allocsa.c allocsa.h \ euidaccess.h \ exit.h \ fprintftime.c fprintftime.h \ full-read.c full-read.h \ full-write.c full-write.h \ getaddrinfo.h \ gettext.h \ localcharset.c localcharset.h \ mbchar.h \ mbswidth.c mbswidth.h \ mbuiter.h \ readtokens0.c readtokens0.h \ strcase.h \ strnlen1.c strnlen1.h \ strstr.h \ time_r.c time_r.h \ unicodeio.c unicodeio.h \ verify.h \ xalloc-die.c \ xgethostname.c xgethostname.h \ xmemcoll.c xmemcoll.h \ xstrndup.c xstrndup.h \ xstrtoimax.c \ xstrtoumax.c libcoreutils_a_SOURCES += \ printf-args.h \ printf-parse.h \ vasprintf.h \ vasnprintf.h \ cygwin.c cygwin.h Somehow, when lib/Makefile is generated by configure, cygwin.c is not included in the Makefile. I did not have automake installed and a warning has been issued during make. I have tried to install automake and rerun configure but I still have the same result where cygwin.c is not compiled. Greetings, Olivier Langlois http://www.olivierlanglois.net -Original Message- When compiling this package, I receive this error message from the linker: gcc -std=gnu99 -g -O2 -o cp.exe cp.o copy.o cp-hash.o ../lib/libcoreutils.a ../lib/libcoreutils.a copy.o:copy.c:(.text+0xefd): undefined reference to `_cygwin_spelling' copy.o:copy.c:(.text+0x2b38): undefined reference to `_cygwin_spelling' collect2: ld returned 1 exit status Does someone have any idea about what is wrong? It sounds like you did not properly run the /usr/src/coreutils-5.96-1.sh script to prep the source with my downstream patches. cygwin_spelling() is a function I wrote, provided in lib/cygwin.c which is part of my patch, and should be linked in to lib/libcoreutils.a if the package is properly re-autotooled during the prep stage. -- Eric Blake volunteer cygwin coreutils maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On 15 Jun 2006 11:04:56 -0400, Christopher Faylor wrote:
Lacking the ability to interrupt a running program severely limits
gdb's usefulness. Fortunately there's a workaround available.
Yep. Use a console window.
Maybe I haven't been clear. THIS DOES NOT WORK.
Compile the below hellowin.c program with the m$ visual C compiler.
Start it up using gdb. Run it, press CTRL-C, NOTHING HAPPENS.
/* BEGIN hellowin.c */
/* compile with cl -o hellowin.exe hellowin.c user32.lib */
#include windows.h
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInstance, LPSTR
lpCmdLine,
int nCmdShow)
{
MessageBox(NULL, Hello, world!, , MB_OK);
return 0;
}
/* END hellowin.c */
Now if you have such a program compiled with the m$ compiler for
which you do not have the source and such a program is loading a DLL
plugin built with cygwin that you're trying to debug then CTRL-C WILL
NEVER WORK no matter how many console windows you get out.
A console window is also not an option when debugging via a remote X
session or ssh.
On 15 Jun 2006 10:43:23 -0400 , Igor Peshansky wrote:
Does kill -INT cygwin_pid work?
No.
The workaround would be even better if you didn't need a separate
program.
How about submitting a patch for Cygwin's kill (with a new signal,
SIGDBG or SIGDEBUG)? CGF, would you consider such a patch?
That would be nice, for both kill and killall. I provided the very
simple source code in my original message (and included again in this
one for your convenience) so anyone could use it right away or make a
patch if they like. The relevant code is:
HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, (DWORD)
winpid_proc_id);
if (proc != NULL) {DebugBreakProcess(proc); CloseHandle(proc);}
On 15 Jun 2006 01:28:59 -0700 , clayne at anodized dot wrote:
BTW Kyle, you can extend your program greatly by using process
enumeration
coupled with strcmp on the image name to find the pid based on a
string and
automatically signal it.
Yes, or you could just use the below two-line shell script:
#!/bin/sh
ps -W | grep $1 | awk '{print $1}' | xargs -n 1 debugbreak
But honestly I don't think this program should be needed in the
first place.
Neither do I. gdb was not usable for me previously. The console
window option DOES NOT WORK when the program loading the cygwin-built
DLL was compiled with m$ visual C. It is also a non-solution for ssh
users and remote X users.
Here is the simple debugbreak.c source again.
Kyle
/* BEGIN debugbreak.c */
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif
#if _WIN32_WINNT 0x0501
#error Must target Windows NT 5.0.1 or later for DebugBreakProcess
#endif
#include Windows.h
#include stddef.h
#include stdlib.h
/* Compile with this line:
gcc -o debugbreak -mno-cygwin -mthreads debugbreak.c
*/
static char errbuffer[256];
static const char *geterrstr(DWORD errcode)
{
size_t skip = 0;
DWORD chars;
chars = FormatMessage(
FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, errcode, 0, errbuffer, sizeof(errbuffer)-1, 0);
errbuffer[sizeof(errbuffer)-1] = 0;
if (chars) {
while (errbuffer[chars-1] == '\r' || errbuffer[chars-1] ==
'\n') {
errbuffer[--chars] = 0;
}
}
if (chars errbuffer[chars-1] == '.') errbuffer[--chars] = 0;
if (chars = 2 errbuffer[0] == '%' errbuffer[1] = '0'
errbuffer[1] = '9')
{
skip = 2;
while (chars skip errbuffer[skip] == ' ') ++skip;
if (chars = skip+2 errbuffer[skip] == 'i'
errbuffer[skip+1] == 's')
{
skip += 2;
while (chars skip errbuffer[skip] == ' ') ++skip;
}
}
if (chars skip errbuffer[skip] = 'A' errbuffer[skip] =
'Z') {
errbuffer[skip] += 'a' - 'A';
}
return errbuffer+skip;
}
int main(int argc, char *argv[])
{
HANDLE proc;
unsigned proc_id = 0;
BOOL break_result;
if (argc != 2) {
printf(Usage: debugbreak process_id_number\n);
return 1;
}
proc_id = (unsigned) strtol(argv[1], NULL, 0);
if (proc_id == 0) {
printf(Invalid process id %u\n, proc_id);
return 1;
}
proc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, (DWORD)proc_id);
if (proc == NULL) {
DWORD lastError = GetLastError();
printf(Failed to open process %u\n, proc_id);
printf(Error code is %lu (%s)\n, (unsigned long)lastError,
geterrstr(lastError));
return 1;
}
break_result = DebugBreakProcess(proc);
if (!break_result) {
DWORD lastError = GetLastError();
printf(Failed to debug break process %u\n, proc_id);
printf(Error code is %lu (%s)\n, (unsigned long)lastError,
geterrstr(lastError));
CloseHandle(proc);
return 1;
}
printf(DebugBreak sent successfully to process id %u\n, proc_id);
CloseHandle(proc);
return 0;
}
/*
Re: Problems with NFS server
On Thu, 2006-06-15 at 15:36 +0200, Nicolas Boudin wrote: Hello, I am trying to export via NFS a cygwin directory as a root filesystem for an embedded Linux system (I hope it can work..) It should - that's the whole reason I ported it for cygwin in the first place :-) Could you post your /etc/exports file, please? -Samrobb -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 10:38:57AM -0700, Kyle McKay wrote: On 15 Jun 2006 11:04:56 -0400, Christopher Faylor wrote: Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. Yep. Use a console window. Maybe I haven't been clear. THIS DOES NOT WORK. Compile the below hellowin.c program with the m$ visual C compiler. On Cygwin, gdb is the debugger for programs produced by gcc. You are not going to be able to read many (any?) symbols for programs produced by other compilers so there really isn't much of a reason to use gdb to debug non-gcc-produced programs. It is also possible that CTRL-C will not interrupt programs which are compiled for -mwin32. I haven't tried that for a while. That may be what you're seeing when you use the Microsoft Visual C compiler. In any event, at least we're getting details now beyond the CTRL-C doesn't work with gdb. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygdrive flags / hiding cygdrive prefix directory (the old behavior)
On 6/15/06, Buchbinder, Barry (NIH/NIAID) [E] wrote: Does the following do what you want? mount -u -b --change-cygdrive-prefix / Stepp, Charles wrote: Symlink? ln -s /cygdrive/c /c No... Thanks but no. Barry and Charles, i think you're answering a different question. This thread wasn't about changing the path for the cygdrive prefix, but, rather, making it invisible to cygwin programs. Igor, about /cygdrive being created upon install: If anything does this, it will probably be a postinstall script that contains the string cygdrive. Grep through all .sh.done files in /etc/postinstall, and you'll likely find the culprit. No luck with anything in /etc/postinstall. Hmm... not sure if anyone will care enough to investigate this. Do you think anyone at cygwin would consider making this feature optional in a later release? They will probably consider it and reject it. The spirit of open-source software is that you scratch what itches you, and others benefit. This is not something that itches any of the Cygwin developers. Hence, http://cygwin.com/acronyms/#PTC. If you do plan to submit a patch, I suggest looking at the fhandler_disk_file::readdir() function, and changing it to optionally remove the virtual /cygdrive directory according to a new cygdrive flag (and add a corresponding mount option). That way, this behavior can be controlled according to people's tastes. Thanks for the advice! - Kral -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
python-2.4.3-1 problem with urllib2
The attached python script works fine under python-2.4.1-1. Under python-2.4.3-1, I get this output: Using urllib.urlopen .. Using urllib2.urlopen .Traceback (most recent call last): File test-urllib.py, line 42, in ? doRequest2(http://localhost:8010;) File test-urllib.py, line 16, in doRequest2 f = urllib2.urlopen(url) File /usr/lib/python2.4/urllib2.py, line 130, in urlopen return _opener.open(url, data) File /usr/lib/python2.4/urllib2.py, line 358, in open response = self._open(req, data) File /usr/lib/python2.4/urllib2.py, line 376, in _open '_open', req) File /usr/lib/python2.4/urllib2.py, line 337, in _call_chain result = func(*args) File /usr/lib/python2.4/urllib2.py, line 1021, in http_open return self.do_open(httplib.HTTPConnection, req) File /usr/lib/python2.4/urllib2.py, line 996, in do_open raise URLError(err) urllib2.URLError: urlopen error unable to select on socket This happens after a consistent number of requests on my machine. Cheers, Chris #!/usr/bin/python import urllib2, urllib, BaseHTTPServer, os, sys, signal class MyHandler(BaseHTTPServer.BaseHTTPRequestHandler): def do_GET(self): data = Hello world self.wfile.write(HTTP/1.0 200 OK\nContent-Length: %s\n\n%s % ( len(data), data)) self.wfile.close() def doRequest(url): f = urllib.urlopen(url) data = f.read() return data def doRequest2(url): f = urllib2.urlopen(url) data = f.read() return data if __name__ == __main__: n = 150 pid = os.fork() if pid == 0: # Run the server s = BaseHTTPServer.HTTPServer((, 8010), MyHandler) try: s.serve_forever() except KeyboardInterrupt: sys.exit(0) else: try: print Using urllib.urlopen for i in range(n): sys.stdout.write(.) sys.stdout.flush() doRequest(http://localhost:8010;) print print Using urllib2.urlopen for i in range(n): sys.stdout.write(.) sys.stdout.flush() doRequest2(http://localhost:8010;) finally: os.kill(pid, signal.SIGINT) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: sshd connection reset by peer problem
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marct Sent: Thursday, June 15, 2006 10:23 AM To: cygwin@cygwin.com Subject: Re: sshd connection reset by peer problem Thanks for the pointer. I removed all of my keys from the .ssh directory and then ran ssh-keygen.exe which created 3 new sets of keys but I still get connection reset by peer: $ ssh -vvv localhost Unless you have an ssh server running on 'localhost', then this command will not work because your 'ssh' client has no server to communicate with. Setting up a (Cygwin) ssh service on your Windows computer is possible, but it's not likely that you want to do that because you have said that you are new to using ssh. Instead, you should find out the IP address of the ssh server, if any, is available on your network. Once you've found out that IP address, then you should first ping it to confirm that your computer has some basic network connectivity to that address. Cygwin provides a simplified method for creating ssh encryption- key files: ssh-user-config. After removing your present key files, run that script, and respond to its prompts. Typically, you will not need the RSA1 and DSA key types, so you can respond no when prompted to create them (they are less secure than the RSA2 key type). --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: GDB Ctrl-C Interrupt Fails WORKAROUND
On 15 June 2006 18:39, Kyle McKay wrote: On 15 Jun 2006 11:04:56 -0400, Christopher Faylor wrote: Lacking the ability to interrupt a running program severely limits gdb's usefulness. Fortunately there's a workaround available. Yep. Use a console window. Maybe I haven't been clear. THIS DOES NOT WORK. Compile the below hellowin.c program with the m$ visual C compiler. Start it up using gdb. Run it, press CTRL-C, NOTHING HAPPENS. OTOH, Ctrl-Break 'works', but is not intercepted by GDB, which just reports Program exited normally. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On 15 Jun 2006 13:57:14 -0400, Christopher Faylor wrote:
On Cygwin, gdb is the debugger for programs produced by gcc. You are
not going to be able to read many (any?) symbols for programs produced
by other compilers so there really isn't much of a reason to use gdb
to debug non-gcc-produced programs.
Apparently you did not see my previous comments about this:
On 15 Jun 2006 10:38:57 -0700, Kyle McKay wrote:
Now if you have such a program compiled with the m$ compiler for
which you do not have the source and such a program is loading a
DLL plugin built with cygwin that you're trying to debug then CTRL-
C WILL NEVER WORK no matter how many console windows you get out.
DLLs built with gcc cannot be interrupted with CTRL-C when they are
loaded by programs built with other compilers.
In any event, at least we're getting details now beyond the CTRL-C
doesn't work with gdb.
Or these comments about using a console window:
On 15 Jun 2006 10:38:57 -0700, Kyle McKay wrote:
It is also a non-solution for ssh users and remote X users.
CTRL-C also appears to be used by the X windows ddd break button.
Doesn't work there either.
However, in all these cases the debugbreak (debugbreak.c) utility can
provide a usable, if awkward, workaround.
For example, build the loopdll.dll and runloop.exe from the following
sources using the gcc and m$ compilers as indicated:
/* BEGIN loopdll.c */
/* Compile with cygwin gcc -o loopdll.dll -g -mno-cygwin -mthreads -
mdll loopdll.c */
#include Windows.h
extern __declspec(dllexport) void Looper(void);
__declspec(dllexport) void Looper(void)
{
for (;;)
{
/* do nothing except eat CPU */
}
}
/* END loopdll.c */
/* BEGIN runloop.c */
#include Windows.h
#include stddef.h
/* Compile with m$ cl -o runloop.exe runloop.c */
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
FARPROC loopfunc;
HMODULE lib = LoadLibrary(loopdll.dll);
if (lib != NULL) {
loopfunc = GetProcAddress(lib, Looper);
if (loopfunc != NULL) {
(*((void(*)())loopfunc))();
}
FreeLibrary(lib);
}
return 0;
}
/* END runloop.c */
Then type gdb runloop.exe (making sure loopdll.dll is located in the
current directory along with runloop.exe) followed by run. Do this
from a CONSOLE window without tty set. Now try CTRL-C. Doesn't
work. Build the debugbreak utility and then type this at a cygwin
bash prompt while gdb is stuck:
./debugbreak `ps -W | grep runloop | awk '{print $1}'`
gdb will regain control. Type list Looper or break Looper and
you will see that indeed you can use gdb to debug with symbols in
this case, set breakpoints, etc. However CTRL-C is useless for
interrupting the running program.
This is not a contrived example. It mirrors the situation found when
attempting to use the cygwin environment to build DLL plugins (and
debug them) for commercial windows applications for which you do not
have the source and which were not built using cygwin. (Note that
this example can also be used to demonstrate that having set stop-on-
solib-events 1 active in gdb before typing run does NOT cause gdb to
regain control when loopdll.dll is first loaded.)
Kyle
P.S. (Here is debugbreak.c again to build debugbreak for use with
this example:)
/* BEGIN debugbreak.c */
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0501
#endif
#if _WIN32_WINNT 0x0501
#error Must target Windows NT 5.0.1 or later for DebugBreakProcess
#endif
#include Windows.h
#include stddef.h
#include stdlib.h
/* Compile with this line:
gcc -o debugbreak -mno-cygwin -mthreads debugbreak.c
*/
static char errbuffer[256];
static const char *geterrstr(DWORD errcode)
{
size_t skip = 0;
DWORD chars;
chars = FormatMessage(
FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, errcode, 0, errbuffer, sizeof(errbuffer)-1, 0);
errbuffer[sizeof(errbuffer)-1] = 0;
if (chars) {
while (errbuffer[chars-1] == '\r' || errbuffer[chars-1] ==
'\n') {
errbuffer[--chars] = 0;
}
}
if (chars errbuffer[chars-1] == '.') errbuffer[--chars] = 0;
if (chars = 2 errbuffer[0] == '%' errbuffer[1] = '0'
errbuffer[1] = '9')
{
skip = 2;
while (chars skip errbuffer[skip] == ' ') ++skip;
if (chars = skip+2 errbuffer[skip] == 'i'
errbuffer[skip+1] == 's')
{
skip += 2;
while (chars skip errbuffer[skip] == ' ') ++skip;
}
}
if (chars skip errbuffer[skip] = 'A' errbuffer[skip] =
'Z') {
errbuffer[skip] += 'a' - 'A';
}
return errbuffer+skip;
}
int main(int argc, char *argv[])
{
HANDLE proc;
unsigned proc_id = 0;
BOOL break_result;
if (argc != 2) {
printf(Usage: debugbreak process_id_number\n);
return 1;
}
proc_id = (unsigned)
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 12:17:09PM -0700, Kyle McKay wrote: On 15 Jun 2006 13:57:14 -0400, Christopher Faylor wrote: On Cygwin, gdb is the debugger for programs produced by gcc. You are not going to be able to read many (any?) symbols for programs produced by other compilers so there really isn't much of a reason to use gdb to debug non-gcc-produced programs. Apparently you did not see my previous comments about this: No. I didn't. Same observation applies, though. On 15 Jun 2006 10:38:57 -0700, Kyle McKay wrote: Now if you have such a program compiled with the m$ compiler for which you do not have the source and such a program is loading a DLL plugin built with cygwin that you're trying to debug then CTRL- C WILL NEVER WORK no matter how many console windows you get out. DLLs built with gcc cannot be interrupted with CTRL-C when they are loaded by programs built with other compilers. In any event, at least we're getting details now beyond the CTRL-C doesn't work with gdb. Or these comments about using a console window: On 15 Jun 2006 10:38:57 -0700, Kyle McKay wrote: It is also a non-solution for ssh users and remote X users. I mentioned ptys and ttys in my very first response. CTRL-C also appears to be used by the X windows ddd break button. Doesn't work there either. So, submit a ddd bug report. However, in all these cases the debugbreak (debugbreak.c) utility can provide a usable, if awkward, workaround. The keyword being awkward. There is nothing to stop an interested person from modifying gdb to do the right thing. For example, build the loopdll.dll and runloop.exe from the following sources using the gcc and m$ compilers as indicated: Isn't the m'$' compiler you're using actually free? If so, the dollar sign appears to be misplaced. In any event, we seem to be looping: On Thu, Jun 15, 2006 at 01:57:14PM -0400, Christopher Faylor wrote: It is also possible that CTRL-C will not interrupt programs which are compiled for -mwin32. I haven't tried that for a while. That may be what you're seeing when you use the Microsoft Visual C compiler. /* BEGIN loopdll.c */ /* Compile with cygwin gcc -o loopdll.dll -g -mno-cygwin -mthreads - mdll loopdll.c */ /* Compile with m$ cl -o runloop.exe runloop.c */ You sure love that 'm$' don't you? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygdrive flags / hiding cygdrive prefix directory (the old behavior)
Stepp, Charles wrote: Symlink? ln -s /cygdrive/c /c Oh please no. If you want that just set the cygdrive prefix to / (mount -c /). Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: GDB Ctrl-C Interrupt Fails WORKAROUND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Thursday, June 15, 2006 3:29 PM To: cygwin@cygwin.com Subject: Re: GDB Ctrl-C Interrupt Fails WORKAROUND On Thu, Jun 15, 2006 at 12:17:09PM -0700, Kyle McKay wrote: On 15 Jun 2006 13:57:14 -0400, Christopher Faylor wrote: On Cygwin, gdb is the debugger for programs produced by gcc. You are not going to be able to read many (any?) symbols for programs produced by other compilers so there really isn't much of a reason to use gdb to debug non-gcc-produced programs. Apparently you did not see my previous comments about this: No. I didn't. Same observation applies, though. On 15 Jun 2006 10:38:57 -0700, Kyle McKay wrote: Now if you have such a program compiled with the m$ compiler for which you do not have the source and such a program is loading a DLL plugin built with cygwin that you're trying to debug then CTRL- C WILL NEVER WORK no matter how many console windows you get out. DLLs built with gcc cannot be interrupted with CTRL-C when they are loaded by programs built with other compilers. In any event, at least we're getting details now beyond the CTRL-C doesn't work with gdb. Or these comments about using a console window: On 15 Jun 2006 10:38:57 -0700, Kyle McKay wrote: It is also a non-solution for ssh users and remote X users. I mentioned ptys and ttys in my very first response. CTRL-C also appears to be used by the X windows ddd break button. Doesn't work there either. So, submit a ddd bug report. However, in all these cases the debugbreak (debugbreak.c) utility can provide a usable, if awkward, workaround. The keyword being awkward. There is nothing to stop an interested person from modifying gdb to do the right thing. For example, build the loopdll.dll and runloop.exe from the following sources using the gcc and m$ compilers as indicated: Isn't the m'$' compiler you're using actually free? If so, the dollar sign appears to be misplaced. Visual C++ 2005 Express Edition is free; all other editions are not. The only thing us Cygwin users use from MSVC++8 is cl. In any event, we seem to be looping: On Thu, Jun 15, 2006 at 01:57:14PM -0400, Christopher Faylor wrote: It is also possible that CTRL-C will not interrupt programs which are compiled for -mwin32. I haven't tried that for a while. That may be what you're seeing when you use the Microsoft Visual C compiler. /* BEGIN loopdll.c */ /* Compile with cygwin gcc -o loopdll.dll -g -mno-cygwin -mthreads - mdll loopdll.c */ /* Compile with m$ cl -o runloop.exe runloop.c */ You sure love that 'm$' don't you? Kyle probably wanted to imiatate the unix-like shells. In some howtos, they put in something like: bash$ Or, as in A Day With CVS, they put in: floss$ So Kyle put in m$ to signify that he was using the vcvars32.bat file (or something like that) cgf For me, the Ctrl+C thing never works, on cygwin.bat AND xterm. I would use Ctrl+Z instead. So if you hit Ctrl+Z, this would appear (for example): [1]+ Stopped gpg And then when you type another command, hit enter, and wait the new command to stop, this would appear: [1]+ Done gpg Charli -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Cygwin) iD8DBQFEkdATKGyf4JaPChgRAja/AJsEb3Kj59xIQdYFGVllOc53VUpYdACgpev3 tj5VAIUwbub9Zby6MVqsRbc= =oxrd -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: GDB Ctrl-C Interrupt Fails WORKAROUND
On Thu, Jun 15, 2006 at 05:28:59PM -0400, Charli Li wrote: For me, the Ctrl+C thing never works, on cygwin.bat AND xterm. I would use Ctrl+Z instead. So if you hit Ctrl+Z, this would appear (for example): [1]+ Stopped gpg Since using CTRL-Z only works on a running program when using CYGWIN=tty this would YA fall under what I have previously mentioned and repeated. However, since gdb wouldn't know what to do with a CTRL-Z it's hard to see how this helps. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
random fork: Resource temporarily unavailable
I've not seen this message except when I've had to rapidly press ^C to break out of a loop shell script. Today, I've seen it twice when there was virtually no cpu load on the system, about 50% virtual memory committed, and 40 processes. Once, was with an ls command, the other happened as my shell was starting up by some command invoked in the .rc script. I get suspicious whenever I see behavior on my computers when anomalies crop up. I don't think any of my cygwin libraries have been updated recently. What would cause something like this? Memory fragmentation? Insufficient real memory to immediately fork? I.e. I wonder if, when NT goes to fork, if it doesn't have enough free memory, it tells the caller it failed (try again later) and then starts a memory cleanup cycle to free up memory: i.e. rather than the forking process sleeping while memory is made available NT returns it immediately with a failure. Any idea on causes? Is it as rare as it has been for me? A possible solution would be retry the fork a second time, or sleep for a millisecond and then try fork again. I'm not sure, but I think many *ixy (*='un'|'pos'|'lin'|'ir'...etc) type programs may not retry the fork but immediately die, as on *ixy systems, a fork failure is less common, and usually only happens when the system really is out of resources. If that's the case, it _might_ be an aid to smooth *ixy compatibility for the library handling fork, retry the fork (possibly with millisecond sleep) once before returning failure to the application. Not a high priority issue, but just wondering Linda If it is NT returning failure rather than forking, I wonder if, in order to provide a better run-time -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bash and CSRSS consuming 100% of CPU
This problem has been noted before by someone else, http://www.mail-archive.com/cygwin@cygwin.com/msg37532.html but I followed the threads and can find no resolution. When I fire-up a cygwin bash window, everything is fine for a few minutes. Then the CPU utilization on my system suddenly jumps to 100%. Bash is typically grabbing about 80% of the CPU, with almost all the rest grabbed by CSRSS. This all happens even if I just let the bash window sit unused. In other words, it does not seem related to anything I do in the bash window. The problem arises even if I fire-up cygwin and do nothing in the bash window. The cygcheck.out file is attached. This all makes cygwin unusable for me, which is unfortunate. Cygwin did work fine for several years on this PC. This problem started happening only recently, and of course I reinstalled cygwin from the web site but that has not helped. My PC does receive the latest updates and patches from Microsoft, and perhaps that is related to the sudden appearance of this problem. Any suggestions on how to get cygwin running properly for me again would be most appreciated. cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash and CSRSS consuming 100% of CPU
Science Guy wrote: This problem has been noted before by someone else, http://www.mail-archive.com/cygwin@cygwin.com/msg37532.html but I followed the threads and can find no resolution. The problem is caused by sysinternals' process explorer injecting its own threads into other processes. It was also fixed several months ago in cygwin. Try a snapshot. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: random fork: Resource temporarily unavailable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Linda Walsh Sent: Thursday, June 15, 2006 6:06 PM To: cygwin@cygwin.com Subject: random fork: Resource temporarily unavailable I've not seen this message except when I've had to rapidly press ^C to break out of a loop shell script. Today, I've seen it twice when there was virtually no cpu load on the system, about 50% virtual memory committed, and 40 processes. Once, was with an ls command, the other happened as my shell was starting up by some command invoked in the .rc script. I get suspicious whenever I see behavior on my computers when anomalies crop up. I don't think any of my cygwin libraries have been updated recently. What would cause something like this? Memory fragmentation? Insufficient real memory to immediately fork? I.e. I wonder if, when NT goes to fork, if it doesn't have enough free memory, it tells the caller it failed (try again later) and then starts a memory cleanup cycle to free up memory: i.e. rather than the forking process sleeping while memory is made available NT returns it immediately with a failure. Any idea on causes? Is it as rare as it has been for me? A possible solution would be retry the fork a second time, or sleep for a millisecond and then try fork again. I'm not sure, but I think many *ixy (*='un'|'pos'|'lin'|'ir'...etc) type programs may not retry the fork but immediately die, as on *ixy systems, a fork failure is less common, and usually only happens when the system really is out of resources. If that's the case, it _might_ be an aid to smooth *ixy compatibility for the library handling fork, retry the fork (possibly with millisecond sleep) once before returning failure to the application. Not a high priority issue, but just wondering Linda If it is NT returning failure rather than forking, I wonder if, in order to provide a better run-time Confirmed. This happens on Windows 2000 Service Pack 4, with the latest *stable* cygwin1.dll. It happens when I even run a configure script, or anything else. It's rare, you're right Linda, and it happens at any time (also a bit annoying). The temporary workaround for me is to just restart the whatever and get on with life. Charli -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Cygwin) iD8DBQFEke+CKGyf4JaPChgRAmVYAJ9vGJHdRWLLdzt/a9L55sY9ieJPGQCfZjV3 p7JbZsrfKOzXEadjSjsL6os= =x6lh -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: random fork: Resource temporarily unavailable
Linda Walsh wrote: I've not seen this message except when I've had to rapidly press ^C to break out of a loop shell script. Today, I've seen it twice when there was virtually no cpu load on the system, about 50% virtual memory committed, and 40 processes. Once, was with an ls command, the other happened as my shell was starting up by some command invoked in the .rc script. I get suspicious whenever I see behavior on my computers when anomalies crop up. I don't think any of my cygwin libraries have been updated recently. What would cause something like this? Memory fragmentation? Insufficient real memory to immediately fork? I.e. I wonder if, when NT goes to fork, if it doesn't have enough free memory, it tells the caller it failed (try again later) and then starts a memory cleanup cycle to free up memory: i.e. rather than the forking process sleeping while memory is made available NT returns it immediately with a failure. Any idea on causes? Is it as rare as it has been for me? A possible solution would be retry the fork a second time, or sleep for a millisecond and then try fork again. I'm not sure, but I think many *ixy (*='un'|'pos'|'lin'|'ir'...etc) type programs may not retry the fork but immediately die, as on *ixy systems, a fork failure is less common, and usually only happens when the system really is out of resources. If that's the case, it _might_ be an aid to smooth *ixy compatibility for the library handling fork, retry the fork (possibly with millisecond sleep) once before returning failure to the application. Not a high priority issue, but just wondering Linda If it is NT returning failure rather than forking, I wonder if, in order to provide a better run-time If you can reproduce this problem, I would suggest trying it again with a recent snapshot. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RPM's require to much knowledge of setup to port easily
Larry Hall (Cygwin) wrote: Ah, the lack of a Windows RPM port was *exactly* the reason setup.exe was created. The simplest way to port RPM was to use Cygwin, which then leads to a chicken/egg problem. Most linux distributions have solved this issue. When one goes to do an install on a fresh system, there is no RPM on the target machine. RPM usually doesn't run on the target machine for various reasons (no libs, no utils, no directory structure, no filesystem..etc.) :-) I think that one normally would use some number of non-RPM tools to create the infrastructure needed to support RPM first. Then install RPM and leverage it to install the rest of the system. In all honesty though, if you really would like to know the details of the decision- making process that made the install process what it is today, you can find it all in the cygwin-apps email archives. You'll have to go back quite a ways to find it's beginnings though. --- I'm sure, but perhaps more interesting might be emails talking about when RPM might become an accepted way to distribute cygwin packages (not that there is anyone to work on it right now, but if there was). It's not that RPM is a great work of art or necessarily even worthy of being a standard, but the point of cygwin is to provide an environment that makes it easier to port POSIX compatible (or *ixish) applications. Using a widely adopted package standard like RPM would make the cygwin environment more application-porting friendly. -l -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
