emacs-w32 (64bit) displays generic tray icon
Hi, I've recently made the switch to 64bit Cygwin for my day-to-day use. I've already encountered a few (about four) minor issues. However once they become repeatable I'll follow reporting guidelines and report. This one though is a simple one that hopefully is easily verifiable. When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. -- Thanks, Shaddy -- 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: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
On Aug 16 10:32, Kal Sze wrote: > I have been using Cygwin 32-bit on Windows 7 Profession 64-bit. I had > the HKLM\SYSTEM\CurrentControlSet\Control\Session > Manager\kernel\ObCaseInsensitive registry key set to DWORD 0x > and case-sensitive filename handling has been fully working in Cygwin > 32-bit (as far as I can tell from my usage anyway). > > Now that Cygwin 64-bit has been released, I want to try it. I notice > that git in Cygwin 64-bit does not seem to correctly handle filesname > that differ only by case. > > To reproduce, create a repository in Cygwin 32-bit *with the > aforementioned registry key set*: > > $ git init case_sensitivity_test; cd case_sensitivity_test > > Create two files of different content with similar filenames that > differ only by case: > > $ echo 'FOO' > FOO.TXT; echo 'foo' > foo.txt > > Commit them into the repository: > > $ git add .; git commit -m 'Initial commit' > [master (root-commit) 16d1b59] Initial commit > 2 files changed, 2 insertions(+), 0 deletions(-) > create mode 100644 FOO.TXT > create mode 100644 foo.txt > > In Cygwin 32-bit, this looks all green: > > $ git status > # On branch master > nothing to commit (working directory clean) > $ ls > FOO.TXT foo.txt > > Now, fire up the Cygwin64 terminal and browse to the repository, then: > > $ ls > FOO.TXT foo.txt > $ cat FOO.TXT > FOO > $ cat foo.txt > foo > > So `ls` and `cat` both recognize the two different files. However: > > $ git status > # On branch master > # Changes not staged for commit: > # (use "git add ..." to update what will be committed) > # (use "git checkout -- ..." to discard changes in working > directory) > # > # modified: foo.txt > # > no changes added to commit (use "git add" and/or "git commit -a") > > "Oops." The interesting thing here is, if you try this the other way around, you'll see the exact same effect. If you created the above git repo with 64 bit git, everything works exactly as in the 32 bit version and the two files are correctly recognized. I assume the format of the git database files depends on the architecture. Therefore it's probably not advisable to use a git repo created under 32 bit git with a 64 bit git and vice versa. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp43o5AtVnrM.pgp Description: PGP signature
Re: 64-bit Cygwin installation is missing /usr/bin/lockfile
On Aug 15 16:02, Steve Rowley wrote: > On Aug 14 16:34, Corinna Vinschen wrote: > >On Aug 14 16:04, Corinna Vinschen wrote: > >>On 8/13/2013 5:01 PM, Steve Rowley wrote: > >>>I just installed 64-bit Cygwin on Win7, and noticed that /usr/bin/lockfile > >>>is missing in my installation. [...] > >> > >>It's just a packaging bug. Somehow I tripped over the order of variable > >>evaluation. I'm looking into it and provide a new 64 bit procmail later > >>today. > > > >I just uploaded procmail-3.22-13. Please give it a try. > > I waited for the mirrors to update and then installed > procmail-3.22-13. The result: /usr/bin/lockfile is once again > present, and my backup script now runs and completes properly, much to > my relief. > > So: thanks very much. > > And just in case nobody says this often enough: you have a difficult > job maintaining a beast as complex as Cygwin, and we all appreciate it > very much. Thanks for your feedback! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpySIHrQ92tS.pgp Description: PGP signature
GNU ld -O option breaks compilation
I am getting compilation error when I try to use the GNU ld's -O option:
`--> cat test.c
int
main ()
{
return 0;
}
`--> gcc -Wl,-O -o test test.c
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../lib/libcygwin.a(libcmain.o):
In function `main':
/usr/src/debug/cygwin-1.7.24-1/winsup/cygwin/lib/libcmain.c:39:
undefined reference to `WinMain'
/usr/src/debug/cygwin-1.7.24-1/winsup/cygwin/lib/libcmain.c:39:(.text.startup+0x7e):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`WinMain'
collect2: error: ld returned 1 exit status
--
VZ
--
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
curl on 64bit always includes headers
Hi, I think this is some sort of regression best demonstrated with copy/paste: $ uname -a CYGWIN_NT-6.1-WOW64 AUD-CYGHOST 1.7.22(0.268/5/3) 2013-07-22 17:06 i686 Cygwin $ curl 'http://www.google.com/' content="text/html;charset=utf-8">302 Moved302 MovedThe document has moved HREF="http://www.google.com.au/?gws_rd=cr";>here. Compared with: $ uname -a CYGWIN_NT-6.1 AUD-CYGHOST 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ curl 'http://www.google.com/' HTTP/1.1 302 Moved Temporarily Content-Length: 226 Location: http://www.google.com.au/?gws_rd=cr Cache-Control: private Content-Type: text/html; charset=UTF-8 Set-Cookie: PREF=ID=e0106a09639a312d:FF=0:TM=1376643265:LM=1376643265:S=zsZySjsnTdcRg3yL; expires=Sun, 16-Aug-2015 08:54:25 GMT; path=/; domain=.google.com Set-Cookie: NID=67=REaoG7I9iVPjoxnMrgVSSk6wbQBcmffuagiPTm9lg2zVVbOfmcz7htEDoxX1eUUOAp7Uw-sjt_0j2xOT2b6OGYT6R7oa4Qlah1YavOorYSEeimCLLJV_lMnBCMSHxl3J; expires=Sat, 15-Feb-2014 08:54:25 GMT; path=/; domain=.google.com; HttpOnly P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info." Date: Fri, 16 Aug 2013 08:54:25 GMT Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Alternate-Protocol: 80:quic Connection: keep-alive content="text/html;charset=utf-8">302 Moved302 MovedThe document has moved HREF="http://www.google.com.au/?gws_rd=cr";>here. PS: the 32bit is not 1.7.24 yet. I haven't got around to it yet. -- Regards, Shaddy -- 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: 64-bit emacs crashes a lot
I'm not subscribed to this list, so if you want me to reply, please CC me explicitly. Besides, this discussion should be moved to emacs-de...@gnu.org, since I don't see anything Cygwin specific here at this point. > Date: Thu, 15 Aug 2013 16:55:18 -0400 > From: Ryan Johnson > > On 15/08/2013 1:10 PM, Eli Zaretskii wrote: > >> Date: Thu, 15 Aug 2013 12:58:02 -0400 > >> From: Ken Brown > >> CC: Eli Zaretskii > >> > >> Eli is the expert on bidi.c (he wrote it). He can probably tell you > >> whether you've really bumped into an emacs bug here. > > There's nothing wrong with bidi.c here, it just aborts because it is > > handed an invalid character codepoint. It would have been useful to > > see the value of that character. > I guess I would just consider crashing to be overkill for a bad byte on > the input stream... It's not a crash, it's a deliberate abort. Any invalid codepoint at such low level of the Emacs display engine means only one thing: a bug, and a grave one at that. Such bugs must be flagged prominently and unequivocally, prompting users to report them. We could in principle "recover" by substituting some other character, but such recovery would only sweep a grave problem under the carpet. Since Emacs isn't a safety-critical program, and auto-saves your edits before it commits suicide, such recovery feature is deemed inappropriate, and detrimental to the general quality of Emacs code in the long run. > and in any case, if 5-byte UTF-8 is illegal, and > worth dying for, wouldn't it make sense to die right away rather than > processing it so something else can croak down the road? See above: yes, it's worth dying for, because I'm quite sure this is a sign of a very serious trouble in the session anyway. Why does it matter for you, as a user, whether we abort here or "down the road"? The principle is to die as soon as possible, because in many cases this allows to identify the culprit faster and easier. IOW, dying sooner and faster helps the Emacs maintainers to find and fix problems without any real effect on the users. > > Anyway, I generally agree that this is probably some memory > > corruption, as I'm guessing that the text in the window was all ASCII > > in this case, so any character codepoint beyond 127 is not to be > > expected. > I set a breakpoint there, since I thought it was guaranteed to lead to a > crash if it ever ran, but it turns out that's not true. Invoking M-x > compile triggers the breakpoint twice in a row with the following > (valid!) 5-byte UTF-8: > > 10XX 10XX 10XX 10XX 10XX > 1000 1000 1011 1001 1011 > > The value is always the same, and corresponds to the code point > U+3FFF7F, FWIW. If the value is positive and below 3F, then the abort could not have happened. Therefore, I believe that the optimized build lies to GDB, and the actual value is not what you see in GDB. Alternatively (and that is also a known effect of debugging an optimized build), the abort happened not where you think, but rather a few lines below: default_type = (bidi_type_t) XINT (CHAR_TABLE_REF (bidi_type_table, ch)); /* Every valid character code, even those that are unassigned by the UCD, have some bidi-class property, according to DerivedBidiClass.txt file. Therefore, if we ever get UNKNOWN_BT (= zero) code from CHAR_TABLE_REF, that's a bug. */ if (default_type == UNKNOWN_BT) emacs_abort (); << Optimized code frequently emits only one call to emacs_abort, and converts the other calls to a jump to the locus of that single call. I really suggest to get an unoptimized build and debug that instead. Debugging optimized builds, even with GCC 4.8, is a hard and frustrating task. In particular, most of the backtraces you posted don't make any sense at all -- a frequent problem in optimized builds. -- 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: 64-bit emacs crashes a lot
Again, please move this discussion to emacs-devel. > Date: Thu, 15 Aug 2013 22:35:54 -0400 > From: Ken Brown > > 1. Invoke 'emacs-nox -Q' in mintty. > > 2. M-x compile C-a C-k ls RET > > 3. C-x o > > 4. Hit 'g' repeatedly. > > I got it to abort with Fatal error 6 after slightly over 100 repetitions. > > I then tried the same thing with emacs-X11 (running under X, not in > mintty). I hit 'g' 200 times without a problem. I repeated this with > emacs-w32, again 200 times without a problem. > > So there's a bug somewhere. But if it's an emacs bug, it's strange that > it only occurs with emacs-nox and not with either of the GUI versions of > emacs. I suspect that buffer relocation might be the reason. Can you show a backtrace from the fatal error in an unoptimized build, with the above recipe? -- 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: 64-bit emacs crashes a lot
Ryan Johnson wrote: >I set a breakpoint there, since I thought it was guaranteed to lead to a >crash if it ever ran, but it turns out that's not true. Invoking M-x >compile triggers the breakpoint twice in a row with the following >(valid!) 5-byte UTF-8: > >10XX 10XX 10XX 10XX 10XX >1000 1000 1011 1001 1011 > >The value is always the same, and corresponds to the code point >U+3FFF7F, FWIW. The backtrace seems to involve loading a file (maybe the >.elc contains 'compile or 'compilation-mode?), and the breakpoint does >not recur in subsequent compilations, presumably because they don't >re-load the file. Emacs continues normally from there, because the >leading bits are zero and the resulting code point doesn't pass the >0x3F limit. Modern Emacs uses an extended UTF-8 as internal representation. http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Representations.html -- 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: 64-bit emacs crashes a lot
Please move this discussion to emacs-de...@gnu.org. > Date: Fri, 16 Aug 2013 01:59:41 -0400 > From: Ryan Johnson > > The variable pending_exact has value 0x0, which would be a Bad Thing... > except that the code looks like this: > > if (!pending_exact > > > > /* If last exactn not at current position. */ > > =>|| pending_exact + *pending_exact + 1 != b > > > ... with corresponding assembly code looking very reasonable: > >0x000100535cfa :cmpq $0x0,0x3f8(%rbp) > >0x000100535d02 :je 0x100535eca > > > >0x000100535d08 :mov 0x3f8(%rbp),%rax > > => 0x000100535d0f :movzbl (%rax),%eax > >0x000100535d12 :movzbl %al,%eax > >0x000100535d15 :lea 0x1(%rax),%rdx > >0x000100535d19 :mov 0x3f8(%rbp),%rax > >0x000100535d20 :add %rdx,%rax > >0x000100535d23 :cmp %rbx,%rax > >0x000100535d26 :jne 0x100535eca > > What is the value in the RAX register at the point of the crash? Is it also zero? Or maybe it is some other invalid pointer value? > A third crash: > > #1 0x000100541930 in re_match_2_internal (bufp=0x10095ce20 > > , string1=0x0, size1=0, string2=0x6f00028 "-*- > > mode: compilation; default-directory: \"~/\" -*-\nCompilation started > > at Fri Aug 16 01:32:19\n\nls\n#message-20130808-090732#\t > > emacs-crash.txt\t\tmusic\n6b8ob06a.default.tar.xz\t\t > > emacs-nox.exe."..., size2=355, pos=254, regs=0x10095def0 > > , stop=317) at regex.c:6217 > > 6217 abort (); > This time, p (the subject of the case statement) points to 0x76b3b6c7, > which is the middle of a function (ntdll!RtlFillMemory, though the > memory map places that address smack in the middle of kernel32.dll > instead). This time it makes perfect sense that the switch statement > should fail, but how did p go so wrong? What is bufp->buffer at this point, and what is its contents? -- 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: curl on 64bit always includes headers
On Aug 16 18:39, Shaddy Baddah wrote: > Hi, > > I think this is some sort of regression best demonstrated with > copy/paste: > > $ uname -a > CYGWIN_NT-6.1-WOW64 AUD-CYGHOST 1.7.22(0.268/5/3) 2013-07-22 17:06 > i686 Cygwin > > $ curl 'http://www.google.com/' > content="text/html;charset=utf-8">302 > Moved302 MovedThe document has moved > http://www.google.com.au/?gws_rd=cr";>here. > > > > Compared with: > > $ uname -a > CYGWIN_NT-6.1 AUD-CYGHOST 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin > > $ curl 'http://www.google.com/' > HTTP/1.1 302 Moved Temporarily > Content-Length: 226 > Location: http://www.google.com.au/?gws_rd=cr > Cache-Control: private > Content-Type: text/html; charset=UTF-8 > Set-Cookie: > PREF=ID=e0106a09639a312d:FF=0:TM=1376643265:LM=1376643265:S=zsZySjsnTdcRg3yL; > expires=Sun, 16-Aug-2015 08:54:25 GMT; path=/; domain=.google.com > Set-Cookie: > NID=67=REaoG7I9iVPjoxnMrgVSSk6wbQBcmffuagiPTm9lg2zVVbOfmcz7htEDoxX1eUUOAp7Uw-sjt_0j2xOT2b6OGYT6R7oa4Qlah1YavOorYSEeimCLLJV_lMnBCMSHxl3J; > expires=Sat, 15-Feb-2014 08:54:25 GMT; path=/; domain=.google.com; > HttpOnly > P3P: CP="This is not a P3P policy! See > http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 > for more info." > Date: Fri, 16 Aug 2013 08:54:25 GMT > Server: gws > X-XSS-Protection: 1; mode=block > X-Frame-Options: SAMEORIGIN > Alternate-Protocol: 80:quic > Connection: keep-alive > > content="text/html;charset=utf-8">302 > Moved302 MovedThe document has moved > http://www.google.com.au/?gws_rd=cr";>here. > I can't reproduce this: $ uname -a CYGWIN_NT-6.2 VMBERT864 1.7.24(0.269/5/3) 2013-08-15 11:59 x86_64 Cygwin $ curl 'http://www.google.com/' 302 Moved 302 Moved The document has moved http://www.google.de/?gws_rd=cr";>here. $ Any chance you have a .curlrc file with an "include" line? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLg7S2mMZPM.pgp Description: PGP signature
Re: GNU ld -O option breaks compilation
On Aug 16 10:50, Václav Zeman wrote:
> I am getting compilation error when I try to use the GNU ld's -O option:
>
> `--> cat test.c
> int
> main ()
> {
> return 0;
> }
>
> `--> gcc -Wl,-O -o test test.c
> /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../lib/libcygwin.a(libcmain.o):
> In function `main':
> /usr/src/debug/cygwin-1.7.24-1/winsup/cygwin/lib/libcmain.c:39:
> undefined reference to `WinMain'
> /usr/src/debug/cygwin-1.7.24-1/winsup/cygwin/lib/libcmain.c:39:(.text.startup+0x7e):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `WinMain'
> collect2: error: ld returned 1 exit status
Per the ld info pages, the -O option is only designed to work for
ELF shared libraries so far.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpGaDPA8GxcX.pgp
Description: PGP signature
shell-init: error retrieving current directory
This might be the same issue as a couple of previous unresolved reports with the same error message, but I'm not sure, so here's a new thread. Steps to reproduce: - On Windows 7, install 64-bit Cygwin into C:\cygwin, and let it create a desktop shortcut. - Edit /etc/fstab to change the cygdrive prefix to /. - Double click 'Cygwin64 Terminal' desktop shortcut. Result: a bunch of errors before the bash prompt. shell-init: error retrieving current directory: getcwd: cannot access parent directories: Bad file descriptor job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory chdir: error retrieving current directory: getcwd: cannot access parent directories: No error The errors remain if the shortcut target is changed from invoking mintty to invoking bash directly: 'C:\cygwin\bin\bash.exe -l'. The errors go away if 'C:\cygwin\bin' is put into the shortcut's otherwise empty 'Start In' field. (But they stay if 'C:\' is put there instead.) They also go away if the cygdrive prefix is changed to anything but the root directory. I couldn't reproduce the issue with a 32-bit install. Regards, 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: Octave 3.6.4 cannot plot in X server
On Aug 15 23:37, Larry Hall (Cygwin) wrote: > On 8/15/2013 8:38 PM, Yuxiang Wang wrote: > >Dear all, > > > >I have installed Octave with Cygwin 64-bit, under Win 7. Besides > >octave-3.6.4-1, I also installed xinit and xlaunch according to the > >doc, and gnuplot just in case. > > > >However, when I start X terminal, open octave (that all went > >successfully) and enter plot(1:5), I got the following message: > > > >octave:1> plot(1:5) > > 0 [main] octave-3.6.4 2708 child_info_fork::abort: > >C:\cygwin64\bin\cygoctave-1.dll: Loaded to different address: > >parent(0xF0) != ch > >error: popen2: process creation failed -- Resource temporarily unavailable > >error: called from: > >error: /usr/share/octave/3.6.4/m/plot/private/__gnuplot_open_stream__.m > >at line 30, column 44 > >error: /usr/share/octave/3.6.4/m/plot/__gnuplot_drawnow__.m at line > >72, column 19 > > > >Would anyone please help me with this? > > In 64-bit land, the available address space for Cygwin DLLs is much > increased. This should theoretically eliminate the "casual" overlap > of address spaces for loaded DLLs, which was a common fork failure vector > in 32-bit land. Not exactly eliminated, but drastically reduced. The problem is, the hash algorithm used by ld to compute a default DLL load address is not exactly bullet proof, not even with such a big address space we have now available for DLLs. It still requires to run rebase to be on the safe side. However, I just found a problem in the 64 distro which results in not running autorebase as part of an update. This should be fixed soon. For the time being, stop all Cygwin processes, start a naked dash and run /usr/bin/rebaseall. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgtxCMdOGcU.pgp Description: PGP signature
Re: 64-bit emacs crashes a lot
On 16/08/2013 5:13 AM, Eli Zaretskii wrote: Date: Fri, 16 Aug 2013 01:59:41 -0400 From: Ryan Johnson <**snip**> Please don't feed the spammers. I get enough as it is... -- 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: emacs-w32 (64bit) displays generic tray icon
On 8/16/2013 3:40 AM, Shaddy Baddah wrote: When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. I fixed this before the release of emacs-24.3-4. Are you running an older version? Ken -- 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: GNU ld -O option breaks compilation
On 16 August 2013 12:48, Corinna Vinschen wrote:
> On Aug 16 10:50, Václav Zeman wrote:
>> I am getting compilation error when I try to use the GNU ld's -O option:
>>
>> `--> cat test.c
>> int
>> main ()
>> {
>> return 0;
>> }
>>
>> `--> gcc -Wl,-O -o test test.c
>> /usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../lib/libcygwin.a(libcmain.o):
>> In function `main':
>> /usr/src/debug/cygwin-1.7.24-1/winsup/cygwin/lib/libcmain.c:39:
>> undefined reference to `WinMain'
>> /usr/src/debug/cygwin-1.7.24-1/winsup/cygwin/lib/libcmain.c:39:(.text.startup+0x7e):
>> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
>> `WinMain'
>> collect2: error: ld returned 1 exit status
>
> Per the ld info pages, the -O option is only designed to work for
> ELF shared libraries so far.
Ok. I have expected it to do nothing (no optimization) on non-ELF targets.
--
VZ
--
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: emacs-w32 (64bit) displays generic tray icon
Hi Ken, On 16 Aug 2013 22:14+1000, Ken Brown wrote: On 8/16/2013 3:40 AM, Shaddy Baddah wrote: When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. I fixed this before the release of emacs-24.3-4. Are you running an older version? Definitely installed all latest packages. $ cygcheck -cd | grep emacs emacs 24.3-3 emacs-w32 24.3-3 emacs-X11 24.3-3 One thing to note, in case it might explain things. I install under a separate user to the one that I run Cygwin apps under. Running under my personal user I will not have permissions to write to /usr, /etc, etc... (pardon thepun). Unless I explicitly elevate my privilege, which I avoid unless necessary. I mention only in that if a file somehow managed not to be world readable then running under my user I may not be able to read it. And the off chance that the icon is obtained from such a file. -- Regards, Shaddy -- 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: emacs-w32 (64bit) displays generic tray icon
Hi Ken, On 16 Aug 2013 22:14+1000, Ken Brown wrote: On 8/16/2013 3:40 AM, Shaddy Baddah wrote: When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. I fixed this before the release of emacs-24.3-4. Are you running an older version? Definitely installed all latest packages. $ cygcheck -cd | grep emacs emacs 24.3-3 emacs-w32 24.3-3 emacs-X11 24.3-3 One thing to note, in case it might explain things. I install under a separate user to the one that I run Cygwin apps under. Running under my personal user I will not have permissions to write to /usr, /etc, etc... (pardon thepun). Unless I explicitly elevate my privilege, which I avoid unless necessary. I mention only in that if a file somehow managed not to be world readable then running under my user I may not be able to read it. And the off chance that the icon is obtained from such a file. -- Regards, Shaddy -- 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: emacs-w32 (64bit) displays generic tray icon
Hi Ken, On 16 Aug 2013 22:39+1000, Shaddy Baddah wrote: On 16 Aug 2013 22:14+1000, Ken Brown wrote: On 8/16/2013 3:40 AM, Shaddy Baddah wrote: When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. I fixed this before the release of emacs-24.3-4. Are you running an older version? Definitely installed all latest packages. $ cygcheck -cd | grep emacs emacs 24.3-3 emacs-w32 24.3-3 emacs-X11 24.3-3 Oops I just noticed the build number. I am not running the latest. I'll have to try again against my current mirror and if I don't get the latest, I'll have to place it in the "do not trust" list. Unfortunately that'll be two out of two here in Australia :-( -- Regards, Shaddy -- 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: emacs-w32 (64bit) displays generic tray icon
Hi again, On 16 Aug 2013 22:46+1000, Shaddy Baddah wrote: On 16 Aug 2013 22:39+1000, Shaddy Baddah wrote: On 16 Aug 2013 22:14+1000, Ken Brown wrote: On 8/16/2013 3:40 AM, Shaddy Baddah wrote: When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. I fixed this before the release of emacs-24.3-4. Are you running an older version? Definitely installed all latest packages. $ cygcheck -cd | grep emacs emacs 24.3-3 emacs-w32 24.3-3 emacs-X11 24.3-3 Oops I just noticed the build number. I am not running the latest. I'll have to try again against my current mirror and if I don't get the latest, I'll have to place it in the "do not trust" list. Unfortunately that'll be two out of two here in Australia :-( OK. It seems my mirror can be trusted. It seems setup cannot be trusted. That's a little unfair actually. More that... something I assumed about setup, but also based on the assumption thought would one day cause issue is the following. When you do a "Download Only", how does setup decide what the current version of your packages are? And if it finds an update path, will it automatically select the package for update? My understanding is it does look at your installation root, and will select existing packages for upgrade. However, as per http://cygwin.com/ml/cygwin-apps/2013-06/msg00042.html I wonder how it select the right installation root when there are multiple installs. I don't have multiple installs of 64 bit at the moment, but I do have a concurrent 32 bit. And in general, if I am right in saying it peeks into the targeted installation root for an existing "selection" of packages, there is no mechanism to point it at the right one when more than one exists. Anyway, this is turning into a discussion on setup. I'll take it to cygwin-apps if it is more appropriate. Actually, I will take it there as I have further comments. In this case, setup did not think emacs was installed. So left it for me to decide if I wanted it selected for install. I didn't notice. And this must be true for a number of packages. After manual selection and upgrade of emacs-w32 I can confirm the problem is resolved. (Also resolved issue for curl reported in http://cygwin.com/ml/cygwin/2013-08/msg00271.html. But I'll report back there). -- Regards, Shaddy -- Regards, Shaddy -- 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: emacs-w32 (64bit) displays generic tray icon
On 8/16/2013 8:46 AM, Shaddy Baddah wrote: Hi Ken, On 16 Aug 2013 22:39+1000, Shaddy Baddah wrote: On 16 Aug 2013 22:14+1000, Ken Brown wrote: On 8/16/2013 3:40 AM, Shaddy Baddah wrote: When I run emacs-w32, I do not see the emacs tray icon as I did with 32bit Cygwin. Instead I see the generic "Windows Program" icon. I can take a screenshot of that if required. I fixed this before the release of emacs-24.3-4. Are you running an older version? Definitely installed all latest packages. $ cygcheck -cd | grep emacs emacs 24.3-3 emacs-w32 24.3-3 emacs-X11 24.3-3 Oops I just noticed the build number. I am not running the latest. I'll have to try again against my current mirror and if I don't get the latest, I'll have to place it in the "do not trust" list. Unfortunately that'll be two out of two here in Australia :-( Your mirror must be *very* far behind. I released 24.3-4 on July 5. The current 64-bit release is 24.3-6. Ken -- 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: curl on 64bit always includes headers
Hi Corinna, On 16 Aug 2013 20:46+1000, Corinna Vinschen wrote: On Aug 16 18:39, Shaddy Baddah wrote: I think this is some sort of regression best demonstrated with copy/paste: Any chance you have a .curlrc file with an "include" line? Sorry for the noise. As per http://cygwin.com/ml/cygwin/2013-08/msg00286.html due to a misunderstanding on my part of how setup works, I thought that being offered no update for curl or other packages meant there were no updates. I will discuss the aspects of setup behaviour separately in cygwin-apps. Updating curl manually has corrected the behaviour. -- Regards, Shaddy -- 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: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
On 8/16/2013 4:17 AM, Corinna Vinschen wrote: I assume the format of the git database files depends on the architecture. Therefore it's probably not advisable to use a git repo created under 32 bit git with a 64 b Oh, wow. That's...awkward. I'm sharing the same drive area mounted in both cyg32 and cyg64 for my builds, and repo'ing the cygport & related files using git. So far I always have done the git manipulations in cyg32...guess I need to make sure I continue to do it that way! (I could always "clone" the repo(s) to a new area on cyg64, but I would probably have to use one of the wire protocols and not the file system protocol to do it). -- 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: shell-init: error retrieving current directory
On Aug 16 12:00, Andy Koppe wrote: > This might be the same issue as a couple of previous unresolved > reports with the same error message, but I'm not sure, so here's a new > thread. > > Steps to reproduce: > - On Windows 7, install 64-bit Cygwin into C:\cygwin, and let it > create a desktop shortcut. > - Edit /etc/fstab to change the cygdrive prefix to /. > - Double click 'Cygwin64 Terminal' desktop shortcut. > > Result: a bunch of errors before the bash prompt. > > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Bad file descriptor > job-working-directory: error retrieving current directory: getcwd: > cannot access parent directories: No such file or directory > job-working-directory: error retrieving current directory: getcwd: > cannot access parent directories: No such file or directory > job-working-directory: error retrieving current directory: getcwd: > cannot access parent directories: No such file or directory > chdir: error retrieving current directory: getcwd: cannot access > parent directories: No error > > The errors remain if the shortcut target is changed from invoking > mintty to invoking bash directly: 'C:\cygwin\bin\bash.exe -l'. > > The errors go away if 'C:\cygwin\bin' is put into the shortcut's > otherwise empty 'Start In' field. (But they stay if 'C:\' is put there > instead.) > > They also go away if the cygdrive prefix is changed to anything but > the root directory. > > I couldn't reproduce the issue with a 32-bit install. I tried to find the cause for this issue, but as far as I can tell, it's not a problem in Cygwin. For some reason bash seems to implement its own getcwd function, which plays a lot with calling stat on ., .., ../.., etc. All results from stat seem to make sense. The error code itself (Bad file descriptor, etc) doesn't matter. It's just some arbitrary value errno is set to at the time bash decides it doesn't like what the system calls return. By tweaking the internal function which implements the core of the system getcwd function, I could return any error value at will. Eric, can you please have a look into this issue? Something's weird with bash's getcwd implementation which is apparently only triggered in the 64 bit version. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpVB6wUwClsS.pgp Description: PGP signature
Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
On Aug 16 09:21, Charles Wilson wrote: > On 8/16/2013 4:17 AM, Corinna Vinschen wrote: > >I assume the format of the git database files depends on the > >architecture. Therefore it's probably not advisable to use > >a git repo created under 32 bit git with a 64 b > > Oh, wow. That's...awkward. I'm sharing the same drive area mounted > in both cyg32 and cyg64 for my builds, and repo'ing the cygport & > related files using git. So far I always have done the git > manipulations in cyg32...guess I need to make sure I continue to do > it that way! > > (I could always "clone" the repo(s) to a new area on cyg64, but I > would probably have to use one of the wire protocols and not the > file system protocol to do it). This is just an assumption. I don't know if the format is really different, but the symmetry of the effect *is* weird. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvFyk9WkQ_y.pgp Description: PGP signature
Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
On 16 August 2013 21:49, Corinna Vinschen wrote: > > This is just an assumption. I don't know if the format is really > different, but the symmetry of the effect *is* weird. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat Further testing indicates that it *is* ok to git clone, directly on the local NTFS, a repository created in Cygwin 32-bit from Cygwin 64-bit and git wouldn't be confused about the filename case. -- 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: Octave 3.6.4 cannot plot in X server
Sorry that I do not know how to reply to a specific follow-up email since I subscribed to the digest version of this mailing list. And to Corinna: dash - usr/bin/rebaseall worked! Thank you so much for your help. Looking forward to the next update! To Larry: Thanks a lot for the help! -Shawn -- Forwarded message -- From: Corinna Vinschen To: cygwin at cygwin dot com Cc: Date: Fri, 16 Aug 2013 13:14:16 +0200 Subject: Re: Octave 3.6.4 cannot plot in X server On Aug 15 23:37, Larry Hall (Cygwin) wrote: > On 8/15/2013 8:38 PM, Yuxiang Wang wrote: > >Dear all, > > > >I have installed Octave with Cygwin 64-bit, under Win 7. Besides > >octave-3.6.4-1, I also installed xinit and xlaunch according to the > >doc, and gnuplot just in case. > > > >However, when I start X terminal, open octave (that all went > >successfully) and enter plot(1:5), I got the following message: > > > >octave:1> plot(1:5) > > 0 [main] octave-3.6.4 2708 child_info_fork::abort: > >C:\cygwin64\bin\cygoctave-1.dll: Loaded to different address: > >parent(0xF0) != ch > >error: popen2: process creation failed -- Resource temporarily unavailable > >error: called from: > >error: /usr/share/octave/3.6.4/m/plot/private/__gnuplot_open_stream__.m > >at line 30, column 44 > >error: /usr/share/octave/3.6.4/m/plot/__gnuplot_drawnow__.m at line > >72, column 19 > > > >Would anyone please help me with this? > > In 64-bit land, the available address space for Cygwin DLLs is much > increased. This should theoretically eliminate the "casual" overlap > of address spaces for loaded DLLs, which was a common fork failure vector > in 32-bit land. Not exactly eliminated, but drastically reduced. The problem is, the hash algorithm used by ld to compute a default DLL load address is not exactly bullet proof, not even with such a big address space we have now available for DLLs. It still requires to run rebase to be on the safe side. However, I just found a problem in the 64 distro which results in not running autorebase as part of an update. This should be fixed soon. For the time being, stop all Cygwin processes, start a naked dash and run /usr/bin/rebaseall. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat On Thu, Aug 15, 2013 at 8:37 PM, Yuxiang Wang wrote: > Dear all, > > I have installed Octave with Cygwin 64-bit, under Win 7. Besides > octave-3.6.4-1, I also installed xinit and xlaunch according to the doc, and > gnuplot just in case. > > However, when I start Xterminal, open octave (that all went successfully) > and enter plot(1:5), I got the following message: > > octave:1> plot(1:5) > 0 [main] octave-3.6.4 2708 child_info_fork::abort: > C:\cygwin64\bin\cygoctave-1.dll: Loaded to different address: > parent(0xF0) != ch > error: popen2: process creation failed -- Resource temporarily unavailable > error: called from: > error: /usr/share/octave/3.6.4/m/plot/private/__gnuplot_open_stream__.m at > line 30, column 44 > error: /usr/share/octave/3.6.4/m/plot/__gnuplot_drawnow__.m at line 72, > column 19 > > Would anyone please help me with this? > > Thanks so much! > > -Shawn > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: shell-init: error retrieving current directory
Greetings, Andy Koppe! > This might be the same issue as a couple of previous unresolved > reports with the same error message, but I'm not sure, so here's a new > thread. > Steps to reproduce: > - On Windows 7, install 64-bit Cygwin into C:\cygwin, and let it > create a desktop shortcut. > - Edit /etc/fstab to change the cygdrive prefix to /. > - Double click 'Cygwin64 Terminal' desktop shortcut. > Result: a bunch of errors before the bash prompt. > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Bad file descriptor > job-working-directory: error retrieving current directory: getcwd: > cannot access parent directories: No such file or directory > job-working-directory: error retrieving current directory: getcwd: > cannot access parent directories: No such file or directory > job-working-directory: error retrieving current directory: getcwd: > cannot access parent directories: No such file or directory > chdir: error retrieving current directory: getcwd: cannot access > parent directories: No error > The errors remain if the shortcut target is changed from invoking > mintty to invoking bash directly: 'C:\cygwin\bin\bash.exe -l'. > The errors go away if 'C:\cygwin\bin' is put into the shortcut's > otherwise empty 'Start In' field. (But they stay if 'C:\' is put there > instead.) > They also go away if the cygdrive prefix is changed to anything but > the root directory. > I couldn't reproduce the issue with a 32-bit install. Been there, done that. http://sourceware.org/ml/cygwin/2013-06/msg00733.html Unfortunately, the pending new VM setup was cancelled, and I've had no time to get around to test this issue again. -- WBR, Andrey Repin (anrdae...@freemail.ru) 16.08.2013, <21:44> Sorry for my terrible english... -- 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
Stack size on 64-bit Cygwin
The problem that has been discussed at length in the thread "64-bit emacs crashes a lot" appears to have been solved on the emacs-devel list. (I say "appears to" because I'm waiting for Ryan to confirm this.) The problem went away for me when I built emacs with 'LDFLAGS=-Wl,--stack,4194304'. I'm wondering if it's just that emacs needs an unusually big stack or if the default stack size on 64-bit Cygwin should be increased for all applications. I noticed that ulimit -s gives 2025 on both 32-bit Cygwin and 64-bit Cygwin. Shouldn't 64-bit applications need a larger stack than 32-bit applications in general? Ken -- 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: Stack size on 64-bit Cygwin
On 16/08/2013 4:49 PM, Ken Brown wrote: The problem that has been discussed at length in the thread "64-bit emacs crashes a lot" appears to have been solved on the emacs-devel list. (I say "appears to" because I'm waiting for Ryan to confirm this.) WJFFM so far (fingers crossed!) The problem went away for me when I built emacs with 'LDFLAGS=-Wl,--stack,4194304'. I'm wondering if it's just that emacs needs an unusually big stack or if the default stack size on 64-bit Cygwin should be increased for all applications. I could easily imagine running into trouble by doubling pointer sizes, if GC calls routinely reach 10k+ stack frames deep like somebody mentioned a couple days ago... Ryan -- 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: Cygwin 1.7.23 / OpenSSH 6.2p2 fails to allocate a pty, because it fails to seteuid on Windows 2008r2
I tried the 32-bit version. I tried older versions of Cygwin (but not
very hard).
I checked the permissions of the cyg_server account with
editrights.exe. They're good. I installed a newer version of mintty.
That failed. I may try it again in case I downloaded the wrong
mintty.
I stopped running /usr/sbin/sshd -dd on the command line and I
adjusted LogLevel in /etc/sshd_config to DEBUG. Then I re-ran the
service and I can see debug output in the Windows Application Log.
The PTY is being generated, but when I run the test ruby script,
mentioned earlier, I still get nothing back -- *usually* -- when I
request a PTY. If I don't request a PTY, then the results of a simple
command (echo hi) come back over the SSH session, as expected, every
single time I run the test script.
Randomly, running my test script and requesting a PTY succeeds. I am
rarely able to reproduce it.
If I switch my testing script to hit a Linux box, and I request a PTY,
it works ok. I see a /dev/pts/2 device get created on the linux box,
mode 0620, and then it disappears. I get the results of the command
back via SSH.
If I switch the testing script to hit Cygwin, I see a /dev/ptyX device
get created in /dev, mode 0622, and it disappears as well. I know
that the pty generation is happening as it should but maybe it's the
wrong permissions?
Screenshot of /dev/pty2 device creation / disappearance follows below:
http://imgur.com/WlLuSiT
Finally, I run this on the cygwin box:
while true ; do cat /dev/ptyX 2> /dev/null ; done
Whenever I run my test script, the pty is created, the contents of the
device end up being "Hangup," and then the results that are passed
back to my SSH client are empty. When I compare on a linux SSH
server, the contents of the device remain clean and -- again -- I get
a "hi" back over the wire.
On Thu, Aug 15, 2013 at 2:59 PM, Greg Swallow wrote:
> Hi,
>
> I am trying to build a Windows 2008r2 base box with Packer, and then
> bootstrap clones of that box using Chef. I'm stumbling on Cygwin and
> OpenSSH.
>
> The automated install procedure, when I run Packer, does this:
>
>
> @echo off
> REM
> http://webcache.googleusercontent.com/search?q=cache:SjoPPpuQxuoJ:www.tcm.phy.cam.ac.uk/~mr349/cygwin_install.html+install+cygwin+ssh+commandline&cd=2&hl=nl&ct=clnk&gl=be&source=www.google.be
>
> cmd /c powershell.exe -command "$webClient = New-Object
> System.Net.WebClient ;
> $webClient.DownloadFile('http://cygwin.com/setup-x86_64.exe',
> $env:TEMP + '/cygwin-setup-x86_64.exe')"
>
> REM goto a temp directory
> cd %TEMP%
>
> REM run the installation
> cmd /c cygwin-setup-x86_64.exe -N -n -q -P openssh,cygrunsrv -s
> http://cygwin.cybermirror.org
>
> REM clear out straggler SSH daemons
> %SystemDrive%\cygwin64\bin\bash -c 'PATH=/usr/local/bin:/usr/bin:/bin
> cygrunsrv -R sshd'
>
> REM not sure this is necessary
> cmd /c %SystemDrive%\cygwin64\bin\bash -c
> 'PATH=/usr/local/bin:/usr/bin:/bin mkgroup
> -l'>%SystemDrive%\cygwin64\etc\group
> cmd /c %SystemDrive%\cygwin64\bin\bash -c
> 'PATH=/usr/local/bin:/usr/bin:/bin mkpasswd
> -l'>%SystemDrive%\cygwin64\etc\passwd
>
> REM set up sshd service
> %SystemDrive%\cygwin64\bin\bash -c 'PATH=/usr/local/bin:/usr/bin:/bin
> /usr/bin/ssh-host-config -y -w "redacted"'
>
> REM configure cyglsa
> REM %SystemDrive%\cygwin64\bin\bash -c
> 'PATH=/usr/local/bin:/usr/bin:/bin /usr/bin/cyglsa-config -y'
>
> REM enable firewall
> cmd /c netsh advfirewall firewall add rule name="SSH" protocol=TCP
> dir=in localport=22 action=allow enable=yes
>
> net start sshd
>
> I test it with this:
>
> 1.#!/usr/bin/env ruby
> 2.
> 3.require 'net/ssh'
> 4.require 'net/ssh/multi'
> 5.
> 6.user_name = "redacted"
> 7.user_pass = "redacted"
> 8.my_ticket = { "servers" => [ "172.16.125.191" ] }
> 9.
> 10.Net::SSH::Multi.start do |session|
> 11.
> 12. # define the servers we want to use
> 13. my_ticket['servers'].each do |session_server|
> 14.session.use session_server, :user => user_name , :password =>
> user_pass
> 15. end
> 16.
> 17. # execute commands on all servers
> 18. session.open_channel do |channel|
> 19.# This fails and is not caught.
> 20.channel.request_pty
> 21.channel.exec 'echo hi' do |chan, success|
> 22. raise ArgumentError, "Cannot execute command" unless success
> 23. # This never happens on Cygwin but it happens on Linux.
> 24. channel.on_data do |ichannel, data|
> 25.raise ArgumentError, "wtf?" if data.nil?
> 26.puts data
> 27. end
> 28. channel.on_extended_data do |ch, type, data|
> 29.puts STDERR "STDERR" + data
> 30. end
> 31. channel.on_request "exit-status" do |ichannel, data|
> 32.puts data.read_long
> 33. end
> 34. end
> 35. end
> 36.
> 37. # run the aggregated event loop
> 38. puts "looping."
> 39. session.loop
> 40.end
>
> When I log in as the "privileged server" account (the cyg_server
> account), and I run:
>
> start -> run -> cmd
> net stop sshd
> c:\cygwin64\bin\bash
Adding a new package to cygwin
Hi guys, I would like to add some statistics tools to cygwin like top, free, sar, etc. I tried to add procps package by downloading it and using the setup program. But obviously I do not do it well because I cannot find it inside the packages list in the setup window (full list state). Can some one give me a step by step procedure to add a new package? 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: Adding a new package to cygwin
On 8/16/2013 7:17 PM, Tal wrote: Hi guys, I would like to add some statistics tools to cygwin like top, free, sar, etc. I tried to add procps package by downloading it and using the setup program. But obviously I do not do it well because I cannot find it inside the packages list in the setup window (full list state). Can some one give me a step by step procedure to add a new package? You haven't stated but I'm going to assume you're installing 64-bit Cygwin. If that's true, then the answer is there is no procps package at this time. If you truly need it, you need to rebuild it yourself from source, wait for someone to build it for you, or install a parallel 32-bit Cygwin. The 32-bit version contains a procps package. -- Larry _ 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
Cygwin Installer In-use file detected
Hello, I am using Cygwin installer 2.819 x86. After installing new packages (and updating existing packages), I sometimes get the message: In-use file detected Unable to extract /usr/bin/cygwin1.dll The file is in use by the following processes: C:\cygwin\bin\mintty.exe C:\cygwin\bin\bash.exe C:\cygwin\bin\XWin.exe Select 'Kill' to kill Cygwin processes and retry, or select 'Continue' to go on anyway (you will need to reboot). I believe there used to be an option "Try again" on the older installers. This was useful because it allowed me to first try to manually close my applications and then try again. While I can still manually do this and then click "Kill Processes", a "try again" option seems like a more graceful approach since if I accidentally didn't close some program (after possibly saving some data), I would be notified, versus having the installer kill that process and possibly lose data. -- 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
