[ITP] iperf 2.0.4
Category: Utils Requires: cygwin sesc: Measures maximum TCP and UDP bandwidth ldesc: was developed by NLANR/DAST as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter and datagram loss URL: sourceforge.net/projects/iperf Best Regards Cliff George Paradise Datacom
Re: [ITP] iperf 2.0.4
On Feb 25 04:40, Clifford George wrote: Category: Utils Requires: cygwin sesc: Measures maximum TCP and UDP bandwidth ldesc: was developed by NLANR/DAST as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter and datagram loss URL: sourceforge.net/projects/iperf Erm... thanks for contributing but... can you please follow the submission guidelines? See http://cygwin.com/setup.html Specificially: - Direct URLs to the Cygwin specific binary and source packages, following the Cygwin package naming convention. - If you don't want to rely on needing 5 votes for this package, please tell us a stable Linux distro in which this package is packed as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GCC4 status.
On Feb 24 18:22, Dave Korn wrote: Corinna Vinschen wrote: I don't think that's necessary. I just dread a situation where you suddenly don't have w32api in the default include and lib search paths. I don't have problems with mingw. Just w32api is essential IMO. If I missed this in the discussion up to this point, feel free to ignore me. Otherwise, just make sure that w32api is searched by default. Back-compat is a given, don't worry! Thanks, Dave. While we're talking gcc-4, may I ask about two really annoying messages I'd rather not like to see in future unless I switch them on with a special --i-wanna-see-every-single-detail-whatever-the-cost option? #1) sftp.c:368: warning: 'opterr' redeclared without dllimport attribute: previous dllimport ignored Yes, well, so what? #2) /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. *Sob* Yes, officer, I confess everything! But *please* don't tell me this every time I dare to link an application. Is there any chance to get rid of this really useless stuff upstream? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] iperf 2.0.4
On Feb 25 05:56, Clifford George wrote: Sorry, thought I had followed the rules in 'submitting a new package', point 2, my apologies. As far as I am aware this is not in any Linux Distro. It's in Fedora, afaics. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GCC4 status.
Corinna Vinschen wrote: #1) sftp.c:368: warning: 'opterr' redeclared without dllimport attribute: previous dllimport ignored Yes, well, so what? This one IIRC has some significance. If you declare any extern symbols at all with dllimport attributes, it disables auto-import altogether. So a stray definition like that can break linking all the other functions that would normally be auto-imported. #2) /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. *Sob* Yes, officer, I confess everything! But *please* don't tell me this every time I dare to link an application. Is there any chance to get rid of this really useless stuff upstream? I don't know. We could turn on auto import globally but that will pessimize a whole bunch of stuff that needn't be affected. We could discard the warning altogether but then people would get silent failures. What would be best of all would be to only issue the warning if a const data structure reference of the kind mentioned actually occurs. I haven't looked to see if that's possible to detect yet, but it would be a nice fix for upstream ld. As a workaround, the sources could always be fixed. Inconsistent declarations *is* a correctness issue, after all, and it's usually trivial to add an item to LDFLAGS. Also, perhaps as a half-way compromise measure, auto import could be enabled in the GCC specs for just C++/ObjC++/Java. I don't know what's for the best yet, does anyone else have any suggestions? cheers, DaveK
Re: GCC4 status.
On Feb 25 17:30, Dave Korn wrote: Corinna Vinschen wrote: #1) sftp.c:368: warning: 'opterr' redeclared without dllimport attribute: previous dllimport ignored Yes, well, so what? This one IIRC has some significance. If you declare any extern symbols at all with dllimport attributes, it disables auto-import altogether. So a stray definition like that can break linking all the other functions that would normally be auto-imported. So why does it do that at all: previous dllimport ignored? It shouldn't do that. The dllimport should have precedence, IMHO. #2) /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. *Sob* Yes, officer, I confess everything! But *please* don't tell me this every time I dare to link an application. Is there any chance to get rid of this really useless stuff upstream? I don't know. We could turn on auto import globally but that will pessimize a whole bunch of stuff that needn't be affected. We could discard the warning altogether but then people would get silent failures. I think auto import should be the default. You don't have this problem and the message on any other platform. Why isn't the default setting so that we get what other platforms get, too? I never had the case so far where auto import would have hurt. Am I just maintaining too simple projects? As a workaround, the sources could always be fixed. Inconsistent declarations *is* a correctness issue, after all, and it's usually trivial to add an item to LDFLAGS. There's only so much platform uglification put up with in the upstream OpenSSH sources... Also, perhaps as a half-way compromise measure, auto import could be enabled in the GCC specs for just C++/ObjC++/Java. I don't know what's for the best yet, does anyone else have any suggestions? ...which are written in plain C, btw. So this compromise is none for a lot of packages in the Cygwin distro, not only for OpenSSH. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] iperf 2.0.4
Corinna Vinschen wrote: On Feb 25 05:56, Clifford George wrote: Sorry, thought I had followed the rules in 'submitting a new package', point 2, my apologies. As far as I am aware this is not in any Linux Distro. It's in Fedora, afaics. Corinna I vote yes.
Re: [ITP] iperf 2.0.4
On Feb 25 12:39, Lee D.Rothstein wrote: Corinna Vinschen wrote: On Feb 25 05:56, Clifford George wrote: As far as I am aware this is not in any Linux Distro. It's in Fedora, afaics. I vote yes. It's in Fedora so there's no need to vote. But it would help if you could review the package for correct packaging. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] iperf 2.0.4
Clifford George writes: Sorry, thought I had followed the rules in 'submitting a new package', point 2, my apologies. As far as I am aware this is not in any Linux Distro. No FTP site, but the packages I made are attached. I would like iperf in cygwin, if there is no support for that then so be it. Packaging looks good, but your source package has no hint how you created the binary package, see o http://cygwin.com/setup.html#package_contents Regards Cliff George Ciao Volker
Re: GCC4 status.
Corinna Vinschen wrote: /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. *Sob* Yes, officer, I confess everything! But *please* don't tell me this every time I dare to link an application. Is there any chance to get rid of this really useless stuff upstream? This is a binutils, not gcc, issue (unless you just want gcc's specs file to automatically pass the option to ld. But then, how does Bruno turn it off, as he does, for gettext and libintl? ld would see both --enable (from specs) and --disable (from Bruno's cmdline -- but do we guarantee which order specs-derived and cmdline-derived options are delivered to ld?). I think it's better to change cygwin-ld's default behavior than to try to work around the warning in gcc's specs file. Now, ld for pe[i]-386 already (as of 2008/11/24) defaults to --enable-runtime-pseudo-reloc-v1. http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/emultempl/pe.em.diff?r1=1.137r2=1.138cvsroot=srcf=h This doesn't make much sense unless we also default to --enable-auto-import, which is a one-line change to the same file at line 148: -link_info.pei386_auto_import = -1; +link_info.pei386_auto_import = 1; /* default to enabled */ There might be pushback from other pe platforms, but changing the default behavior for cygwin is in cgf's court. -- Chuck
Re: GCC4 status.
Dave Korn wrote: Corinna Vinschen wrote: #2) /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. *Sob* Yes, officer, I confess everything! But *please* don't tell me this every time I dare to link an application. Is there any chance to get rid of this really useless stuff upstream? I don't know. We could turn on auto import globally but that will pessimize a whole bunch of stuff that needn't be affected. We could discard the warning altogether but then people would get silent failures. It's already on by default. The variable link_info.pei386_auto_import is currently initialized to -1, which means Do it, but complain. The only thing changing that initialization to 1 would do, would be to stop complaining. You already have to use explicitly --disable-auto-import to turn it off. What would be best of all would be to only issue the warning if a const data structure reference of the kind mentioned actually occurs. I haven't looked to see if that's possible to detect yet, but it would be a nice fix for upstream ld. Actually, with Kai's recent changes, IF we (1) modified cygwin's src/winsup/cygwin/lib/pseudo-reloc.c file to support -v2 psuedo-relocs (2) EVENTUALLY, after much testing, changed cygwin-ld's default reloc mode from (current: not enabled; CVS ld: v1 enabled) to v2 enabled, THEN we can have const structure references (and complex data type references) that can be updated without error. I think. See: http://cygwin.com/ml/cygwin-developers/2009-01/msg9.html and following thread, as well as embedded links in the referenced message. As a workaround, the sources could always be fixed. Inconsistent declarations *is* a correctness issue, after all, and it's usually trivial to add an item to LDFLAGS. Also, perhaps as a half-way compromise measure, auto import could be enabled in the GCC specs for just C++/ObjC++/Java. I don't know what's for the best yet, does anyone else have any suggestions? See previous message. -- Chuck
Re: GCC4 status.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: This is a binutils, not gcc, issue (unless you just want gcc's specs file to automatically pass the option to ld. But then, how does Bruno turn it off, as he does, for gettext and libintl? Maybe we tell him how things should be done on Cygwin, rather than *him* telling *us* how Cygwin should work. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmmENgACgkQpiWmPGlmQSNyagCgkdfmmWUhz53FIWRZVUrlgC8C 3dgAn0W+T3GYr6SScz3ejWtRYqJXHOvv =RsfB -END PGP SIGNATURE-
Re: GCC4 status.
Yaakov (Cygwin/X) wrote: Charles Wilson wrote: This is a binutils, not gcc, issue (unless you just want gcc's specs file to automatically pass the option to ld. But then, how does Bruno turn it off, as he does, for gettext and libintl? Maybe we tell him how things should be done on Cygwin, rather than *him* telling *us* how Cygwin should work. I just picked gettext/libintl as a known example of existing projects where --disable-auto-import is the desired (by *somebody*, doesn't matter who or why) behavior. There could be other end-users who, for whatever reason, want to avoid auto-import. Putting --enable-auto-import into the specs file makes that...tricky. -- Chuck
Re: GCC4 status.
Charles Wilson wrote: Yaakov (Cygwin/X) wrote: Charles Wilson wrote: But then, how does Bruno turn it off, as he does, for gettext and libintl? Maybe we tell him how things should be done on Cygwin, rather than *him* telling *us* how Cygwin should work. There could be other end-users who, for whatever reason, want to avoid auto-import. Putting --enable-auto-import into the specs file makes that...tricky. Yeh, I think I agree that we shouldn't block it altogether. I'm fully in favour of changing the default in upstream ld. cheers, DaveK
Re: GCC4 status.
Corinna Vinschen wrote: So why does it do that at all: previous dllimport ignored? It shouldn't do that. The dllimport should have precedence, IMHO. I don't know why it does that, it's just the behaviour of vanilla upstream GCC. I think it might be important, and have a vague memory of some PR relating to this in the bugzilla. I'll take a closer look. cheers, DaveK
[Thread reset] GCC4 vs binutils
[ Time to start a fresh thread, since something's come up. ] In the thread at http://cygwin.com/ml/cygwin/2009-02/threads.html#00448 Chuck reported a problem with cygmagic-1.dll causing a segfault when rebased. To cut to the end of the thread, this turns out to be owing to a bug that was fixed upstream in ld, unfortunately just a few weeks after the current binutils was released: http://sourceware.org/ml/binutils/2008-07/msg00372.html This problem affects potentially all maintainers and end-users who compile DLLs using -static-libgcc. Otherwise, it would have been the case that only users who wanted to build the compiler themselves from sources would need to worry about having a more recent binutils, but this problem can bite anybody, so I guess we need to get a newer binutils out there. And, as long as we're making plans for silencing that ld warning, we should try and get that change in there first. CGF, how are you fixed for time right now? Will you be able to do a release sometime in the next week say? But not so quickly that we don't have time to get a quick patch in upstream to shut up the auto-import warning? On a side issue, are you going to want to handle the MinGW cross-binutils we'll be needing for the cross-compiler further on down the line? cheers, DaveK
RE: GCC4 status.
Dave Korn wrote: Corinna Vinschen wrote: So why does it do that at all: previous dllimport ignored? It shouldn't do that. The dllimport should have precedence, IMHO. I don't know why it does that, it's just the behaviour of vanilla upstream GCC. I think it might be important, and have a vague memory of some PR relating to this in the bugzilla. I'll take a closer look. It does that because native MS compiler does that as do/did other Windows compilers (I think MSVC actually says dllexport assumed). The behaviour is due to a patch committed in gcc 3.0 development but was also in the sources used by cygwin and mingw in 2.95.3 days. There are several testsuite cases that expect this behaviour. In olden (pre -funit-at-a-time) days it was critical because without the override semantics we would sometimes get a function being used as a dllimport than later in the same TU it would find a definition and the RTL generation would blow up. Danny
RE: GCC4 status.
Charles Wilson Dave Korn wrote: Corinna Vinschen wrote: #2) It's already on by default. The variable link_info.pei386_auto_import is currently initialized to -1, which means Do it, but complain. The only thing changing that initialization to 1 would do, would be to stop complaining. It also merges *all* .rdata variables into .data section. That's the pessimization. Danny
Re: [Thread reset] GCC4 vs binutils
.Dave Korn wrote: And, as long as we're making plans for silencing that ld warning, we should try and get that change in there first. Background: The current behavior wrt auto-import (enabled by default, but complain -- info, not warn -- if used without explicit --enable-auto-import) happened here: http://sourceware.org/ml/binutils/2002-05/msg00703.html and extends to ALL pe platforms. Prior to that, auto-import was disabled by default, and if enabled, issued a warning if used. This dates back to when auto-import was first added to ld: http://sourceware.org/ml/binutils/2001-08/msg00040.html So, in short: auto-import has been available for 7.5 years, and has been the default (but whines with info message) on all pe platforms for just under 7 years. I don't think anyone will complain about no longer whining. It's an established tool in the gcc/ld-on-pe toolbox. Dave, do you want to propose the patch on binutils, or shall I? -- Chuck
Re: GCC4 status.
Danny Smith wrote:
Charles Wilson
It's already on by default. The variable
link_info.pei386_auto_import
is currently initialized to -1, which means Do it, but complain.
The only thing changing that initialization to 1 would do,
would be to
stop complaining.
It also merges *all* .rdata variables into .data section. That's the
pessimization.
But
(a) implicitly enabled auto-import (-1) *doesn't* merge .rdata into
.data? That seems...unwise. I thought that the only way to keep .rdata
separate and non-writable was to --disable-auto-import.
(b) However, I also thought with Kai's runtime-pseudo-reloc-v2 changes,
at least, it is no longer necessary for fixuped references to be in a
writable page, so they can stay in .rdata? True/False? ('Course, even
if true, this requires --enable-runtime-psuedo-relocs-v2 because only
-v1 is now the default for 32bit pe. And cygwin's runtime .o's don't yet
support -v2).
--
Chuck
Re: GCC4 status.
Charles Wilson wrote: Danny Smith wrote: Charles Wilson It's already on by default. The variable link_info.pei386_auto_import is currently initialized to -1, which means Do it, but complain. The only thing changing that initialization to 1 would do, would be to stop complaining. It also merges *all* .rdata variables into .data section. That's the pessimization. I think we might have to live with it as a temporary measure, until we can get the whole thing done with Kai's new relocs and even start to think about disabling auto-import by default. But (a) implicitly enabled auto-import (-1) *doesn't* merge .rdata into .data? That seems...unwise. I thought that the only way to keep .rdata separate and non-writable was to --disable-auto-import. Nope, hence the warning. Implicitly-enabled auto-import behaves as if auto-import was disabled until it finds something that needs auto-importing, then switches mode - but it's too late to reassign the sections, because the linker script has already been selected by then. cheers, DaveK
Re: [Thread reset] GCC4 vs binutils
Charles Wilson wrote: .Dave Korn wrote: And, as long as we're making plans for silencing that ld warning, we should try and get that change in there first. Background: The current behavior wrt auto-import (enabled by default, but complain -- info, not warn -- if used without explicit --enable-auto-import) happened here: http://sourceware.org/ml/binutils/2002-05/msg00703.html and extends to ALL pe platforms. See also http://sourceware.org/bugzilla/show_bug.cgi?id=4844. Dave, do you want to propose the patch on binutils, or shall I? I've already started testing one :) cheers, DaveK
RE: Reproducing the cygwin X problems
I have two dual-core systems and they both have clipboard problems. -Chris -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Jon TURNEY Sent: Tuesday, February 24, 2009 2:14 PM To: cygwin-xfree@cygwin.com Cc: dan.tsaf...@gmail.com; mike_ay...@tvworks.com Subject: Re: Reproducing the cygwin X problems Dan Tsafrir wrote: On Fri, Feb 20, 2009 at 1:05 PM, Mike Ayers wrote: I can neither confirm nor deny this, as I don't have ClipBook available. Did you try to run 'clipbrd' through start-run ? I just kill Xwin.exe forcibly in task manager - it takes all X apps with it. Right. However, the better trick I discovered recently is to click on VNC's taskbar icon and close it. Once it closes, the X applications recover and can cut-n-pste with Windows apps. Also, because VNC is VNC, no setup is lost there either - I can reconnect and my console is unharmed. This too works for me (but as you say, only if I kill the vncviewer through the context menu that pops up when right clicking its taskbar icon; strangely, killing it through the top right x doesn't produce a similar effect). Thanks! I suspect the problem here may be contention between the two applications that want to share the clipboard. Our other report implicated Office clipboard, which may be doing the same thing..? Dan Mike, Thanks very much for this information on the clipboard problems. I've been able to reproduce something similar to the problems you describe, so I will spend some time trying to fix it. It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? -- 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/ -- 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: update - Vista: no copy/paste X - MS
On Tue, 24 Feb 2009, Marc Girod wrote: Dick Repasky-2 wrote: not being able to copy from an X application (xterm or nedit) and paste into Windows Notepad. For what it's worth, and notwithstanding the need for deeper analysis and a fix, I can report that, disabling the Office clipboard (e.g. from Outlook), copypaste work for me from emacs run on X to the Windows Notepad, on Vista. Marc On my system toggling the Office clipboard toggles the ability to copy from X and paste into Windows Notepad when Notepad is launced before X. If I launch X and then Windows Notepad I cannot copy from X and paste into Notepad independently of whether Office clipboard is on or off. If I launch Windows Notepad before launching X, I can copy from X and paste into Notepad when Office clipboard is off. I cannot copy and paste when Office clipboard is on. I'm running Office 2007, I have been using Excel to toggle the Windows clipboard. Dick Dick Repasky Center for Computational Cytomics UITS Cubicle 101.08 Indiana University USA rrepa...@indiana.edu -- 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: update - Vista: no copy/paste X - MS
Dick wrote: On my system toggling the Office clipboard toggles the ability to copy from X and paste into Windows Notepad when Notepad is launched before X. ... I'm running Office 2007, I have been using Excel to toggle the Windows clipboard. I have not noticed any difference related to the order of launching. Usually, I launch X first. Not always though: I may have to start Outlook or IE first... But I am using older versions of the Office tools than you. My Outlook says: 11.8206.8202 SP3, Copyright 1995-2003... Marc -- View this message in context: http://www.nabble.com/update---Vista%3A-no-copy-paste-X--%3E-MS-tp22164522p22205981.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- 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: Reproducing the cygwin X problems
From: Dan Tsafrir [mailto:dan.tsaf...@gmail.com] Sent: Tuesday, February 24, 2009 11:03 PM However, in an attempt to test your hypothesis, I've set the affinity of XWin.exe, emacs, and the vncviewer to only use CPU0 (through the task manager). I don't think this is a valid test. What is wanted is a P4 single-core hyperthreader with BIOS hyperthread enable (or a multi processor and a screwdriver). Anyone have a single/nulti switchable handy? I'll check my BIOS next reboot. Mike -- 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: Reproducing the cygwin X clipboard problems
Jon TURNEY wrote: Thanks very much for this information on the clipboard problems. I've been able to reproduce something similar to the problems you describe, so I will spend some time trying to fix it. I've looked into this a bit and it seems to me that the patch in [1] can interact badly with other clipboard viewer applications (like clipbrd.exe, VNC viewer, and probably other clipboard helper applications and maybe VMs as well) On my PC, just running the tightvnc viewer and X server and copying something into the X clipboard sends the CPU load to 100% as we seem to be constantly converting the selection onto the windows clipboard and then clearing it. I've built a version of 1.5.3-7, with this patch reverted and lots more clipboard debugging added. You can download it from [2] It would be most helpful if you could try this and see if the clipboard problems you are seeing are changed at all. If the problems still persist, could you please run the X server with the extra parameter '-logverbose 3' and post a relevant section from the log output along with a description of the behaviour. (Note that running with this level of logging will make your log file get very big quite quickly and probably slow down the X server) [1] http://bugs.freedesktop.org/show_bug.cgi?id=5735 [2] ftp://cygwin.com/pub/cygwinx/XWin.20090225214130.exe.bz2 -- 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: Reproducing the cygwin X problems; MinTTY, too
Lee D.Rothstein wrote: FWIW, I'm having a similar proble with MinTTY. If I select text in a MinTTY window, then copy text withing a GUI app, like TextPad (http://textpad.com), clipboard stops working for all apps. If I ten return to the original, MinTTY window, and reselect text, paste it, that works and then copy and paste work in all apps, again. MinTTY problems are probably better directed to the cyg...@cygwin.com list or at http://code.google.com/p/mintty/ -- 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: Reproducing the cygwin X problems
Mike Ayers wrote: From: Dan Tsafrir Sent: Tuesday, February 24, 2009 11:03 PM However, in an attempt to test your hypothesis, I've set the affinity of XWin.exe, emacs, and the vncviewer to only use CPU0 (through the task manager). I don't think this is a valid test. What is wanted is a P4 single-core hyperthreader with BIOS hyperthread enable (or a multi processor and a screwdriver). Anyone have a single/nulti switchable handy? I'll check my BIOS next reboot. I think a boot.ini entry with /onecpu is the way to do this. But I'm not saying that these problems don't exist on single-core machines (they do, as I am able to reproduce something like the behaviour mentioned), I'm just saying the behaviour may be different (as I don't see exactly the behaviour described), and I do not have the resources to test on a multiple-core machine. -- 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: -query not working on cygwin/windows
Phil, Thanks for hanging in there and trying your best to help identify my problem. If I ever find the solution I will shout it from the mountain top! I'd like to try cygwin-x on another Windows PC with less software installed but my company's network is configured to block unknown MAC addresses. So I can't use just any PC on my network. Furthermore I won't be getting any help from my IT department. They're not sympathetic to anything Linux related. Ironically, I work at a major university in the engineering department. They see Linux as disruptive technology. We have Phd's who have written dissertations on TCP/IP related stuff. I told one of them about my problem. He wasn't interested. As far as identifying BLODA software, that's way over my head. I'm already well beyond my knowledge of Windows software and how Windows works in general. Furthermore I already know everything I care to know about Windows. I guess my next step is to retreat to VNC and see if that works. I just hate giving up on xdmcp when it has worked well for me before. I guess I haven't used it since cygwin-x went from xfree to Xorg. But I don't think cygwin-x is the problem since Xming and X-Win32 don't work either. I think you're correct, something is blocking the communications. BTW, why did you suggest I telnet to port 6000? Isn't port 177 the one that xdmcp uses to initiate sessions? I noticed in my PC's task bar that I have anti-virus software from Trend Micro installed. I called their support number. To their credit the support engineer helped me shut down their software completely. He stayed on the line to talk me through the process. Unfortunately cygwin-x still didn't work. The engineer assured me that the test confirmed that Trend Micro software is not the problem. I hope he's right. There's just too may variables here. Phil Betts-2 wrote: km4hr wrote: Phil Betts-2 wrote: km4hr wrote: Perhaps you missed my suggestions here: http://cygwin.com/ml/cygwin-xfree/2009-02/msg00222.html Try the telnet check first to see if the port is accessible from Windows because that only takes a few seconds. (Make sure you run the cygwin telnet.exe) Phil, Thanks for hanging in there. I tried your telnet suggestion. I get the following: $telnet xxx.xxx.xxx.xxx 6000 trying xxx.xxx.xxx.xxx... Connected to xxx.xxx.xxx.xxx. Escape character is '^]'. The above is all I get. A login prompt never appears. I waited for several minutes. When I press Ctrl-c I get: Connection closed by foreign host. If I telnet using an unopen port I the response gets past the trying statement. Your quoting went a bit wrong there. Sorry, I should have explained that that was the expected outcome. If you get the Connected to message, the port is open and you can close the connection. The proper way to terminated a telnet session from that situation is to press Ctrl-] (the Escape character mentioned in the message). You then get a telnet prompt, where you just type quit. You wouldn't normally expect a prompt (unless the port was 23 - telnet's own). In theory, if you knew enough about the protocol expected on the opened port, you could simulate a normal connection and debug the connection using telnet, but you have to have a certain masochistic streak to try it! So, now we know that the port is accessible from Windows. In that case, it *should* work, so something else is interfering. Have you investigated the BLODA angle? Prime suspects are anti-virus and other security software, but hardware drivers have caused problems too. These programs inject themselves into every running process at a fairly low level and, whilst they are mostly benign, can cause nasty, spurious problems, particularly when the code you are trying to run is slightly off the beaten track. X and XCMCP probably falls into that category for Windows machines. The usual advice is to uninstall these, rather than just disable them. The faulty components are frequently left in place when disabled. Once you have ruled out a candidate, you can reinstall it. If you do find one that is causing the problem, it may be possible to configure it in a way which avoids the problem (e.g. disabling real-time virus scanning). You can often spot BLODA by running the program which is failing, and then seeing which DLLs are loaded using something like Process Explorer. Any unexpected DLLs, particularly if not under C:\Windows or C:\cygwin are prime suspects. In your case, because the -query option is failing, you won't get chance to see the DLLs before X terminates, so you could just start a normal server (e.g. via startxwin.bat) instead. You may find that an app that is not on the BLODA is causing the problem. If so, a message to the main cygwin list would be appreciated so that the BLODA can be updated. If the BLODA hunt fails, you could try running the server via strace so that the point of failure might be
Re: graphics programming - beginner
Hello, On Wed, Feb 25, 2009 at 1:39 AM, H Le wrote: Hi, The previous message I asked was the path to graphics.h library but it seems to get more confusion. After searching for awhile, it seems that the graphics.h library is obsoleted. I try to compile some simple graphics program but unsure what libraries to #include and what compile parameters are needed. If someone shows me or has a link to someplace where it has some simple program, and step by step to compile it to run under cygwin, I appreciate it. I think this is what you're looking for: http://www.cs.colorado.edu/~main/bgi/install.html It's designed for use with MinGW, however, and not Cygwin. If you don't need Cygwin's Linux API emulation layer for your program I suggest you use MinGW itself, following the instructions on that website. You may be able to compile it from source to work on Cygwin. The source code is here: http://www.cs.colorado.edu/~main/bgi/source/ The makefile will need some changes to work. Regards, Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
On Feb 24 15:42, Greg Freemyer wrote: All, I'm familiar with http://www.cygwin.com/cygwin-ug-net/using-specialnames.html But it only shows the \device\hardisk mappings. Are there also mapppings for the shadow devices. (http://en.wikipedia.org/wiki/Shadow_Copy) ie. \Device\HarddiskVolumeShadowCopy4 or \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4 Sorry, there's no Cygwin device associated with volume shadow copies so far. There are no plans to add them, but if they can be simply mapped to raw disk devices, we can certainly talk about adding a matching device (/dev/svX or something). As usual http://cygwin.com/acronyms/#PTC. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
question about fonts
Hi, each time I launch the bash shell first then /usr/X11R6/bin/startxwin.sh to start the X-term then ssh to the server in my department.. but there're two questions, one is I want to change the fonts but don't know how. and then I couldn't start the windows copy/paste facility in an X-term (the background is while) http://www.nabble.com/file/p22198988/QQ%25E6%2588%25AA%25E5%259B%25BE%25E6%259C%25AA%25E5%2591%25BD%25E5%2590%258D.jpeg -- View this message in context: http://www.nabble.com/question-about-fonts-tp22198988p22198988.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe crashing without its error message
t...@panix.spam wrote: Warning: There are multiple cygwin1.dlls on your path There's yer problem. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: OpenSSH-5.2p1-1
I've just updated the Cygwin 1.7 version of OpenSSH to 5.2p1-1. This is a new major upstream release. It fixes a security related issue and introdues a lot of new features. The Cygwin release is created from the vanilla sources with just a minor installation tweak. The official release message of 5.2p1: OpenSSH 5.2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We have also recently completed another Internet SSH usage scan, the results of which may be found at http://www.openssh.com/usage.html Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html The focus of this release has been on bugfixes as the previous openssh-5.1 release introduced many new features and made some invasive changes. Changes since OpenSSH 5.1 = Security: * This release changes the default cipher order to prefer the AES CTR modes and the revised arcfour256 mode to CBC mode ciphers that are susceptible to CPNI-957037 Plaintext Recovery Attack Against SSH. * This release also adds countermeasures to mitigate CPNI-957037-style attacks against the SSH protocol's use of CBC-mode ciphers. Upon detection of an invalid packet length or Message Authentication Code, ssh/sshd will continue reading up to the maximum supported packet length rather than immediately terminating the connection. This eliminates most of the known differences in behaviour that leaked information about the plaintext of injected data which formed the basis of this attack. We believe that these attacks are rendered infeasible by these changes. New features: * Added a -y option to ssh(1) to force logging to syslog rather than stderr, which is useful when running daemonised (ssh -f) * The sshd_config(5) ForceCommand directive now accepts commandline arguments for the internal-sftp server. * The ssh(1) ~C escape commandline now support runtime creation of dynamic (-D) port forwards. * Support the SOCKS4A protocol in ssh(1) dynamic (-D) forwards. (bz#1482) * Support remote port forwarding with a listen port of '0'. This informs the server that it should dynamically allocate a listen port and report it back to the client. (bz#1003) * sshd(8) now supports setting PermitEmptyPasswords and AllowAgentForwarding in Match blocks Bug and documentation fixes * Repair a ssh(1) crash introduced in openssh-5.1 when the client is sent a zero-length banner (bz#1496) * Due to interoperability problems with certain broken SSH implementations, the e...@openssh.com and no-more-sessi...@openssh.com protocol extensions are now only sent to peers that identify themselves as OpenSSH. * Make ssh(1) send the correct channel number for SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to avoid triggering 'Non-public channel' error messages on sshd(8) in openssh-5.1. * Avoid printing 'Non-public channel' warnings in sshd(8), since the ssh(1) has sent incorrect channel numbers since ~2004 (this reverts a behaviour introduced in openssh-5.1). * Avoid double-free in ssh(1) ~C escape -L handler (bz#1539) * Correct fail-on-error behaviour in sftp(1) batchmode for remote stat operations. (bz#1541) * Disable nonfunctional ssh(1) ~C escape handler in multiplex slave connections. (bz#1543) * Avoid hang in ssh(1) when attempting to connect to a server that has MaxSessions=0 set. * Multiple fixes to sshd(8) configuration test (-T) mode * Several core and portable OpenSSH bugs fixed: 1380, 1412, 1418, 1419, 1421, 1490, 1491, 1492, 1514, 1515, 1518, 1520, 1538, 1540 * Many manual page improvements. Checksums: == - SHA1 (openssh-5.2.tar.gz) = 260074ed466e95f054ac05a4406f613d08575217 - SHA1 (openssh-5.2p1.tar.gz) = 8273a0237db98179fbdc412207ff8eb14ff3d6de Reporting Bugs: === - Please read http://www.openssh.com/report.html Security bugs should be reported directly to open...@openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look
1.5.25: pthread/ofstream problem
Hello,
I've been trying to track down a segmentation fault that a rather large
application I'm working on has been experiencing. I have seemed to narrow it
down to two threads that are opening, appending, and closing files quite often.
I've created a very simple example program that suffers from the same condition.
Two threads are created, each open up their own unique file, followed by a
close (no writing, in this example). The threads are both joined and then the
processes is then repeated. After some indeterminate amount of time - millions
of iterations - the application segfaults with no real useful information that
I can see. Running in gdb doesn't seem to help (after compiling with debug
flags, of course) as the backtrace is either corrupted or can't be followed
because I'm not using a debug version of Cygwin.
Note that this problem seems to be accelerated by having the target directory
open in explorer and/or having the files highlighted. I've come across
situations where even ofstream.open() will throw an exception when doing the
above. The exception has been seen in both C++ and python, which makes me think
it's something fundamental in Cygwin, and possibly related to this as well.
Is there something inherently wrong with having different treads access
different files at once? I have reproduced this issue across multiple machines.
Compile: g++ FileTest.cpp -lpthread -oFileTest
FileTest.cpp:
#include fstream
#include string
#include iostream
#include pthread.h
using namespace std;
struct ThreadData {
string fileName;
};
void *
FileThread(void *arg) {
try {
ofstream outfile;
ThreadData *td = (ThreadData*)arg;
string fileName = td-fileName;
try {
outfile.open(fileName.c_str(), ios_base::app);
} catch(...) {
cerr Exception during open() endl;
return NULL;
}
try {
outfile.close();
} catch(...) {
cerr Exception during open() endl;
return NULL;
}
} catch(...) {
cerr Exception while creating objects endl;
return NULL;
}
return NULL;
}
int
main(void) {
unsigned long long count = 0;
ThreadData td1;
td1.fileName = temp1.txt;
ThreadData td2;
td2.fileName = temp2.txt;
while(1) {
count++;
if(count%5000 == 0) cout Iteration count endl;
pthread_t thread1;
pthread_t thread2;
pthread_create(thread1, NULL, FileThread, td1);
pthread_create(thread2, NULL, FileThread, td2);
void *res = NULL;
pthread_join(thread1, res);
pthread_join(thread2, res);
}
// Not reached
return 0;
}
Stackdump:
Exception: STATUS_ACCESS_VIOLATION at eip=610B5FF2
eax=0D89466C ebx=006A02F0 ecx=61149C88 edx=0D89466C esi=61149C88 edi=006C05C8
ebp=0022CAC8 esp=0022CAB0 program=c:\Documents and
Settings\sfilipek\test\FileTest.exe, pid 4344, thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function Args
0022CAC8 610B5FF2 (006A02F0, , 0022CAE8, 006A02F0)
0022CAE8 610B8B0D (006A0298, , 0022CC98, 006B0508)
0022CC08 610B1E4B (0022CC20, 0022CC94, 0022CCE8, 610935A8)
0022CC18 610779F8 (006A0298, 0022CC94, 00401150, 0022CCA0)
0022CCE8 610935A8 (0001, 6116B798, 006A0090, 0022CC70)
0022CD98 610060D8 (, 0022CDD0, 61005450, 0022CDD0)
61005450 61004416 (009C, A02404C7, E8611021, FF48)
34 [main] FileTest 4344 _cygtls::handle_exceptions: Error while dumping
state (probably corrupted stack)
Nothing was written to stderr in the end... just the segfault.
Any advice, workaround, etc. would be extremely helpful.
Regards,
Stefan Filipek
uname -a: CYGWIN_NT-5.1 [computer name] 1.5.25(0.156/4/2) 2008-06-12 19:34 i686
Cygwin
cygcheck.out
Description: cygcheck.out
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: OpenSSH-5.2p1-1
2009/2/25 Corinna Vinschen: I've just updated the Cygwin 1.7 version of OpenSSH to 5.2p1-1. This is a new major upstream release. It fixes a security related issue and introdues a lot of new features. The Cygwin release is created from the vanilla sources with just a minor installation tweak. Since this is a security fix, will there be a 1.5 update as well? Regards, Frank -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.25: pthread/ofstream problem
Filipek, Stefan R. wrote:
Note that this problem seems to be accelerated by having the target
directory open in explorer and/or having the files highlighted. I've come
across situations where even ofstream.open() will throw an exception when
doing the above. The exception has been seen in both C++ and python, which
makes me think it's something fundamental in Cygwin, and possibly related
to this as well.
Actually, that makes me think you have BLODA-style interference.
Potential app conflicts:
ZoneAlarm Personal Firewall
Detected: HKLM Registry Key, Named file.
Which version is this? Is it the full version with antispyware and all
sorts of extra tricks built in? What anti-virus do you have?
The stack trace you posted suggests BLODA too:
[ minor munging of paths to simplify
~ $ addr2line --exe /bin/cygwin1.dbg
610B5FF2
/usr/src/cygwin-1.5.25-15/winsup/cygwin/thread.cc:1593
610B8B0D
/usr/src/cygwin-1.5.25-15/winsup/cygwin/thread.h:147
610B1E4B
/usr/src/cygwin-1.5.25-15/winsup/cygwin/thread.h:301
610779F8
/usr/src/cygwin-1.5.25-15/winsup/cygwin/pthread.cc:71
610935A8
??:0
610060D8
/usr/src/cygwin-1.5.25-15/winsup/cygwin/dcrt0.cc:956
61004416
/usr/src/cygwin-1.5.25-15/winsup/cygwin/cygtls.cc:73
Looking at the top of the stack there:
1590 pthread_mutex::~pthread_mutex ()
1591 {
1592if (win32_obj_id)
1593 CloseHandle (win32_obj_id);
1594
1595mutexes.remove (this);
1596 }
suggests that a plain call to win32.CloseHandle blew up in our faces. That
really does smack of a bad AV/PFW hook that's messing with handles.
Is there something inherently wrong with having different treads access
different files at once?
No, of course not; any failures are real bugs. However, nobody's going to
be very likely to fix it in 1.5, so you should definitely see if it reproduces
under 1.7. If you can't narrow it down to a BLODA, that is.
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
Greg Freemyer wrote: ... My personal desire is make a full dd copy of a snapshot onto a external drive. ie. dd if=/dev/sd-shadowcopy4 of=my_image_file With new Cygwin 1.7, the VSS volume image can be retrieved as follows: dd if='//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy4' of=... But this does not work with Cygwin 1.5. To access individual files, assign a drive letter X: to the VSS volume: http://blogs.msdn.com/adioltean/archive/2006/09/18/761515.aspx http://blogs.msdn.com/adioltean/archive/2005/01/20/357836.aspx Then you can access the files via /cygdrive/x. This works with cygwin 1.5 also. Only the WinXP explorer refuses to access the drive. See also related discussion here: http://cygwin.com/ml/cygwin/2008-11/msg00070.html Hope this helps, Christian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
On Wed, Feb 25, 2009 at 1:57 PM, Christian Franke christian.fra...@t-online.de wrote: Greg Freemyer wrote: ... My personal desire is make a full dd copy of a snapshot onto a external drive. ie. dd if=/dev/sd-shadowcopy4 of=my_image_file With new Cygwin 1.7, the VSS volume image can be retrieved as follows: dd if='//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy4' of=... But this does not work with Cygwin 1.5. To access individual files, assign a drive letter X: to the VSS volume: http://blogs.msdn.com/adioltean/archive/2006/09/18/761515.aspx http://blogs.msdn.com/adioltean/archive/2005/01/20/357836.aspx Then you can access the files via /cygdrive/x. This works with cygwin 1.5 also. Only the WinXP explorer refuses to access the drive. See also related discussion here: http://cygwin.com/ml/cygwin/2008-11/msg00070.html Hope this helps, Wonderful links and information!! That is all I really needed, since I assume 1.5 is basically no longer being developed, I don't see a big need to create mappings for the shadow volumes. I do think it would be good to have the above links and documentation added to the special names section of the documentation. Time to experiment with Cygwin 1.7 I know the whole package is still considered test. How stable is the actual dll(s). Especially as relates to this type of functionality. Thanks Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.25: pthread/ofstream problem
Which version is this? Is it the full version with antispyware and all sorts of extra tricks built in? What anti-virus do you have? It's using Symantec Endpoint Protection 11.0.2000.1567 - all the bells and whistles. I blamed AVS at first, but the problem also persists on machines that do not have any AVS installed. I double checked and ran another test today on a different machine that also ended the same way (exact same spot too), but only at 100k iterations. But, it should be noted that the stackdump has occurred at different points, in different threads (as opposed to main). I can try to provide those if anyone is interested. Is there something inherently wrong with having different treads access different files at once? No, of course not; any failures are real bugs. Thank you for the sanity check. I'll test with 1.7 but I just wanted to say that it's not AVS/PFW to blame here. Could it possibly be Windows Explorer itself? Again, it does seem to occur more often when an explorer window is open to the output directory, in which it refreshes the status of the files being opened/closed every so often. It would also be nice to know if someone else can reproduce the issue; perhaps just leave it running on a computer overnight. Regards, Stefan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Looking for Linux cross-compiler for cygwin
Hi I am trying to build android sdk components for windows on Linux. I read there are cygwin cross compiler that can run on Linux and generate Cygwin compatible binaries. I came across http://www.libsdl.org/extras/win32/cross/ that has mingw cross compiler that runs on Linux. I am looking for cygwin cross compiler. I have C, C++ code that will be compiled on Linux using this cross compiler. The binaries should run fine on windows as if they were built under cygwin on windows. Are there prebuilt cygwin cross compilers (like gcc, g++)? I appreciate your help. Thanks Video guy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Dave Korn wrote: The purpose of playing these games is in order not to drag in the whole exception handling machinery into a statically-linked application unless we actually need it. We're relying on detecting an unlinked weak symbol by it having a value of zero at runtime. That usually works, but the pointer variable register_frame_info_ptr must have some kind of reloc pointing at it, because rebase adjusts it, so instead of zero it becomes equal to the difference between the new and old base addresses. That rang a bell, and reminded me of something Danny posted a little while back: http://sourceware.org/ml/binutils/2008-07/msg00372.html So I believe now this is a symptom of a buggy ld already fixed upstream. I'll try the testcase again against one of my CVS builds of binutils and report back, but I expect it will fix the problem and rebase will no longer alter the unlinked weak null-initialised pointer. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: question about fonts
kurin wrote: Hi, each time I launch the bash shell first then /usr/X11R6/bin/startxwin.sh to start the X-term then ssh to the server in my department.. but there're two questions, one is I want to change the fonts but don't know how. and then I couldn't start the windows copy/paste facility in an X-term (the background is while) Wrong list. X questions go to the cygwin-xfree list. You may find 'max xterm' to be helpful in changing the fonts. See the '-fb' flag. You may find it beneficial to look at the X documentation as well. For instance http://x.cygwin.com/docs/ug/configure-cygwin-x-options.html should probably help you with your copy/paste question. -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
Greg Freemyer wrote: snip Time to experiment with Cygwin 1.7 I know the whole package is still considered test. How stable is the actual dll(s). Especially as relates to this type of functionality. Difficult to say since this functionality isn't on a typical use path and no specific efforts have been made to 'integrate' it into Cygwin, whatever form that integration might take. What is clear, however, is if there is a problem using this functionality in 1.7, now would be the time to find out. Since the 1.7 DLL is near its final form for release, any hope of fixing problems before the release requires that they be found first. -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lynx seems broken
Morten Kjærulff wrote: Hi, On my machine#2 I just installed lynx, but it just exit without telling anything. Then I went to my machine#1 where lynx was already installed, and it worked fine. I then ran setup.exe and it installed a little. After that, lynx just exit without telling anything. What does 'lynx; echo $?' say? What does 'cygcheck lynx' say? -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lynx seems broken
On Thu, Feb 26, 2009 at 12:10 AM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Morten Kjærulff wrote: Hi, On my machine#2 I just installed lynx, but it just exit without telling anything. Then I went to my machine#1 where lynx was already installed, and it worked fine. I then ran setup.exe and it installed a little. After that, lynx just exit without telling anything. What does 'lynx; echo $?' say? What does 'cygcheck lynx' say? $ lynx;echo $?;cygcheck lynx 57 Found: C:\cygwin\bin\lynx.exe C:\cygwin\bin\lynx.exe C:\cygwin\bin\cygcrypto-0.9.8.dll C:\cygwin\bin\cygwin1.dll C:\WINDOWS\system32\ADVAPI32.DLL C:\WINDOWS\system32\KERNEL32.dll C:\WINDOWS\system32\ntdll.dll C:\WINDOWS\system32\RPCRT4.dll C:\WINDOWS\system32\Secur32.dll C:\cygwin\bin\cygintl-3.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygncurses-8.dll C:\cygwin\bin\cygssl-0.9.8.dll C:\WINDOWS\system32\USER32.dll C:\WINDOWS\system32\GDI32.dll $ Cheers, Morten -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc: problem with scanf/printf with 64 bit integers on cygwin with -mno-cygwin
I use the type unsigned long long and long long to get 64 bit integers on gcc. For reading and writing I use the formatting e.g. unsigned long long u64; u64 = ...; printf(a 64 bit integer %llu\n, u64); This has worked up to now on all systems using gcc except on cygwin compiling with the option -mno-cygwin and on mingw. I get the following problems: - If I print a 64 bit integer alone, the output is ok, if I print 64 bit and 32 bit integers with the same print statement, the output is not the content of the integers. - If I scan a 64 bit integer and the corresponding and the variable into which I read is not initialized, the input is not correct. Is this problem known? Unfortunately the problem is within a big program. But if needed, I could try to isolate it in a small program. But I don't know, if the problem is deterministic, so I cannot promise that. Kind regards Helmut -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: lynx seems broken
Morten Kjærulff wrote: On Thu, Feb 26, 2009 at 12:10 AM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Morten Kjærulff wrote: Hi, On my machine#2 I just installed lynx, but it just exit without telling anything. Then I went to my machine#1 where lynx was already installed, and it worked fine. I then ran setup.exe and it installed a little. After that, lynx just exit without telling anything. What does 'lynx; echo $?' say? What does 'cygcheck lynx' say? $ lynx;echo $?;cygcheck lynx 57 Perhaps this is your problem? http://www.cygwin.com/ml/cygwin/2008-12/msg00727.html -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc: problem with scanf/printf with 64 bit integers on cygwin with -mno-cygwin
On 02/25/2009, Helmut Brandl wrote: I use the type unsigned long long and long long to get 64 bit integers on gcc. For reading and writing I use the formatting e.g. unsigned long long u64; u64 = ...; printf(a 64 bit integer %llu\n, u64); This has worked up to now on all systems using gcc except on cygwin compiling with the option -mno-cygwin and on mingw. Cygwin's '-mno-cygwin' flag means use Cygwin's mingw compiler package. So this is a mingw issue. I recommend looking for the solution at the mingw site. -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Another long pathname question
I just read the release email for 1.7.0 In part it says: - Fallout from the long path names: If the current working directory is longer than 260 bytes, or if the current working directory is a virtual path (like /proc, /cygdrive, //server), don't call native Win32 programs since they don't understand these paths. I've done a fair amount of long path name testing in Vista / Win2008, and I'd like to understand the above in more detail. In particular in Vista/Win2008 the open dialog box now allows me to open and modify pre-existing files with long paths. Or I can use the file explorer to browse to those files, then right click and open them successfully. FYI: the command line tools for Vista / Win2008 seem to still have an issue with long paths. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
A personal getting started document
I am not certain if this is an appropriate email for this list, but I think it probably is. (If not, I am certain someone will let me know G) I recently installed and started (trying to) use Cygwin. I did this, NOT because I am someone who is used to or even knows UNIX or Linux, but rather because I wanted to install and use OpenCOBOL (an Open Source COBOL package). (The last time that I actually used UNIX for any time, was in the early '80s - when working for the phone company before divestiture. Even then, I primarily used it to use TROFF for developing and write a COBOL programming course.) I had some trials and tribulations trying to get Cygwin installed for use with OpenCOBOL and then getting OpenCOBOL up and working for me. Therefore, I created for that project a Getting Started document that includes step by step instructions for installing Cygwin (for use with OpenCOBOL) and then OpenCOBOL itself. Obviously, this document has a specific and targeted audience. On the other hand, I thought that some in this list might have the time and inclination to look at it and give me any corrections and/or suggestions for improvement - especially when it comes to the Cygwin side of things. The document can be found online in either PDF or HTML at: http://opencobol.add1tocobol.com/oc_gettingstarted_windows.html or http://opencobol.add1tocobol.com/OC_GettingStarted_Windows.pdf If you have any comments, suggestions, or corrections, please feel free to send them to me off-list at wmklein at ix.netcom.com or via this list (assuming the topic itself is considered appropriate). Thanks in advance for any input you can give me. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
On Wed, Feb 25, 2009 at 6:01 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Greg Freemyer wrote: snip Time to experiment with Cygwin 1.7 I know the whole package is still considered test. How stable is the actual dll(s). Especially as relates to this type of functionality. Difficult to say since this functionality isn't on a typical use path and no specific efforts have been made to 'integrate' it into Cygwin, whatever form that integration might take. What is clear, however, is if there is a problem using this functionality in 1.7, now would be the time to find out. Since the 1.7 DLL is near its final form for release, any hope of fixing problems before the release requires that they be found first. Okay, (trouble report, see the end of the email. Successes first :) I've got the latest 1.7 release. I'm testing right now on Vista Home. Just as an FYI, this machine has 32 snapshots in place. Going back to Thanksgiving. All of these were created automatically by Vista. I don't think I did any config work etc. to make it happen. I can see these from the Vista Command Prompt by running vssadmin list shadows. Very cool. dd seems to be working great, but I've only done a couple quick tests. dd if=global-device-path | od -cv | less is showing what looks like good data. I tried the same with snapshot instance 33. As hoped dd came back with an error message since that snapshot does not exist. I currently have 5 dd's running against 5 different snapshots and the output going to /dev/null.Per task manager all are actively reading data. Very cool. They are reading very slowly, but then again I'm beating the heck out of the drive. I tried the dosdev trick from one of the links to mount the snapshot as V:. Apparently that is a XP only trick. Or at least Vista does not have it. From the Vista command prompt I can do: mklink /d C:\shadow_copy21 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy21\ and then cd into that directory and see my old snapshot data. I can also see it from the Vista file explorer. From cygwin's shell if I try to do so I get: $ cd /cygdrive/c/shadow_copy21 bash: cd: /cygdrive/c/shadow_copy21: No such file or directory I assume that should work? Thanks Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
Greg Freemyer wrote: On Wed, Feb 25, 2009 at 6:01 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Greg Freemyer wrote: snip Time to experiment with Cygwin 1.7 I know the whole package is still considered test. How stable is the actual dll(s). Especially as relates to this type of functionality. Difficult to say since this functionality isn't on a typical use path and no specific efforts have been made to 'integrate' it into Cygwin, whatever form that integration might take. What is clear, however, is if there is a problem using this functionality in 1.7, now would be the time to find out. Since the 1.7 DLL is near its final form for release, any hope of fixing problems before the release requires that they be found first. Okay, (trouble report, see the end of the email. Successes first :) I've got the latest 1.7 release. I'm testing right now on Vista Home. Just as an FYI, this machine has 32 snapshots in place. Going back to Thanksgiving. All of these were created automatically by Vista. I don't think I did any config work etc. to make it happen. I can see these from the Vista Command Prompt by running vssadmin list shadows. Very cool. dd seems to be working great, but I've only done a couple quick tests. dd if=global-device-path | od -cv | less is showing what looks like good data. I tried the same with snapshot instance 33. As hoped dd came back with an error message since that snapshot does not exist. I currently have 5 dd's running against 5 different snapshots and the output going to /dev/null.Per task manager all are actively reading data. Very cool. They are reading very slowly, but then again I'm beating the heck out of the drive. I tried the dosdev trick from one of the links to mount the snapshot as V:. Apparently that is a XP only trick. Or at least Vista does not have it. From the Vista command prompt I can do: mklink /d C:\shadow_copy21 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy21\ and then cd into that directory and see my old snapshot data. I can also see it from the Vista file explorer. From cygwin's shell if I try to do so I get: $ cd /cygdrive/c/shadow_copy21 bash: cd: /cygdrive/c/shadow_copy21: No such file or directory I assume that should work? Dunno. I can't get the 'cd' or 'dir' to work from the Vista command prompt. For me, 'dir foo' (I named the link 'foo') gives me 'File Not Found'. So in my case, what you see from Cygwin makes sense since it's consistent with what Windows tells me. -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Need info on removing corrupted parrot 7.1
I get an error with setup trying to access memory loc #0 when attempting to remove or update parrot 7.1. I tried editing setup files and removing manually, with negative results. Anyone have any ideas? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Need info on removing corrupted parrot 7.1
Mr Webber wrote: I get an error with setup trying to access memory loc #0 when attempting to remove or update parrot 7.1. I tried editing setup files and removing manually, with negative results. Anyone have any ideas? Please don't usurp someone else's thread for your own purposes. If you have a new question or issue, just create a new message and send it to the list. There's no need to respond to some random unrelated existing message/thread. -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: file-5.00-1
Dave Korn wrote: http://sourceware.org/ml/binutils/2008-07/msg00372.html So I believe now this is a symptom of a buggy ld already fixed upstream. I'll try the testcase again against one of my CVS builds of binutils and report back, but I expect it will fix the problem and rebase will no longer alter the unlinked weak null-initialised pointer. Confirmed. (This has implications which I will pursue in the GCC4 thread on -apps.) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[Fwd: Re: Reproducing the cygwin X problems; MinTTY, too]
---BeginMessage--- Lee D.Rothstein wrote: FWIW, I'm having a similar proble with MinTTY. If I select text in a MinTTY window, then copy text withing a GUI app, like TextPad (http://textpad.com), clipboard stops working for all apps. If I ten return to the original, MinTTY window, and reselect text, paste it, that works and then copy and paste work in all apps, again. MinTTY problems are probably better directed to the cygwin@cygwin.com list or at http://code.google.com/p/mintty/ -- 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/ ---End Message--- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
On Wed, Feb 25, 2009 at 8:44 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Greg Freemyer wrote: On Wed, Feb 25, 2009 at 6:01 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Greg Freemyer wrote: snip Time to experiment with Cygwin 1.7 I know the whole package is still considered test. How stable is the actual dll(s). Especially as relates to this type of functionality. Difficult to say since this functionality isn't on a typical use path and no specific efforts have been made to 'integrate' it into Cygwin, whatever form that integration might take. What is clear, however, is if there is a problem using this functionality in 1.7, now would be the time to find out. Since the 1.7 DLL is near its final form for release, any hope of fixing problems before the release requires that they be found first. Okay, (trouble report, see the end of the email. Successes first :) I've got the latest 1.7 release. I'm testing right now on Vista Home. Just as an FYI, this machine has 32 snapshots in place. Going back to Thanksgiving. All of these were created automatically by Vista. I don't think I did any config work etc. to make it happen. I can see these from the Vista Command Prompt by running vssadmin list shadows. Very cool. dd seems to be working great, but I've only done a couple quick tests. dd if=global-device-path | od -cv | less is showing what looks like good data. I tried the same with snapshot instance 33. As hoped dd came back with an error message since that snapshot does not exist. I currently have 5 dd's running against 5 different snapshots and the output going to /dev/null. Per task manager all are actively reading data. Very cool. They are reading very slowly, but then again I'm beating the heck out of the drive. I tried the dosdev trick from one of the links to mount the snapshot as V:. Apparently that is a XP only trick. Or at least Vista does not have it. From the Vista command prompt I can do: mklink /d C:\shadow_copy21 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy21\ and then cd into that directory and see my old snapshot data. I can also see it from the Vista file explorer. From cygwin's shell if I try to do so I get: $ cd /cygdrive/c/shadow_copy21 bash: cd: /cygdrive/c/shadow_copy21: No such file or directory I assume that should work? Dunno. I can't get the 'cd' or 'dir' to work from the Vista command prompt. For me, 'dir foo' (I named the link 'foo') gives me 'File Not Found'. So in my case, what you see from Cygwin makes sense since it's consistent with what Windows tells me. Very strange mklink created usable directories for me on both Vista Home and Win 2008. Can you or someone else test it on another machine? ie. Cygwin need not be installed to test this Windows feature. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: special name for vss shadow copy device?
Greg Freemyer wrote: On Wed, Feb 25, 2009 at 8:44 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Greg Freemyer wrote: On Wed, Feb 25, 2009 at 6:01 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: Greg Freemyer wrote: snip Time to experiment with Cygwin 1.7 I know the whole package is still considered test. How stable is the actual dll(s). Especially as relates to this type of functionality. Difficult to say since this functionality isn't on a typical use path and no specific efforts have been made to 'integrate' it into Cygwin, whatever form that integration might take. What is clear, however, is if there is a problem using this functionality in 1.7, now would be the time to find out. Since the 1.7 DLL is near its final form for release, any hope of fixing problems before the release requires that they be found first. Okay, (trouble report, see the end of the email. Successes first :) I've got the latest 1.7 release. I'm testing right now on Vista Home. Just as an FYI, this machine has 32 snapshots in place. Going back to Thanksgiving. All of these were created automatically by Vista. I don't think I did any config work etc. to make it happen. I can see these from the Vista Command Prompt by running vssadmin list shadows. Very cool. dd seems to be working great, but I've only done a couple quick tests. dd if=global-device-path | od -cv | less is showing what looks like good data. I tried the same with snapshot instance 33. As hoped dd came back with an error message since that snapshot does not exist. I currently have 5 dd's running against 5 different snapshots and the output going to /dev/null.Per task manager all are actively reading data. Very cool. They are reading very slowly, but then again I'm beating the heck out of the drive. I tried the dosdev trick from one of the links to mount the snapshot as V:. Apparently that is a XP only trick. Or at least Vista does not have it. From the Vista command prompt I can do: mklink /d C:\shadow_copy21 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy21\ and then cd into that directory and see my old snapshot data. I can also see it from the Vista file explorer. From cygwin's shell if I try to do so I get: $ cd /cygdrive/c/shadow_copy21 bash: cd: /cygdrive/c/shadow_copy21: No such file or directory I assume that should work? Dunno. I can't get the 'cd' or 'dir' to work from the Vista command prompt. For me, 'dir foo' (I named the link 'foo') gives me 'File Not Found'. So in my case, what you see from Cygwin makes sense since it's consistent with what Windows tells me. Very strange mklink created usable directories for me on both Vista Home and Win 2008. Can you or someone else test it on another machine? Sorry. Fresh out of Vista machines (sniff ;-)) -- 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://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wget, ssh, ... and cygwin 1.7 issues
Corinnia: I finally got cygwin 1.7 swapped-in to try to reproduce my problem. Good news, after a few hours of pinging a website, ZERO ERRORS for now. Since it is an intermittent error, I'll let it run at 6 seconds interval until tomorrow. Now some issues raised with 1.7 . $ ls -l /etc/passwd /etc/group -rwxrwxrwx+ 1 UNKNOWN mkpasswd 74 Feb 25 23:42 /etc/group -rwxrwxrwx+ 1 UNKNOWN mkpasswd 81 Jan 11 19:06 /etc/passwd For BOTH files having write access by everyone, any attemps to edit the files with vim will result on a permament block on OPEN. No EPERM error code. Now I did NOT upgrade anything elso but just replacing cygwin1.dll file. I was able to append a new-line to the group file. When editing group file, vim group became vim -u NONE group is procps output. As I was reading 1.7 docs on mkpasswd mkproup, I didn't see any way to specify a UID or GID when creating the entry. Otherwise, things are looking up. With my two web servers running fine. Corinna Vinschen wrote: On Feb 22 18:24, Paul McFerrin wrote: I've been having the same problem for the past two weeks. Just didn't know where to look. Thanks for sharing. Maybe we can get someone on this. Wget would just HANG intermittently in the Connecting phase. I don't observe this problem. Does updating to Cygwin 1.7 help? Corinna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] New: tack-1.06-10
The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. tack was distributed as part of the ncurses package until (upstream) 5.7, when it was spun out into its own package. Because cygwin's ncurses package(s) have recently been updated to 5.7, the new versions are deficient compared to the old ones. This package remedies that. This release is cygwin-1.7 specific. There is a different release for cygwin-1.5. -- Charles Wilson To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] New: tack-1.06-1
The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. tack was distributed as part of the ncurses package until (upstream) 5.7, when it was spun out into its own package. Because cygwin's ncurses package(s) have recently been updated to 5.7, the new versions are deficient compared to the old ones. This package remedies that. This release is cygwin-1.5 specific. There is a different release for cygwin-1.7. -- Charles Wilson To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] New: tack-1.06-10
Charles Wilson wrote: The tack program is a diagnostic that is designed to create and verify Sorry. Wrong list. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] New: tack-1.06-10
The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. tack was distributed as part of the ncurses package until (upstream) 5.7, when it was spun out into its own package. Because cygwin's ncurses package(s) have recently been updated to 5.7, the new versions are deficient compared to the old ones. This package remedies that. This release is cygwin-1.7 specific. There is a different release for cygwin-1.5. -- Charles Wilson To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
New: tack-1.06-10
The tack program is a diagnostic that is designed to create and verify the correctness of terminfo's. This program can be used to create new terminal descriptions that are not included in the standard terminfo database. tack was distributed as part of the ncurses package until (upstream) 5.7, when it was spun out into its own package. Because cygwin's ncurses package(s) have recently been updated to 5.7, the new versions are deficient compared to the old ones. This package remedies that. This release is cygwin-1.7 specific. There is a different release for cygwin-1.5. -- Charles Wilson To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
