Re: Up for new maintainer - base-files and base-passwd
Hi John, On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. I've been unable to find sufficient time to do these packages justice a situation which is unlikely to improve at this time. The source for the packages is the package itself. I have a small set of automations for building (replacing version numbers etc) which I will happily give to the new maintainer, but I have not created a cygport package for it. I am not going to unsubscribe from the lists nor stop answering questions. I've enjoyed the time I've spent on this project and wish it well. I'm sorry to read that. Thanks for the time and effort you invested into these packages. Since you're not mentioning units, does that mean you keep up maintainership for this package? Other than that, is anybody willing to take over maintainership of base-passwd and/or base-files? While the base-passwd file is relatively uncritical, especially the base-files package needs some work, to pick up the stray bits of problems we collected over the time. Anybody willing to take over a few bash scripts? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] maradns-1.4.04-1
On Sep 13 16:59, Steven Monai wrote: Please upload wget http://dev.monai.ca/cygwin/maradns/maradns-1.4.04-1.tar.bz2 \ http://dev.monai.ca/cygwin/maradns/maradns-1.4.04-1-src.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[RFU] qhull-2010.1-2
Hi, I finally solved the qhull problems casued by an hidden bump of soversion from upstream and my still limited knowledge of cmake. This time seems all right. 2010.1-1 versions to be removed and 2009.1.1-1 to be left as previous for qhull and libqhull-devel. libqhull_5 stays as 2009.1.1 new libqhull_6 for 2010.1-2 New versions built with Yaakov cmake-2.8.1-11. to download: wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/qhull libqhull-devel/libqhull-devel-2010.1-2.tar.bz2 libqhull-devel/setup.hint libqhull_5/libqhull_5-2009.1.1-1.tar.bz2 libqhull_5/setup.hint libqhull_6/libqhull_6-2010.1-2.tar.bz2 libqhull_6/setup.hint qhull-2010.1-2-src.tar.bz2 qhull-2010.1-2.tar.bz2 setup.hint Regards Marco
Re: Up for new maintainer - base-files and base-passwd
On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote: Hi John, On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. I've been unable to find sufficient time to do these packages justice a situation which is unlikely to improve at this time. The source for the packages is the package itself. I have a small set of automations for building (replacing version numbers etc) which I will happily give to the new maintainer, but I have not created a cygport package for it. I am not going to unsubscribe from the lists nor stop answering questions. I've enjoyed the time I've spent on this project and wish it well. I'm sorry to read that. Thanks for the time and effort you invested into these packages. Since you're not mentioning units, does that mean you keep up maintainership for this package? Other than that, is anybody willing to take over maintainership of base-passwd and/or base-files? While the base-passwd file is relatively uncritical, especially the base-files package needs some work, to pick up the stray bits of problems we collected over the time. Anybody willing to take over a few bash scripts? I'd like to do that. Is there a detailed list of things to correct in the base-files package? Or should I look for that info in the archives? Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: Up for new maintainer - base-files and base-passwd
Hi, On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote: Hi John, Thanks for the time and effort you invested into these packages. Thanks to you (and Chris) for putting so much effort in. I only wish I had the time and skills to help more. I learnt a lot from the Cygwin project and it was a definate shove to moving (at home at least) to a 100% *nix base. Since you're not mentioning units, does that mean you keep up maintainership for this package? There is now a cygport script for it (thanks Yaakov) so it takes very very little time. J.
Re: Up for new maintainer - base-files and base-passwd
On Sep 14 11:07, David Sastre wrote: On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote: Hi John, On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. I've been unable to find sufficient time to do these packages justice a situation which is unlikely to improve at this time. The source for the packages is the package itself. I have a small set of automations for building (replacing version numbers etc) which I will happily give to the new maintainer, but I have not created a cygport package for it. I am not going to unsubscribe from the lists nor stop answering questions. I've enjoyed the time I've spent on this project and wish it well. I'm sorry to read that. Thanks for the time and effort you invested into these packages. Since you're not mentioning units, does that mean you keep up maintainership for this package? Other than that, is anybody willing to take over maintainership of base-passwd and/or base-files? While the base-passwd file is relatively uncritical, especially the base-files package needs some work, to pick up the stray bits of problems we collected over the time. Anybody willing to take over a few bash scripts? I'd like to do that. Is there a detailed list of things to correct in the Cool, thank you! base-files package? Or should I look for that info in the archives? This is only spreaded throughout the cygwin and cygwin-apps ML archives. There was also a recent discussion on cygwin-developers, see http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html Other than that, I'm sure there are some who remember what's missing :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Up for new maintainer - base-files and base-passwd
On Sep 14 10:22, John Morrison wrote: Hi, On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote: Hi John, Thanks for the time and effort you invested into these packages. Thanks to you (and Chris) for putting so much effort in. I only wish I had the time and skills to help more. I learnt a lot from the Cygwin project and it was a definate shove to moving (at home at least) to a 100% *nix base. Since you're not mentioning units, does that mean you keep up maintainership for this package? There is now a cygport script for it (thanks Yaakov) so it takes very very little time. Super, I'll keep you as units maintainer in the cygwin-pkg-maint file. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] qhull-2010.1-2
On Sep 14 09:06, Marco Atzeri wrote: Hi, I finally solved the qhull problems casued by an hidden bump of soversion from upstream and my still limited knowledge of cmake. This time seems all right. 2010.1-1 versions to be removed and 2009.1.1-1 to be left as previous for qhull and libqhull-devel. libqhull_5 stays as 2009.1.1 new libqhull_6 for 2010.1-2 Uploaded and 2010.1-1 removed. There's also an older version 2003.1-5. Do you want this removed as well? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] qhull-2010.1-2
--- Mar 14/9/10, Corinna Vinschen ha scritto: On Sep 14 09:06, Marco Atzeri wrote: Hi, I finally solved the qhull problems casued by an hidden bump of soversion from upstream and my still limited knowledge of cmake. This time seems all right. 2010.1-1 versions to be removed and 2009.1.1-1 to be left as previous for qhull and libqhull-devel. libqhull_5 stays as 2009.1.1 new libqhull_6 for 2010.1-2 Uploaded and 2010.1-1 removed. There's also an older version 2003.1-5. Do you want this removed as well? Thanks, Corinna yes, it was linked versus the libqhull that is also gone. Marco
Re: [RFU] qhull-2010.1-2
On Sep 14 10:05, Marco Atzeri wrote: --- Mar 14/9/10, Corinna Vinschen ha scritto: On Sep 14 09:06, Marco Atzeri wrote: Hi, I finally solved the qhull problems casued by an hidden bump of soversion from upstream and my still limited knowledge of cmake. This time seems all right. 2010.1-1 versions to be removed and 2009.1.1-1 to be left as previous for qhull and libqhull-devel. libqhull_5 stays as 2009.1.1 new libqhull_6 for 2010.1-2 Uploaded and 2010.1-1 removed. There's also an older version 2003.1-5. Do you want this removed as well? Thanks, Corinna yes, it was linked versus the libqhull that is also gone. Ok, 2003.1-5 is gone. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Up for new maintainer - base-files and base-passwd
On 14/09/2010 10:30, Corinna Vinschen wrote: On Sep 14 11:07, David Sastre wrote: On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote: On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. Anybody willing to take over a few bash scripts? I'd like to do that. Is there a detailed list of things to correct in the Cool, thank you! base-files package? Or should I look for that info in the archives? This is only spreaded throughout the cygwin and cygwin-apps ML archives. There was also a recent discussion on cygwin-developers, see http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html There's also the issue I reported in [1] where interactive shells which have a non-interactive shell in their ancestry don't get PS1 set correctly. (This affects the shell started by xterm when started from the X tray menu when X is started from the start menu short cut, and can also be demonstrated with 'bash -c bash')
Re: Up for new maintainer - base-files and base-passwd
Hi, On 09/14/2010 09:36 PM, Jon TURNEY wrote: On 14/09/2010 10:30, Corinna Vinschen wrote: On Sep 14 11:07, David Sastre wrote: On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote: On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. Anybody willing to take over a few bash scripts? I'd like to do that. Is there a detailed list of things to correct in the Cool, thank you! base-files package? Or should I look for that info in the archives? This is only spreaded throughout the cygwin and cygwin-apps ML archives. There was also a recent discussion on cygwin-developers, see http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html There's also the issue I reported in [1] where interactive shells which have a non-interactive shell in their ancestry don't get PS1 set correctly. (This affects the shell started by xterm when started from the X tray menu when X is started from the start menu short cut, and can also be demonstrated with 'bash -c bash') I'd also appreciate the patch to fix case sensitive handling from http://sourceware.org/ml/cygwin/2010-04/msg00521.html being PTC. Thanks in advance, Shaddy
Re: Up for new maintainer - base-files and base-passwd
I'd also appreciate it if this could be looked into while updating base-files: http://sourceware.org/ml/cygwin/2010-05/msg0.html Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
Re: Up for new maintainer - base-files and base-passwd
On 14/09/2010 12:36, Jon TURNEY wrote: On 14/09/2010 10:30, Corinna Vinschen wrote: On Sep 14 11:07, David Sastre wrote: On Tue, Sep 14, 2010 at 10:54:05AM +0200, Corinna Vinschen wrote: On Sep 13 10:33, John Morrison wrote: It is with regrets that I give up the maintainership of the cygwin base-files and base-passwd packages. Anybody willing to take over a few bash scripts? I'd like to do that. Is there a detailed list of things to correct in the Cool, thank you! base-files package? Or should I look for that info in the archives? This is only spreaded throughout the cygwin and cygwin-apps ML archives. There was also a recent discussion on cygwin-developers, see http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html There's also the issue I reported in [1] where interactive shells which have a non-interactive shell in their ancestry don't get PS1 set correctly. (This affects the shell started by xterm when started from the X tray menu when X is started from the start menu short cut, and can also be demonstrated with 'bash -c bash') This time, with link :-) [1] http://cygwin.com/ml/cygwin/2010-02/msg00503.html
RE: Up for new maintainer - base-files and base-passwd
Since so little is in the base-cygwin and base-passwd packages, might it make sense to fold them into base-files? - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: Up for new maintainer - base-files and base-passwd (gold star)
On Tue, Sep 14, 2010 at 10:22:18AM +0100, John Morrison wrote: On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote: Thanks for the time and effort you invested into these packages. Thanks to you (and Chris) for putting so much effort in. I only wish I had the time and skills to help more. I learnt a lot from the Cygwin project and it was a definate shove to moving (at home at least) to a 100% *nix base. Right back at you. I appreciate anyone who helps and your packages were instrumental for Cygwin's success. Could we get a gold star for John for his years of service? Or maybe a gold watch would be more appropriate. cgf P.S. Sorry that you had problems sending your message to cygwin-apps.
Re: [ITP] mingw-w64 Second try
On Tue, Sep 14, 2010 at 05:58:08AM +0100, Andy Koppe wrote: On 13 September 2010 18:26, Charles Wilson wrote: On 9/13/2010 6:52 AM, JonY wrote: OK, new headers tarballs up. Thanks for keeping an eye out. All packages are uploaded. A big round of applause for JonY, Chuck, and Yaakov for the huge amount of work they've put into this. Hear, hear! cgf
Re: Up for new maintainer - base-files and base-passwd
On 9/14/2010 9:35 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote: Since so little is in the base-cygwin and base-passwd packages, might it make sense to fold them into base-files? No, IIRC there are issues with circular dependencies. Since these packages live very close to the root of the dependency tree, we have to be careful about the structure of the tree at that level. Merging packages together (e.g. grafting branches in the tree) needs to be considered VERY carefully. -- Chuck
Re: Up for new maintainer - base-files and base-passwd (gold star)
On Tue, Sep 14, 2010 at 10:22:18AM +0100, John Morrison wrote: On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote: Thanks for the time and effort you invested into these packages. Thanks to you (and Chris) for putting so much effort in. I only wish I had the time and skills to help more. I learnt a lot from the Cygwin project and it was a definate shove to moving (at home at least) to a 100% *nix base. Right back at you. I appreciate anyone who helps and your packages were instrumental for Cygwin's success. Could we get a gold star for John for his years of service? Or maybe a gold watch would be more appropriate. Gold watch awarded: http://cygwin.com/goldstars/#JM .
Re: Up for new maintainer - base-files and base-passwd (gold star)
On Tue, Sep 14, 2010 at 01:36:34PM -0400, Andrew Schulman wrote: On Tue, Sep 14, 2010 at 10:22:18AM +0100, John Morrison wrote: On Tue, September 14, 2010 9:54 am, Corinna Vinschen wrote: Thanks for the time and effort you invested into these packages. Thanks to you (and Chris) for putting so much effort in. I only wish I had the time and skills to help more. I learnt a lot from the Cygwin project and it was a definate shove to moving (at home at least) to a 100% *nix base. Right back at you. I appreciate anyone who helps and your packages were instrumental for Cygwin's success. Could we get a gold star for John for his years of service? Or maybe a gold watch would be more appropriate. Gold watch awarded: http://cygwin.com/goldstars/#JM . Awesome. Thanks Andrew. I was hoping that you'd take the challenge of delivering on a gold watch. cgf
Re: Up for new maintainer - base-files and base-passwd (gold star)
On Tue, September 14, 2010 6:49 pm, Andrew Schulman wrote: Gold watch awarded: http://cygwin.com/goldstars/#JM . Awesome. Thanks Andrew. I was hoping that you'd take the challenge of delivering on a gold watch. No image is too great to scale here at cygwin.com. Thankyou :) I'll appreciate it always. J.
Keyboard layout is not automatically detected.
Hi, My keyboard layout is not automatically detected. Relevant info according to your FAQ is below: /var/log/XWin.0.log : [ 4704.046] (--) Windows keyboard layout: 041F (041f) Turkish Q, type 4 [ 4704.046] (EE) Keyboardlayout Turkish Q (041F) is unknown, using X server default layout setxkbmap tr command fixes layout problem. Link of description of the layout: http://www.microsoft.com/resources/msdn/goglobal/keyboards/kbdtuq.htm Thanks, Özgür -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Keyboard layout is not automatically detected.
On 14/09/2010 09:15, Ozgur Murat Homurlu wrote: My keyboard layout is not automatically detected. Relevant info according to your FAQ is below: /var/log/XWin.0.log : [ 4704.046] (--) Windows keyboard layout: 041F (041f) Turkish Q, type 4 [ 4704.046] (EE) Keyboardlayout Turkish Q (041F) is unknown, using X server default layout setxkbmap tr command fixes layout problem. Thanks for reporting this, and the information necessary to fix it Patch to follow to add automatic detection for Turkish Q and Turkish F keyboard layouts Hopefully, this should get added to the next X server release -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Cygwin/X: Add turkish keyboard layouts to keyboard layout mapping table
0x041f Turkish Q = layout tr
0x0001041f Turkish F = layout tr variant f
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winlayouts.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/xwin/winlayouts.h b/hw/xwin/winlayouts.h
index f5397e3..d7a9f27 100644
--- a/hw/xwin/winlayouts.h
+++ b/hw/xwin/winlayouts.h
@@ -81,6 +81,8 @@ WinKBLayoutRec winKBLayouts[] =
{ 0x816, -1, pc105, pt, NULL, NULL, Portuguese (Portugal)},
{ 0x41a, -1, pc105, hr, NULL, NULL, Croatian},
{ 0x41d, -1, pc105, se, NULL, NULL, Swedish (Sweden)},
+{ 0x41f, -1, pc105, tr, NULL, NULL, Turkish (Q)},
+{0x1041f, -1, pc105, tr, f, NULL, Turkish (F)},
{ 0x424, -1, pc105, si, NULL, NULL, Slovenian},
{ 0x425, -1, pc105, ee, NULL, NULL, Estonian},
{ 0x452, -1, pc105, gb, intl, NULL, United Kingdom
(Extended)},
--
1.7.1
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
On 14/09/2010 18:51, Brian Kelly wrote: I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
Thanks Jon for the quick reply. I attached a new log file generated with an attempt to highlight - followed by the hang. Again, this worked PERFECTLY just yesterday. I ran a chkdsk on my system just about an hour ago, and while it repaired a few files, the problem remains. I'll try your -noclipboard suggestion, but unfortunately for me, I do a lot of pasting back and forth between cygwin and native windows. I may have to go back to using the CMD based bash shell console window that is the cygwin default. Not relishing that thought ... Re-imaging my machine is not really an option either - that could set me back a week. Brian Kelly -Original Message- From: Jon TURNEY Sent: Sep 14, 2010 1:47 PM Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text On 14/09/2010 18:51, Brian Kelly wrote: I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer XWin.0.log Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
Also - tried GVim, and it locked when I only got one character highlighted. Tried minTTY, and it works perfectly (of course it's not X-based). The cut-and-paste works flawlessly. Again, why X highlighting and cut-and-paste worked yesterday and not today is the real mystery. The machine has been rebooted numerous times as well - to no avail. Brian Kelly -Original Message- From: Brian Kelly Sent: Sep 14, 2010 2:52 PM Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text Thanks Jon for the quick reply. I attached a new log file generated with an attempt to highlight - followed by the hang. Again, this worked PERFECTLY just yesterday. I ran a chkdsk on my system just about an hour ago, and while it repaired a few files, the problem remains. I'll try your -noclipboard suggestion, but unfortunately for me, I do a lot of pasting back and forth between cygwin and native windows. I may have to go back to using the CMD based bash shell console window that is the cygwin default. Not relishing that thought ... Re-imaging my machine is not really an option either - that could set me back a week. Brian Kelly -Original Message- From: Jon TURNEY Sent: Sep 14, 2010 1:47 PM Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text On 14/09/2010 18:51, Brian Kelly wrote: I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
On 9/14/2010 4:05 PM, Brian Kelly wrote: Also - tried GVim, and it locked when I only got one character highlighted. Tried minTTY, and it works perfectly (of course it's not X-based). The cut-and-paste works flawlessly. Again, why X highlighting and cut-and-paste worked yesterday and not today is the real mystery. The machine has been rebooted numerous times as well - to no avail. You might want to look at what Windows, virus, and spyware updates occurred recently. It's also possible this is interference from BLODA. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
Jon - I tried the -noclipboard option, and you were right. I can now highlight and cut-and-paste within the X environment. Hope that helps you. In the meantime, I will use minTTY, and try to get along without X-based GVim. I sure hope you can find something to correct. I will cooperate and try to give you anything you need from me that might assist. Thanks, Brian Kelly -Original Message- From: Jon TURNEY Sent: Sep 14, 2010 1:47 PM Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text On 14/09/2010 18:51, Brian Kelly wrote: I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-14 14:10:40 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (symlink_info::check): Make sure AllocationSize and EndOfFile are stored in the right order when fetching the info from the NtQueryDirectoryFile result. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5042r2=1.5043 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.607r2=1.608
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
On Sep 13 13:28, Yoni Londner wrote:
Hi,
However, isn't that kind of a chicken/egg situation? If you want to
reuse the content of the FILE_BOTH{_ID}_DIRECTORY_INFORMATION structure
from a previous call to readdir, you would have to call the
I am not talking about reusing info from a previous readdir.
Every single file cygwin tries to access, it does it in a loop,
trying afterwards to check for *.lnk file.
Using the directory query operations, it is possible to get this
info faster:
instead of getting file info for FOO and then for FOO.lnk,
Cygwin can query the directory info for FOO FOO.LNK (for the file
requested, plus its possible symlink file).
I don't understand how you think this should work. The filter expression
given to NtQueryDirectoryFile is either a constant string and has to match
the filename exactly, or it contains wildcards. This is documented
behaviour: http://msdn.microsoft.com/en-us/library/ff567047%28VS.85%29.aspx
So, foo works, foo* works, but a list like foo foo.exe foo.lnk
does not.
There's also the problem of handling NFS shares. However, I just had an
idea how to speed up symlink_info::check without neglecting NFS shares.
This will take some time, though since it turns a lot of code upside
down. Stay tuned.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 13:11, Andy Koppe wrote: On 14 September 2010 03:13, JonY wrote: Version 4.5.1-1 of mingw64-x86_64-gcc has been uploaded. mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain. See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc, mingw64-x86_64-gcc-ada, mingw64-x86_64-gcc-g++ and mingw64-x86_64-gcc-fortran for binaries. Great stuff. First issue: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way. $ /bin/x86_64-w64-mingw32-gcc hello.c -v Using built-in specs. COLLECT_GCC=/bin/x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/user/cygp6/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1/src/gcc-4.5.1/configure --srcdir=/home/user/cygp6/mingw64-x86_64-gcc/mingw64-x86_64-gcc-4.5.1-1/src/gcc-4.5.1 -C --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/mingw64-x86_64-gcc --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,ada,c++,fortran,objc,obj-c++ --enable-fully-dynamic-strings --enable-libgomp --enable-sjlj-exceptions --enable-version-specific-runtime-libs --with-dwarf2 --enable-decimal-float=bid --enable-lto Thread model: win32 gcc version 4.5.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/cc1.exe -quiet -v -iprefix /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/ hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o /Users/Andy/AppData/Local/Temp/ccLGdDIT.s GNU C (GCC) version 4.5.1 (x86_64-w64-mingw32) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include ignoring nonexistent directory /usr/x86_64-w64-mingw32/sys-root/usr/local/include ignoring duplicate directory /bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/include ignoring duplicate directory /bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/include-fixed ignoring nonexistent directory /bin/../lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include #include ... search starts here: #include... search starts here: /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/include /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/include-fixed /usr/x86_64-w64-mingw32/sys-root/mingw/include End of search list. GNU C (GCC) version 4.5.1 (x86_64-w64-mingw32) compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 80e7a582a443f3cfd9d86919d58b0d54 COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' as -v -o /Users/Andy/AppData/Local/Temp/ccD8vdf5.o /Users/Andy/AppData/Local/Temp/ccLGdDIT.s GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils) 2.20.51.20100410 /Users/Andy/AppData/Local/Temp/ccLGdDIT.s: Assembler messages: /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/ccLGdDIT.s:14: Error: bad register name `%rip)' Andy That is weird. Do you have mingw64 binutils installed? Somehow the cygwin binutils was used. -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 2:57 AM, JonY wrote: That is weird. Do you have mingw64 binutils installed? Somehow the cygwin binutils was used. I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a bug in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a bug in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 15:29, Charles Wilson wrote: On 9/14/2010 2:57 AM, JonY wrote: That is weird. Do you have mingw64 binutils installed? Somehow the cygwin binutils was used. I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a bug in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a bug in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck So, if /usr/x86_64-w64-mingw32 actually exists, it works? This looks bad, nonetheless. Maybe we can fix cygwin by only redirecting known directories like, /usr/bin and /usr/lib to those in /. It would probably break third party apps, so its not entirely good either. -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On Sep 14 15:30, JonY wrote: On 9/14/2010 15:29, Charles Wilson wrote: I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a bug in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a bug in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck So, if /usr/x86_64-w64-mingw32 actually exists, it works? This looks bad, nonetheless. Maybe we can fix cygwin by only redirecting known directories like, /usr/bin and /usr/lib to those in /. Cygwin doesn't redirect any /usr dirs to /. There are default mount points for /usr/bin - /bin and /usr/lib - lib. That's all. The problematic path is generated in gcc itself. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 13 19:47, John Carey wrote: On Sep 11 03:30, Corinna Vinschen: Given that, wouldn't it be potentially possible to override the content of curCwd? The problem is probably (just as in my old Cygwin code up to 1.7.5) to make sure that this is thread safe. Probably we would still need CwdCS. Unfortunately, it looks as if Win32 API functions guarantee to each other that they will not modify the path in a VistaCwd whose reference count is = 2. (Though it looks like they may update OldDismountCount under a CwdCS lock.) Consider RtlGetCurrentDirectory_U(). It shares a (non-exported) subroutine with other Win32 API functions that acquires a counted reference to the current VistaCwd instance under the protection of a lock on CwdCS. (This subroutine also does some kind of freshness check against DismountCount.) But that subroutine releases its lock before returning, and RtlGetCurrentDirectory_U() then uses the pathname in the returned VistaCwd instance *without* holding a lock. Specifically, it copies that pathname to a memory buffer passed in by its own caller. Pathname copies are not atomic. Thus, unless there is a bug in RtlGetCurrentDirectory_U(), it has some guarantee that other threads will not modify the pathname in its VistaCwd instance, though they are free to allocate a new VistaCwd instance and assign its address to the global Cwd pointer (so long as they lock CwdCS). Presumably the point of the Vista++ CWD mechanism is to reduce contention on the CWD lock. Threads acquire that lock for very short periods of time. They appear to avoid making system calls or even allocating memory while holding it. Also, the CWD lock is no longer the PEB lock, so CWD usage does not serialize with other PEB-related activities. Anyway, it looks to me as if overwriting the path in an existing VistaCwd instance would confuse RtlGetCurrentDirectory_U() and probably other Win32 API functions. (It may be that the same is true for the handle member; I have not tried to find that out.) Cygwin should probably allocate a new VistaCwd instance, as does the Win32 SetCurrentDirectory() implementation. Hmm, I'm still wondering. In theory we don't have to replace the directory name. We just have to InterlockedExchange the handle, since we only need to replace the original handle which does not allow sharing-for-delete with our own handle which does. All other border cases (virtual dir, directory with restricted rights) can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again. That's at least worth a try, isn't it? == critical section endl; cout showbase hex (size_t)Cwd == Vista++ CWD struct pointer endl; Is there any connection between these two addresses, like, say, they are side by side? Not that I have been able to find. The gap between Cwd and CwdCS is always positive, but is large and varies among OS versions: Bummer. I was hoping that these global variables could be identified as part of some other global structure for which there is an easier way to find it's address. Can't we find Cwd by scanning the .data segment of ntdll.h for the address we inferred from the Params.CurrentDirectoryName.Buffer value? Nice; that might work. But there would need to be some kind of rule to pick a winner among multiple matching words, in case by coincidence some other non-pointer word just happens to have the same bit pattern. I can see two alternatives for the multiple-match case: 1. Code scanning, as suggested earlier. There would need to be a unit test of the code scanner itself so that incompatible changes to ntdll.dll could be detected deterministically, instead of only after a multiple-match coincidence. 2. Call SetCurrentDirectory() and recheck the previously-matching addresses to see which one matches the new value. Place some limit (like 4) on the number of such retries, in case some new version of ntdll.dll intentionally duplicates the pointer every time. (Not sure what to do in that case; fall back to code scanning?) Sounds like code scanning is the better choice then. Your code scanner isn't overly complicated anyway, and it has the advantage of being rather fast. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Deletion race in NtSetFileInformation ? (Directory not empty error in rm -r -f)
On Sep 13 14:20, Earl Chew wrote: I have a Makefile which performs rm -f -r as part of a clean target. On Win7 with 1.7.5-1 this can fail with: rm -f -r win32 rm: cannot remove directory `win32': Directory not empty I tried 1.7.7-1 but the problem still seems to be there. Doing a little digging, I find that /bin/rm calls unlinkat(win32/dll), which eventually calls unlink_nt(). A short time later, /bin/rm calls unlink_at(win32) and fails at check_dir_not_empty() because it finds the following entries:: 413407 [main] rm 3612 check_dir_not_empty: File name: 2 0x2E 0x610E 0x10 . 413493 [main] rm 3612 check_dir_not_empty: File name: 4 0x2E 0x2E 0x18 .. 413574 [main] rm 3612 check_dir_not_empty: File name: 6 0x64 0x6C 0x6C dll Huh? Wasn't this the directory that was just deleted? Taking a look in the directory after the fact shows that the parent directory appears to be empty : W: dir win32 Volume in drive W is OS Volume Serial Number is C0E0-BBEE Directory of W:\cerberus\acl\col_\ato\win32 13/09/2010 01:57 PMDIR . 13/09/2010 01:57 PMDIR .. 0 File(s) 0 bytes 2 Dir(s) 392,720,297,984 bytes free Hmm ... my reading of unlink_nt() is that the directory win32/dll is deleted by setting FileDispositionInformation via NtSetFileInformation(). Yes, that's how it is done by the Win32 API as well. Since the file entry seems to be found during the subsequent check_dir_not_empty() call when trying to delete the parent directory, is some form of explicit synchronisation required when deleting the child win32/dll to be sure that the deletion is actually complete? There shouldn't be any race. When you set the delete disposition, the file is actually deleted as soon as the last handle to the file is closed. If the file isn't opened by another process, it will disappear right at the NtClose at the end of unlink_nt. Please note that the call to check_dir_not_empty already takes place *only* if trying to open the directory failed with STATUS_SHARING_VIOLATION. So there *was* another process blocking things. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
--- Mar 14/9/10, ha scritto: On 9/14/2010 13:11, Andy Koppe wrote: On 14 September 2010 03:13, JonY wrote: Version 4.5.1-1 of mingw64-x86_64-gcc has been uploaded. mingw64-x86_64-gcc contains GCC sources used by the 64bit target toolchain. See mingw64-x86_64-gcc-core, mingw64-x86_64-gcc-objc, mingw64-x86_64-gcc-ada, mingw64-x86_64-gcc-g++ and mingw64-x86_64-gcc-fortran for binaries. Great stuff. First issue: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way. $ /bin/x86_64-w64-mingw32-gcc hello.c -v Using built-in specs. COLLECT_GCC=/bin/x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Andy That is weird. Do you have mingw64 binutils installed? Somehow the cygwin binutils was used. It is not so weird, I have already seen it in other programs that expect to be installed in /usr/bin and are unable to find the other portions if they are called from /bin Instead of /bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe that doesn't work /usr/bin/../lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe means /usr/lib/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Usually assuring the /usr/bin is before /bin in the path solves the problems. For cygwin we could also remove /bin at all from the path. Marco -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 16:03, Corinna Vinschen wrote: On Sep 14 15:30, JonY wrote: On 9/14/2010 15:29, Charles Wilson wrote: I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a bug in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a bug in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck So, if /usr/x86_64-w64-mingw32 actually exists, it works? This looks bad, nonetheless. Maybe we can fix cygwin by only redirecting known directories like, /usr/bin and /usr/lib to those in /. Cygwin doesn't redirect any /usr dirs to /. There are default mount points for /usr/bin - /bin and /usr/lib - lib. That's all. The problematic path is generated in gcc itself. Corinna What do you suggest the fix should be? -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 14 September 2010 11:15, Marco Atzeri wrote: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way Usually assuring the /usr/bin is before /bin in the path solves the problems. /usr/bin is put before /bin in /etc/profile anyway, so it's not a critical issue. I just happened to try it with the /bin prefix first, probably because I was using tab completion on /bin to find the executable name of the compiler. Andy -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 18:46, Andy Koppe wrote: On 14 September 2010 11:15, Marco Atzeri wrote: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way Usually assuring the /usr/bin is before /bin in the path solves the problems. /usr/bin is put before /bin in /etc/profile anyway, so it's not a critical issue. I just happened to try it with the /bin prefix first, probably because I was using tab completion on /bin to find the executable name of the compiler. Andy OK, so calling x86_64-w64-mingw32-gcc or /usr/bin/x86_64-w64-mingw32-gcc in the shell usually works, but not /bin/x86_64-w64-mingw32-gcc? -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 14 September 2010 11:40, JonY wrote: On 9/14/2010 18:46, Andy Koppe wrote: On 14 September 2010 11:15, Marco Atzeri wrote: Is this to be expected? $ x86_64-w64-mingw32-gcc hello.c [compiles fine] $ /bin/x86_64-w64-mingw32-gcc hello.c /Users/Andy/AppData/Local/Temp/cckcwv49.s: Assembler messages: /Users/Andy/AppData/Local/Temp/cckcwv49.s:10: Error: bad register name `%rbp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:11: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:12: Error: bad register name `%rsp' /Users/Andy/AppData/Local/Temp/cckcwv49.s:14: Error: bad register name `%rip)' It's obviously picking up the wrong assembler that way Usually assuring the /usr/bin is before /bin in the path solves the problems. /usr/bin is put before /bin in /etc/profile anyway, so it's not a critical issue. I just happened to try it with the /bin prefix first, probably because I was using tab completion on /bin to find the executable name of the compiler. OK, so calling x86_64-w64-mingw32-gcc or /usr/bin/x86_64-w64-mingw32-gcc in the shell usually works, but not /bin/x86_64-w64-mingw32-gcc? Exactly. Andy -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On Sep 14 18:15, JonY wrote: On 9/14/2010 16:03, Corinna Vinschen wrote: On Sep 14 15:30, JonY wrote: On 9/14/2010 15:29, Charles Wilson wrote: I don't know about Andy, but I sure do -- and I can reproduce his problem. I suspect there is a bug in how the cross tool locates the /usr/x86_64-w64-mingw32/bin directory, given the mount structure: /usr/bin = /bin /usr/lib = /lib BUT /usr/x86_64-w64-mingw32 != /x86_64-w64-mingw32 because if I do THIS: mount -o bind /usr/x86_64-w64-mingw32 /x86_64-w64-mingw32 then /bin/x86_64-w64-mingw32-gcc -o foo foo.c works, just as if I had invoked x86_64-w64-mingw32-gcc -o foo foo.c I say this is a bug in quotes, because...well, I'm not sure it fits the definition. It's *our* fault we use a wacky mount structure on cygwin... -- Chuck So, if /usr/x86_64-w64-mingw32 actually exists, it works? This looks bad, nonetheless. Maybe we can fix cygwin by only redirecting known directories like, /usr/bin and /usr/lib to those in /. Cygwin doesn't redirect any /usr dirs to /. There are default mount points for /usr/bin - /bin and /usr/lib - lib. That's all. The problematic path is generated in gcc itself. Corinna What do you suggest the fix should be? I really don't know, but it's certainly not a fix in Cygwin. The fact that /usr/bin is a mount point to /bin is nothing which wouldn't be allowed under Linux as well. There's a default mechanism in gcc which evaluates the paths to the tools, headers and libdb dirs by massaging the $prefix and $exec_prefix values in some way. I assume you can work around this issue by using slightly different values, but I'm not fluent enough with the path evaluationin gcc to suggest the correct solution, for a given value of correct. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: qhull-2010.1.-2
New versions 2010.1-2 of libqhull-devel, libqhull_6, qhull have been uploaded for cygwin. libqhull_5 version revert to previous 2009.1.1-1 CHANGES The previous 2010.1-1 was faulty as a soversion bump was needed for libqhull. As all the linux distributions as still on 2009 or 2003 version the bump was unnoticed. (And not reported on the upstream Changes.txt :-( ) Moreover the /usr/bin/cygqhull-5.dll was incorrectly built as /usr/bin/cygqhull.dll causing octave to fail when libqhull was called. http://cygwin.com/ml/cygwin/2010-09/msg00152.html Qhull 2010.1-2 built using Yaakov cmake-2.8.1-11 For the full changes http://www.qhull.org/src/Changes.txt DESCRIPTION Qhull is a general dimension convex hull program and library It computes volumes, surface areas, and approximations to the convex hull. HOMEPAGE http://www.qhull.org/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: [ANNOUNCEMENT] New package: mingw64-x86_64-gcc-4.5.1-1
On 9/14/2010 7:18 AM, Corinna Vinschen wrote: On Sep 14 18:15, JonY wrote: What do you suggest the fix should be? I really don't know, but it's certainly not a fix in Cygwin. The fact that /usr/bin is a mount point to /bin is nothing which wouldn't be allowed under Linux as well. There's a default mechanism in gcc which evaluates the paths to the tools, headers and libdb dirs by massaging the $prefix and $exec_prefix values in some way. I assume you can work around this issue by using slightly different values, but I'm not fluent enough with the path evaluationin gcc to suggest the correct solution, for a given value of correct. Actually, I don't think this problem is all that critical. I think that in order to trigger it, you have to do some fairly unusual things: set your $PATH so that /bin precedes /usr/bin (which, in most cases, has zero effect...so why would you do that?), or deliberately invoke the compiler by one of its full PATH specifications (that is not the usual /usr/bin/ one). I think I'd just put a note in the README, the Port Notes section, like this: = If you invoke the compiler or other tools using a path like this: /bin/x86_64-w64-mingw32-gcc ... rather than these /usr/bin/x86_64-w64-mingw32-gcc ... x86_64-w64-mingw32-gcc ... you may see errors. If you must invoke the compiler using the /bin formulation, you can avoid these errors by creating a temporary mount point (or add the following to your ~/.bashrc): mount -o bind /usr/x86_64-w32-mingw32 /x86_64-w32-mingw32 = This can certainly wait until the next normal package update. At least, that's my opinion... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: maradns-1.4.04-1
Version 1.4.04-1 of 'maradns' has been uploaded to the Cygwin archive, superceding 1.4.03-2, which remains available as the previous version. MaraDNS is a package that implements the Domain Name Service (DNS), an essential internet service. For full details, see the project website: http://www.maradns.org/ According to the changelog on the project website, the changes to the MaraDNS software package since the previous release are as follows: - Bugfix: NAPTR records now work when ~ is used to separate records - NAPTR records now documented - Bugfix: ANY queries now correctly work with NS referrals - Example IPv6 addresses now use RFC-4193 compliant IPs -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
1.7.7: STATUS_ACCESS_VIOLATION bug
Hi, While trying to run 'gvim', we get the following messages: ** bash-3.2$ gvim 4 [main] gvim 6964 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1184 [main] gvim 6964 open_stackdumpfile: Dumping stack trace to gvim.exe.stackdump 2 [main] gvim 1020 exception::handle: Exception: STATUS_ACCESS_VIOLATION 815 [main] gvim 1020 open_stackdumpfile: Dumping stack trace to gvim.exe.stackdump 2 [main] gvim 1064 exception::handle: Exception: STATUS_ACCESS_VIOLATION 737 [main] gvim 1064 open_stackdumpfile: Dumping stack trace to gvim.exe.stackdump 4 [main] gvim 6844 exception::handle: Exception: STATUS_ACCESS_VIOLATION 897 [main] gvim 6844 open_stackdumpfile: Dumping stack trace to gvim.exe.stackdump 4 [main] gvim 7940 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1774 [main] gvim 7940 open_stackdumpfile: Dumping stack trace to gvim.exe.stackdump 4 [main] gvim 7236 C:\cygwin\bin\gvim.exe: *** fatal error - unable to remap _\\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to same address as parent: 0x5D != 0x60 Stack trace: Frame Function Args 0028B678 6102749B (0028B678, , , ) 0028B968 6102749B (61177B80, 8000, , 61179977) 0028C998 61004AFB (611A136C, 61242D24, 005D, 0060) End of stack trace 4 [main] gvim 5436 fork: child 7236 - died waiting for dll loading, errno 11 bash-3.2$ ** 'Gvim' works, but is there any way to hide access violation messages and avoid stack dump? Thanks, Tal -- 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: 1.7.7: STATUS_ACCESS_VIOLATION bug
On 9/14/2010 10:40 AM, טל ח wrote: 4 [main] gvim 7236 C:\cygwin\bin\gvim.exe: *** fatal error - unable to remap _\\?\C:\cygwin\lib\gtk-2.0\2.10.0\loaders\cygpixbufloader-xpm.dll to same address as parent: 0x5D != 0x60 Stack trace: Try installing the 'rebase' package, reading /usr/share/doc/Cygwin/rebase-3.0.1.README, and following the instructions there to run 'rebaseall'. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
ssh from linux to cygwin + CUI + Ctrl-C
Hi, All. I've searched quite a lot for the subj and found no solution yet. I've installed the last cygwin+openssh on Windows XP. I want to connect from linux and run some native console applications (non-cygwin CUI, particularly, cdb and cmd) and I need these applications to correctly handle Ctrt-C. If such CUI application is started from local cygwin bash window it handles Ctrl-C properly, but if it's started over ssh Ctrl-C terminates application and the control returns to bash (the one which runs on the server, ssh session doesn't terminate). I would appreciate a solution besides using another remote access program (freessh, VNC, RDP, etc.). Below is my current bash environment when run from sshd (note, CYGWIN is unset and TERM=xterm). HOMEPATH=\cygwin\home\user MANPATH=/usr/local/man:/usr/share/man:/usr/man: _NT_DEBUG_LOG_FILE_APPEND=C:\cygwin\home\user\ntdebug.log HOSTNAME=winxp-vbox _NT_SYMBOL_PATH=srv*C:\cygwin\home\user\symbols*http://msdl.microsoft.com/download/symbols;cache*C:\cygwin\home\user\symbols TERM=xterm SHELL=/bin/bash WINDIR=C:\WINDOWS SSH_CLIENT=192.168.56.1 57891 22 MYDIR=/home/user OLDPWD=/home/user USERDOMAIN=NT AUTHORITY SSH_TTY=/dev/tty0 OS=Windows_NT ALLUSERSPROFILE=C:\Documents and Settings\All Users USER=user USERNAME=SYSTEM MAIL=/var/spool/mail/user PATH=/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/bin:/cygdrive/c/Program Files/Bazaar/:/cygdrive/c/Program Files/Debugging Tools for Windows (x86)/ PWD=/home/user SYSTEMDRIVE=C: LANG=C.UTF-8 USERPROFILE=C:\Documents and Settings\user PS1=\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ HISTIGNORE=[]*::[fb]g:exit:ls HISTCONTROL=ignoreboth SHLVL=1 HOME=/home/user PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH HOMEDRIVE=C: COMSPEC=C:\WINDOWS\system32\cmd.exe LOGNAME=user SYSTEMROOT=C:\WINDOWS PRINTER= CVS_RSH=/bin/ssh SSH_CONNECTION=192.168.56.1 57891 192.168.56.101 22 INFOPATH=/usr/local/info:/usr/share/info:/usr/info: COMPUTERNAME=WINXP-VBOX Thanks, Ilia. -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 10:12, Corinna Vinschen wrote:
On Sep 13 19:47, John Carey wrote:
Anyway, it looks to me as if overwriting the path in an existing
VistaCwd instance would confuse RtlGetCurrentDirectory_U() and
probably other Win32 API functions. (It may be that the same is
true for the handle member; I have not tried to find that out.)
Cygwin should probably allocate a new VistaCwd instance,
as does the Win32 SetCurrentDirectory() implementation.
Hmm, I'm still wondering. In theory we don't have to replace the
directory name. We just have to InterlockedExchange the handle, since
we only need to replace the original handle which does not allow
sharing-for-delete with our own handle which does.
All other border cases (virtual dir, directory with restricted rights)
can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again.
That's at least worth a try, isn't it?
I applied the below patch to Cygwin CVS and it appears to work nicely.
The only potential race I can think of is, if another thread of the same
Cygwin process calls SetCurrentDirectory. I'm inclined to let this
situation slip through the cracks since SetCurrentDirectory will already
mess up a mixed-mode Cygwin process.
The wincap.has_transactions () is just for testing. If we can use
that code, I would replace is with something like
wincap.has_messed_up_cwd_handling() or so.
Corinna
Index: cygheap.h
===
RCS file: /cvs/src/src/winsup/cygwin/cygheap.h,v
retrieving revision 1.146
diff -u -p -r1.146 cygheap.h
--- cygheap.h 13 Aug 2010 11:51:53 - 1.146
+++ cygheap.h 14 Sep 2010 16:10:45 -
@@ -217,6 +217,8 @@ private:
a native Win32 application. See cwdstuff::set for
how it gets set. See spawn_guts for how it's
evaluated. */
+ void override_win32_cwd ();
+
public:
UNICODE_STRING win32;
static muto cwd_lock;
Index: path.cc
===
RCS file: /cvs/src/src/winsup/cygwin/path.cc,v
retrieving revision 1.608
diff -u -p -r1.608 path.cc
--- path.cc 14 Sep 2010 14:10:39 - 1.608
+++ path.cc 14 Sep 2010 16:10:45 -
@@ -3363,6 +3363,29 @@ get_user_proc_parms ()
return NtCurrentTeb ()-Peb-ProcessParameters;
}
+struct VistaCwd {
+ volatile LONG ReferenceCount;
+ HANDLE DirectoryHandle;
+ ULONG OldDismountCount;
+ UNICODE_STRING Path;
+ wchar_t Buffer[MAX_PATH];
+};
+
+void
+cwdstuff::override_win32_cwd ()
+{
+ if (wincap.has_transactions ())
+{
+ VistaCwd *v_cwd = (VistaCwd *)
+ ((PBYTE) get_user_proc_parms ()-CurrentDirectoryName.Buffer
+ - __builtin_offsetof (VistaCwd, Buffer));
+ (void) InterlockedExchangePointer (v_cwd-DirectoryHandle, dir);
+}
+ HANDLE h = InterlockedExchangePointer
+ (get_user_proc_parms ()-CurrentDirectoryHandle, dir);
+ NtClose (h);
+}
+
/* Initialize cygcwd 'muto' for serializing access to cwd info. */
void
cwdstuff::init ()
@@ -3370,9 +3393,13 @@ cwdstuff::init ()
cwd_lock.init (cwd_lock);
/* Cygwin processes inherit the cwd from their parent. If the win32 path
- buffer is not NULL, the cwd struct is already set up. */
- if (win32.Buffer)
-return;
+ buffer is not NULL, the cwd struct is already set up, and we only
+ have to override the Win32 CWD with ours. */
+ if (win32.Buffer !error)
+{
+ override_win32_cwd ();
+ return;
+}
/* Initially re-open the cwd to allow POSIX semantics. */
set (NULL, NULL);
@@ -3570,13 +3597,12 @@ cwdstuff::set (path_conv *nat_cwd, const
}
/* Keep the Win32 CWD in sync. Don't check for error, other than for
strace output. Try to keep overhead low. */
- if (nat_cwd)
-{
- status = RtlSetCurrentDirectory_U (error ? ro_u_pipedir : win32);
- if (!NT_SUCCESS (status))
- debug_printf (RtlSetCurrentDirectory_U(%S) failed, %p,
- error ? ro_u_pipedir : win32, status);
-}
+ status = RtlSetCurrentDirectory_U (error ? ro_u_pipedir : win32);
+ if (!NT_SUCCESS (status))
+debug_printf (RtlSetCurrentDirectory_U(%S) failed, %p,
+ error ? ro_u_pipedir : win32, status);
+ else if (!error)
+override_win32_cwd ();
/* Eventually, create POSIX path if it's not set on entry. */
tmp_pathbuf tp;
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 18:11, Corinna Vinschen wrote: On Sep 14 10:12, Corinna Vinschen wrote: On Sep 13 19:47, John Carey wrote: Anyway, it looks to me as if overwriting the path in an existing VistaCwd instance would confuse RtlGetCurrentDirectory_U() and probably other Win32 API functions. (It may be that the same is true for the handle member; I have not tried to find that out.) Cygwin should probably allocate a new VistaCwd instance, as does the Win32 SetCurrentDirectory() implementation. Hmm, I'm still wondering. In theory we don't have to replace the directory name. We just have to InterlockedExchange the handle, since we only need to replace the original handle which does not allow sharing-for-delete with our own handle which does. All other border cases (virtual dir, directory with restricted rights) can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again. That's at least worth a try, isn't it? I applied the below patch to Cygwin CVS and it appears to work nicely. Sorry, that wasn't what I was trying to say. Actually, I'm using this code just locally for now and put it up here for discussion and for curious testers. I intend to apply it only, if we can agree that it's sufficient. The only potential race I can think of is, if another thread of the same Cygwin process calls SetCurrentDirectory. I'm inclined to let this situation slip through the cracks since SetCurrentDirectory will already mess up a mixed-mode Cygwin process. The wincap.has_transactions () is just for testing. If we can use that code, I would replace is with something like wincap.has_messed_up_cwd_handling() or so. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Deletion race in NtSetFileInformation ? (Directory not empty error in rm -r -f)
There shouldn't be any race. When you set the delete disposition, the file is actually deleted as soon as the last handle to the file is closed. If the file isn't opened by another process, it will disappear right at the NtClose at the end of unlink_nt. Please note that the call to check_dir_not_empty already takes place *only* if trying to open the directory failed with STATUS_SHARING_VIOLATION. So there *was* another process blocking things. Corinna, Yes, I noticed that check wrt STATUS_SHARING_VIOLATION. These actions are performed consequential to a shell script, that launches a Makefile, that performs the rm -r -f ... so within that context there is definitely scope for oversight and we might inadvertently have a process getting in the way. When you describe the other process blocking things, what might that other process be doing? I presume that other process having the directory in question open, or as cwd is sufficient. Is there anything else I should be on the lookout for? Earl -- 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: Deletion race in NtSetFileInformation ? (Directory not empty error in rm -r -f)
On Sep 14 09:39, Earl Chew wrote: There shouldn't be any race. When you set the delete disposition, the file is actually deleted as soon as the last handle to the file is closed. If the file isn't opened by another process, it will disappear right at the NtClose at the end of unlink_nt. Please note that the call to check_dir_not_empty already takes place *only* if trying to open the directory failed with STATUS_SHARING_VIOLATION. So there *was* another process blocking things. Corinna, Yes, I noticed that check wrt STATUS_SHARING_VIOLATION. These actions are performed consequential to a shell script, that launches a Makefile, that performs the rm -r -f ... so within that context there is definitely scope for oversight and we might inadvertently have a process getting in the way. When you describe the other process blocking things, what might that other process be doing? I presume that other process having the directory in question open, or as cwd is sufficient. ...or having a cwd below the directory. Trying to remove a directory which is the CWD of some process is the most common reason that the directory is blocked, because the Win32 CWD is opened without the FILE_SHARE_DELETE flag. Especially something like `rm -rf ../foo' is suspicious, if foo is the CWD of the current shell. We're trying to revert this to the Linux way again in 1.7.8 (see the thread starting at http://cygwin.com/ml/cygwin/2010-09/msg00342.html), but even after that the problem remains for any non-Cygwin process. Is there anything else I should be on the lookout for? Virus scanners, etc. There *might* be some unfortunate interaction with a scanner which keeps handles of just deleted files or dirs open. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 01:12, Corinna Vinschen wrote: On Sep 13 19:47, John Carey wrote: On Sep 11 03:30, Corinna Vinschen: Anyway, it looks to me as if overwriting the path in an existing VistaCwd instance would confuse RtlGetCurrentDirectory_U() and probably other Win32 API functions. (It may be that the same is true for the handle member; I have not tried to find that out.) Cygwin should probably allocate a new VistaCwd instance, as does the Win32 SetCurrentDirectory() implementation. Hmm, I'm still wondering. In theory we don't have to replace the directory name. We just have to InterlockedExchange the handle, since we only need to replace the original handle which does not allow sharing-for-delete with our own handle which does. All other border cases (virtual dir, directory with restricted rights) can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again. That's at least worth a try, isn't it? Oh, I had thought that you wanted it for long paths and directories with restricted rights, too. There's one other issue: the new directory will limit deletion very briefly, until replaced. I don't know if that will bother people as much as the current situation. -- John -- 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: ssh from linux to cygwin + CUI + Ctrl-C
Hi there. I've had the same problem in the past. Posted a temporary solution here: http://www.cygwin.com/ml/cygwin/2009-02/msg00403.html Best regards, KarHeng Ilia K. wrote: Hi, All. I've searched quite a lot for the subj and found no solution yet. I've installed the last cygwin+openssh on Windows XP. I want to connect from linux and run some native console applications (non-cygwin CUI, particularly, cdb and cmd) and I need these applications to correctly handle Ctrt-C. If such CUI application is started from local cygwin bash window it handles Ctrl-C properly, but if it's started over ssh Ctrl-C terminates application and the control returns to bash (the one which runs on the server, ssh session doesn't terminate). I would appreciate a solution besides using another remote access program (freessh, VNC, RDP, etc.). Below is my current bash environment when run from sshd (note, CYGWIN is unset and TERM=xterm). HOMEPATH=\cygwin\home\user MANPATH=/usr/local/man:/usr/share/man:/usr/man: _NT_DEBUG_LOG_FILE_APPEND=C:\cygwin\home\user\ntdebug.log HOSTNAME=winxp-vbox _NT_SYMBOL_PATH=srv*C:\cygwin\home\user\symbols*http://msdl.microsoft.com/download/symbols;cache*C:\cygwin\home\user\symbols TERM=xterm SHELL=/bin/bash WINDIR=C:\WINDOWS SSH_CLIENT=192.168.56.1 57891 22 MYDIR=/home/user OLDPWD=/home/user USERDOMAIN=NT AUTHORITY SSH_TTY=/dev/tty0 OS=Windows_NT ALLUSERSPROFILE=C:\Documents and Settings\All Users USER=user USERNAME=SYSTEM MAIL=/var/spool/mail/user PATH=/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/bin:/cygdrive/c/Program Files/Bazaar/:/cygdrive/c/Program Files/Debugging Tools for Windows (x86)/ PWD=/home/user SYSTEMDRIVE=C: LANG=C.UTF-8 USERPROFILE=C:\Documents and Settings\user PS1=\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ HISTIGNORE=[]*::[fb]g:exit:ls HISTCONTROL=ignoreboth SHLVL=1 HOME=/home/user PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH HOMEDRIVE=C: COMSPEC=C:\WINDOWS\system32\cmd.exe LOGNAME=user SYSTEMROOT=C:\WINDOWS PRINTER= CVS_RSH=/bin/ssh SSH_CONNECTION=192.168.56.1 57891 192.168.56.101 22 INFOPATH=/usr/local/info:/usr/share/info:/usr/info: COMPUTERNAME=WINXP-VBOX Thanks, Ilia. -- 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
Reinstalled gcc, make, automake: now BASH stackdumps LR
Might there be something else a little off? The text from the latest stackdump: Stack trace: Frame Function Args The rest is blank. Should I be concerned, or is this something that will work itself out? Steve W. -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 17:39, John Carey wrote: On Sep 14 01:12, Corinna Vinschen wrote: On Sep 13 19:47, John Carey wrote: On Sep 11 03:30, Corinna Vinschen: Anyway, it looks to me as if overwriting the path in an existing VistaCwd instance would confuse RtlGetCurrentDirectory_U() and probably other Win32 API functions. (It may be that the same is true for the handle member; I have not tried to find that out.) Cygwin should probably allocate a new VistaCwd instance, as does the Win32 SetCurrentDirectory() implementation. Hmm, I'm still wondering. In theory we don't have to replace the directory name. We just have to InterlockedExchange the handle, since we only need to replace the original handle which does not allow sharing-for-delete with our own handle which does. All other border cases (virtual dir, directory with restricted rights) can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again. That's at least worth a try, isn't it? Oh, I had thought that you wanted it for long paths and directories with restricted rights, too. That would be nice, but to me it looks like the Win32 API is just too restricted for that, so that it won't make much sense. The native API can't make any assumption that it would work in such a scenario. Most Win32 calls will still not work in a restricted rights CWD, because they neglect to set the FILE_OPEN_FOR_BACKUP_INTENT flag. And most Apps don't set the FILE_FLAG_BACKUP_SEMANTICS flag incalls to CreateFile. As for long paths, there's some chance that the internal calls creating an absolute path from a relative path fail or crash if the CWD is longer than MAX_PATH. What MSDN has to say about the maximum path length of relative paths(*) is not very promising, at least. Also, even if Vista++ allows to create VistaCwd entries with a longer path, this would probably break starting native child processes due to the MAX_PATH restriction for the CWD in calls to CreateProcess. There's one other issue: the new directory will limit deletion very briefly, until replaced. I don't know if that will bother people as much as the current situation. True. Implementing a full replacement for SetCurrentDirectory as in your PoC is still an option. However, I can't do that anymore since I'm tainted by reading your code. If you would contemplate to sign a copyright assignment(**), we could create a more thorough solution with code scanning and all that in the long run. In the meantime, I could apply my patch and we can try how well it works, hacked as it is. Corinna (*) http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 20:59, Corinna Vinschen wrote: On Sep 14 17:39, John Carey wrote: On Sep 14 01:12, Corinna Vinschen wrote: Hmm, I'm still wondering. In theory we don't have to replace the directory name. We just have to InterlockedExchange the handle, since we only need to replace the original handle which does not allow sharing-for-delete with our own handle which does. All other border cases (virtual dir, directory with restricted rights) can be rightfully handled by setting the Win32 CWD to \\?\PIPE\ again. That's at least worth a try, isn't it? Oh, I had thought that you wanted it for long paths and directories with restricted rights, too. That would be nice, but to me it looks like the Win32 API is just too restricted for that, so that it won't make much sense. The native API can't make any assumption that it would work in such a scenario. Most Win32 calls will still not work in a restricted rights CWD, because they neglect to set the FILE_OPEN_FOR_BACKUP_INTENT flag. And most Apps don't set the FILE_FLAG_BACKUP_SEMANTICS flag incalls to CreateFile. As for long paths, there's some chance that the internal calls creating an absolute path from a relative path fail or crash if the CWD is longer than MAX_PATH. What MSDN has to say about the maximum path length of relative paths(*) is not very promising, at least. Also, even if Vista++ allows to create VistaCwd entries with a longer path, this would probably break starting native child processes due to the MAX_PATH restriction for the CWD in calls to CreateProcess. There's one other issue: the new directory will limit deletion very briefly, until replaced. I don't know if that will bother people as much as the current situation. True. Implementing a full replacement for SetCurrentDirectory as in your PoC is still an option. However, I can't do that anymore since I'm tainted by reading your code. If you would contemplate to sign a copyright assignment(**), we could create a more thorough solution with code scanning and all that in the long run. In the meantime, I could apply my patch and we can try how well it works, hacked as it is. Corinna (*) http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx Sorry, I forgot the URL: (**) http://cygwin.com/contrib.html, the Before you get started section. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Deletion race in NtSetFileInformation ? (Directory not empty error in rm -r -f)
Corinna Vinschen wrote: ...or having a cwd below the directory. Trying to remove a directory which is the CWD of some process is the most common reason that the directory is blocked, because the Win32 CWD is opened without the FILE_SHARE_DELETE flag. Especially something like `rm -rf ../foo' is suspicious, if foo is the CWD of the current shell. Hmm ... the other thing that I just remembered is that I first noticed this problem on 1.7.5-1 on Win7, and the thing that made me suspicious was that replacing the offending command with: strace rm -f -r ... made the command suddenly work! But ... sleep 1 ; rm -f -r ... failed in the same way :-( I haven't tried reproducing this particular behaviour on 1.7.7 (yet). Earl -- 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: Reinstalled gcc, make, automake: now BASH stackdumps LR
SJ Wright wrote: Might there be something else a little off? The text from the latest stackdump: Stack trace: Frame Function Args The rest is blank. Should I be concerned, or is this something that will work itself out? Steve W. A little more information that seems pertinent to this issue. These stackdumps are created whenever a shell is called on (as with the batch scripts that start up my RXVT) or when a subshell (#!/bin/bash) or a command (command sequence?) from same is invoked in a script. I've not seen them happen under any other circumstances since the reinstalls mentioned in the Subject line of my original post. This is annoying, as I have quite a few scripts I use both in Cygwin and in Ubuntu GNOME, and anyone can guess the hassle of having to adapt for one versus the other (taking out the crunch-bang line, specifically, or remembering to add it back). Running various options in cygcheck has so far given me the strong impression there's nothing wrong. Should I run 'rebaseall' to see if I'm missing anything that vaguely or remotely supports bash.exe? SJ Wright -- 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
About mingw64-x86_64 packages
For the sake of completeness, I would ask if with these packages one can build applications which run on Win Xp 32. Thanks, Angelo. -- 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: About mingw64-x86_64 packages
No. They are not multilib capable, so they only target a single system - Win64. I am assuming that Jon will be providing toolchains that target Win32 shortly. These will be separate packages. On Tue, Sep 14, 2010 at 5:21 PM, Angelo Graziosi angelo.grazi...@alice.it wrote: For the sake of completeness, I would ask if with these packages one can build applications which run on Win Xp 32. Thanks, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 09:11, Corinna Vinschen wrote: I applied the below patch to Cygwin CVS and it appears to work nicely. The only potential race I can think of is, if another thread of the same Cygwin process calls SetCurrentDirectory. I'm inclined to let this situation slip through the cracks since SetCurrentDirectory will already mess up a mixed-mode Cygwin process. The wincap.has_transactions () is just for testing. If we can use that code, I would replace is with something like wincap.has_messed_up_cwd_handling() or so. ... I would argue against introducing a race with threads that call SetCurrentDirectory(), for at least the following reasons: 1. The race can be avoided without too much grief. While NTDLL.DLL may change, a code scanner could detect that and fall back cleanly to the unlocked behavior. If cygcheck and/or a unit test were to run the scanner directly and report failure, then there would be no need for cygwin1.dll itself to warn on code scan failure--silence there could avoid clutter on this mailing list on some future patch day. 2. If a program does violate the rule against calling SetCurrentDirectory() directly (possibly because of some third party DLL being involved), then it could be very difficult to detect the source of the resulting problems. Relative path conversions could show a discrepancy, but if all path conversions are absolute, then the only symptoms would be rare, bizarre failures of apparently-unrelated operations involving file handles, and overwriting of memory reallocated to other tasks. I would like to spare others the kind of sleuthing I've had to do. 3. The unknown. In software in general and on Windows in particular, I prefer to program defensively. It's difficult enough to get multithreaded programming right when following the usual guidelines; venturing beyond them is asking for trouble. If there is some threading subtlety in there that we haven't spotted, it could become a huge headache to diagnose when it eventually shows up. For example, maybe some Win32 API call copies the current directory handle from a VistaCwd instance, or even from the PEB under the protection of a lock, and expects it to remain open during its work. How would we rule out such a scenario? Anyway, one other detail: Are races within a pure-Cygwin program are prevented by cwd_lock? I don't see it being locked yet, just initialized. Perhaps the cwdstuff::set patch is not yet written? -- John -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 14 12:02, Corinna Vinschen wrote: True. Implementing a full replacement for SetCurrentDirectory as in your PoC is still an option. However, I can't do that anymore since I'm tainted by reading your code. If you would contemplate to sign a copyright assignment(**), we could create a more thorough solution with code scanning and all that in the long run. In the meantime, I could apply my patch and we can try how well it works, hacked as it is. Sorry, I had not realized that I would cause a problem by supplying proof of concept code. I'll inquire... -- John -- 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: ssh from linux to cygwin + CUI + Ctrl-C
On Tue, Sep 14, 2010 at 7:58 PM, Chan Kar Heng chankarh...@gmail.com wrote: Hi there. I've had the same problem in the past. Posted a temporary solution here: http://www.cygwin.com/ml/cygwin/2009-02/msg00403.html This is an interesting hack, but unfortunately it won't work for native apps, only for cygwin-linked. Regards, Ilia. -- 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
Pine?
Just setting up a new XP pro box, can't find Pine. So what MUA is supported atm? Thanks, Wes -- 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: ssh from linux to cygwin + CUI + Ctrl-C
On 09/14/2010 08:39 AM, Ilia K. wrote: Hi, All. I've searched quite a lot for the subj and found no solution yet. I've installed the last cygwin+openssh on Windows XP. I want to connect from linux and run some native console applications (non-cygwin CUI, particularly, cdb and cmd) and I need these applications to correctly handle Ctrt-C. If such CUI application is started from local cygwin bash window it handles Ctrl-C properly, but if it's started over ssh Ctrl-C terminates application and the control returns to bash (the one which runs on the server, ssh session doesn't terminate). Control-C works from me ssh'ing from Linux - Cygwin. Of course my Cygwin is running on Windows 7 (Actually a vm of Windows 7) but IIRC Control-C also works at work when I ssh from Linux - Cygwin on XP. Earth:uname -a Linux earth 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64 GNU/Linux Earth:ssh pluto Last login: Tue Sep 14 19:40:43 2010 from earth Pluto:uname -a CYGWIN_NT-6.1-WOW64 Pluto 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin Pluto:^C Pluto:stty -a speed 38400 baud; rows 24; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^H; kill = ^X; eof = ^D; eol = undef; eol2 = undef; swtch = ^Z; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe -echok -echonl -noflsh tostop echoctl echoke Pluto: -- Andrew DeFaria http://defaria.com Why can't women put on mascara with their mouth closed? -- 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: Reinstalled gcc, make, automake: now BASH stackdumps LR
On 14/09/2010 19:47, SJ Wright wrote: Might there be something else a little off? The text from the latest stackdump: Stack trace: Frame Function Args The rest is blank. Should I be concerned, or is this something that will work itself out? This is a bit of a guess, but try deleting the release\gcc4\libgcc1 directory from your local package cache and then reinstalling libgcc1 (using setup.exe). If that doesn't help, we'll need your cygcheck output: run cygcheck -s -v -r cygcheck.out and then send the cygcheck.out file to the list with your next post (*specifically as an attachment, please don't paste the contents into the body of your email*). cheers, DaveK -- 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
tinyfugue with python won't compile under cygwin
About a year ago I was able to get assistance compiling my MUD client Tinyfuge, with a special add-on python library, using cywgin. That problem turned out needing to send the location of the python library in the ./configure command. Now that we have a new major release of cygwin with a new(er) version of python, I'm having trouble building it again. I am sending the location of the python developer source files, and I've also made sure to download all the python source (just in case) Here is the error message I get: $ make make[1]: Entering directory `/home/jmorse/tf-50b8-py/src' gcc -g -O2 -DTFPYTHON -I/usr/include/python2.6 -DDATADIR=/home/jmorse/share - c -o attr.o attr.c gcc -g -O2 -DTFPYTHON -I/usr/include/python2.6 -DDATADIR=/home/jmorse/share - c -o command.o command.c In file included from /usr/include/python2.6/Python.h:8, from tfpython.h:6, from command.c:33: /usr/include/python2.6/pyconfig.h:323:1: warning: HAVE_INET_PTON redefined In file included from command.c:15: tfconfig.h:57:1: warning: this is the location of the previous definition In file included from /usr/include/python2.6/unicodeobject.h:120, from /usr/include/python2.6/Python.h:85, from tfpython.h:6, from command.c:33: /usr/include/wchar.h:157: error: conflicting types for `tf_wprintf' tfio.h:160: error: previous declaration of `tf_wprintf' was here In file included from tfpython.h:7, from command.c:33: tfconfig.h:57:1: warning: HAVE_INET_PTON redefined In file included from /usr/include/python2.6/Python.h:8, from tfpython.h:6, from command.c:33: /usr/include/python2.6/pyconfig.h:323:1: warning: this is the location of the previous definition make[1]: *** [command.o] Error 1 make[1]: Leaving directory `/home/jmorse/tf-50b8-py/src' make: *** [files] Error 2 -- 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
tcsh filename substitution bug
% cygcheck -c cygwin tcsh Cygwin Package Information Package Version Status cygwin 1.7.5-1 OK tcsh 6.17.00.1-1 OK I've noticed that certain file matching patterns in tcsh under Cygwin are matching more files than they should. In the cases I've noticed, a pattern like *__* or *xx* matches files containing only a single trailing '_' or 'x' character, respectively. I do not see this problem with tcsh 6.17.00 under Ubuntu 9.04, nor do I see it with tcsh 6.17.00 compiled from source under Cygwin on the same system where I see the problem with the Cygwin-provided tcsh. setup.exe says I have the latest tcsh. Here's a script that demonstrates the problem: == CUT HERE == #!/bin/tcsh -f set nonomatch set tmpdir = /tmp/$$ mkdir $tmpdir || exit 1 cd $tmpdir || exit 1 set ok touch xyz zyx echo Directory contents: * set match = ( *x* ) ; set expected = ( xyz zyx ) if ($match == $expected) then echo *x* matched ( $match ), ok else echo *x*, matched ( $match ), expected ( $expected ) unset ok endif set match = ( *xx* ) ; set expected = ( *xx* ) if ($match == $expected) then echo *xx* matched ( $match ), ok else echo *xx*, matched ( $match ), expected ( $expected ) unset ok endif set match = ( *xxx* ) ; set expected = ( *xxx* ) if ($match == $expected) then echo *xxx* matched ( $match ), ok else echo *xxx*, matched ( $match ), expected ( $expected ) unset ok endif echo '' touch abcx echo Directory contents: * set match = ( *x* ) ; set expected = ( abcx xyz zyx ) if ($match == $expected) then echo *x* matched ( $match ), ok else echo *x*, matched ( $match ), expected ( $expected ) unset ok endif set match = ( *xx* ) ; set expected = ( *xx* ) if ($match == $expected) then echo *xx* matched ( $match ), ok else echo *xx*, matched ( $match ), expected ( $expected ) unset ok endif set match = ( *xxx* ) ; set expected = ( *xxx* ) if ($match == $expected) then echo *xxx* matched ( $match ), ok else echo *xxx*, matched ( $match ), expected ( $expected ) unset ok endif cd rm -rf $tmpdir echo '' if ($?ok) then echo Passed exit 0 else echo Failed exit 1 endif == AND HERE == Here's the output I get with the Cygwin-provided tcsh: == CUT HERE == Directory contents: xyz zyx *x* matched ( xyz zyx ), ok *xx*, matched ( zyx ), expected ( *xx* ) *xxx* matched ( *xxx* ), ok Directory contents: abcx xyz zyx *x* matched ( abcx xyz zyx ), ok *xx*, matched ( abcx zyx ), expected ( *xx* ) *xxx*, matched ( zyx ), expected ( *xxx* ) Failed == AND HERE == And here's the output I get with tcsh compiled from source on the same system: == CUT HERE == Directory contents: xyz zyx *x* matched ( xyz zyx ), ok *xx* matched ( *xx* ), ok *xxx* matched ( *xxx* ), ok Directory contents: abcx xyz zyx *x* matched ( abcx xyz zyx ), ok *xx* matched ( *xx* ), ok *xxx* matched ( *xxx* ), ok Passed == AND HERE == -- Keith Thompson (The_Other_Keith) k...@mib.org http://www.ghoti.net/~kst Nokia We must do something. This is something. Therefore, we must do this. -- Antony Jay and Jonathan Lynn, Yes Minister -- 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
Updated: qhull-2010.1.-2
New versions 2010.1-2 of libqhull-devel, libqhull_6, qhull have been uploaded for cygwin. libqhull_5 version revert to previous 2009.1.1-1 CHANGES The previous 2010.1-1 was faulty as a soversion bump was needed for libqhull. As all the linux distributions as still on 2009 or 2003 version the bump was unnoticed. (And not reported on the upstream Changes.txt :-( ) Moreover the /usr/bin/cygqhull-5.dll was incorrectly built as /usr/bin/cygqhull.dll causing octave to fail when libqhull was called. http://cygwin.com/ml/cygwin/2010-09/msg00152.html Qhull 2010.1-2 built using Yaakov cmake-2.8.1-11 For the full changes http://www.qhull.org/src/Changes.txt DESCRIPTION Qhull is a general dimension convex hull program and library It computes volumes, surface areas, and approximations to the convex hull. HOMEPAGE http://www.qhull.org/ Regards Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: maradns-1.4.04-1
Version 1.4.04-1 of 'maradns' has been uploaded to the Cygwin archive, superceding 1.4.03-2, which remains available as the previous version. MaraDNS is a package that implements the Domain Name Service (DNS), an essential internet service. For full details, see the project website: http://www.maradns.org/ According to the changelog on the project website, the changes to the MaraDNS software package since the previous release are as follows: - Bugfix: NAPTR records now work when ~ is used to separate records - NAPTR records now documented - Bugfix: ANY queries now correctly work with NS referrals - Example IPv6 addresses now use RFC-4193 compliant IPs -SM -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
