Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On 8 December 2011 00:33, Enrico Forestieri wrote: > Corinna Vinschen writes: >> >> Just so it's clear why I did that, maybe you want to have a look into >> the brief discussion on the cygwin-developers list: >> http://cygwin.com/ml/cygwin-developers/2011-11/msg0.html > > All good reasons, but you are going to break backward compatibility. > At least, lyx is going to be affected. It currently works with unicode > without a glitch That's impossible if it's using Ansi APIs. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Dec 8 00:33, Enrico Forestieri wrote: > Corinna Vinschen writes: > > > > Just so it's clear why I did that, maybe you want to have a look into > > the brief discussion on the cygwin-developers list: > > http://cygwin.com/ml/cygwin-developers/2011-11/msg0.html > > All good reasons, but you are going to break backward compatibility. > At least, lyx is going to be affected. It currently works with unicode > without a glitch, but it will be broken with 1.7.10. Which raises the question why the Cygwin version of lyx uses cygwin_conv_path at all. Does it call Windows functions with the paths? If so, why? If not, why are the paths converted to Windows? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Dec 7 16:47, Lars Bjørndal wrote: > On on., des. 07, 2011 at 01:40:25 +0100, Lars Bjørndal wrote: > > [Corinna] > > > On Dec 7 10:23, Lars Bjørndal wrote: > > > > [Corinna] > > > > [...] > > > > > > > > > Btw., "brltty doesn't work" is a bit low on detail. It would also be > > > > > helpful if you could find out with which snapshot brltty starts to > > > > > misbehave. > > > > > > > > At 20111022. Now, I'm using the dll from 20111021, and it works. > > > > > > Thanks! > > > > > > Are you using Windows 7 by any chance? If so, I have a hunch what the > > > problem is. > > > > Yes - 64bit version. > > > > > Can I send you the URL to a test DLL by private email? > > > > Sure. > > I tried the patch you provided, but with no better result - sorry. Too bad. In that case, Samuel, can you please have a closer look to see what broke brltty? I have not the faintest idea how to test it and how to see if it works or not. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unable to install Cygwin on Windows XP: the actual messages.
Dear colleagues, I will repost the same question I did before, correcting my lack of imagination in working around some restrictions on file attachments. The setup I am using is the 2.761. I downloaded all the packages, including all the suggested dependencies, in advance and made the installation from a local directory. A message appeared recommending to download 'ligjpeg62', and I accepted. The process went OK until this message: ""Unable to extract /usr/share -- the file is in use. Please stop all cygwin processes and select "Retry", or select "Continue" to go on anyway (you will need to reboot)."" This was my very first installation, so I searched my entire system to find only one occurrence of cygwin1.dll, the one in the CalculiX installation, which I was not using during the Cygwin installation. I removed the package and tried again, to the same outcome. Pressing 'retry', the window keeps refreshing continuously. Pressing 'continue' leads to a hang in the process, and canceling it leads to: ""Cannot open log file D:\"Documents and Settings"\CXZH/var/log/setup.log for writing"" The directory ...CXZH... is my home the Windows XP, and I do have write access to it. I believe this is a problem with '\' and '/', but I am not sure and have no idea about how to solve it. Any ideas? Thank you very much in advance. __ Hélio C. Bortolon -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unable to install Cygwin on Windows XP: the actual messages.
On 12/8/2011 11:40 AM, Helio C. Bortolon wrote: Dear colleagues, Pressing 'retry', the window keeps refreshing continuously. Pressing 'continue' leads to a hang in the process, and canceling it leads to: ""Cannot open log file D:\"Documents and Settings"\CXZH/var/log/setup.log for writing"" do not install in a directory with space in the name like "Documents and Settings" Try using the standard D:\cygwin The directory ...CXZH... is my home the Windows XP, and I do have write access to it. I believe this is a problem with '\' and '/', but I am not sure and have no idea about how to solve it. Any ideas? Thank you very much in advance. __ Hélio C. Bortolon Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Hello, I upgrade from snapshot 20110829 to current 20111208 qand I update the tools too. $ uname -a CYGWIN_NT-6.1-WOW64 PCFX167 1.7.10s(0.255/5/3) 20111208 06:50:31 i686 Cygwin I did rebaseall and peflagsall. I got some "Bad address" errors while compiling with make while running shell scripts, cygcheck or compilers. I see the error while running mingw compiler too! c:/programme/cygwin/bin/sh: /cygdrive/c/programme/cygwin/bin/cygcheck: Bad address c:/programme/cygwin/bin/sh: C:/clearcase/xview/pid/pid_V3.7_2011.05.06_019/gnu/4.1.2-vxworks-6.7/x86- win32/bin/ccpentium.exe: Bad address c:/programme/cygwin/bin/sh: ../../tools/buildtools/arb/liters/liters.2_5/liters : Bad address But all errors are not reproduceable at the moment - so I cannot send a testcase. With snapshot 20110829 I only got some "forking errors" - but never "Bad address" erros. Can anyone explain me a little bit in detail the "Bad address". So perhaps I can find a testcase. In older postings I found "Bad errors" - but I think these are all related to older cygwin version 1.7.7 and older. regrads Heiko -- 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: Machine very sluggish while compiling
On 12/4/2011 4:06 AM, Corinna Vinschen wrote: On Dec 4 02:55, Ryan Johnson wrote: On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote: Hello, * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: Lately I've noticed that running make -j4 on my quad-core win7-x64 machine causes it to become sluggish or even unresponsive. I have seen very similar effects on my Win7-64 box. I can force the problem here just be running "ccrypt", though, I do not need to use "make -j4". I assume it has to do with the Windows 64 bit problems of Cygwin (search the ML archives for that). For me, this is the first machine since years where I do not use Cygwin because of this issue. Update: I hit the problem again, this time running python, and the problem is repeatable with the native 64-bit windows python interpreter. It looks like cygwin doesn't cause the problem, but rather my high-cpu tasks tend to run under cygwin. Honestly, I wouldn't expect cygwin to be the cause, given that it's a user space only piece of software! Now what other entity could be the cause, I haven't a clue... process explorer doesn't show anything. Maybe that's because it's frozen along with the rest of the world during these episodes; right as it comes back I see context switch deltas above 100k for the interrupt/DPC module, which suggests I've got a wonky driver somewhere. Here's another observation: Since Friday I'm testing a script which runs in a `while true; do done' loop. Nothing serious, just a bit of environment variable setting, calling find in an empty directory tree, grep, sed, the usual. It's running in mintty on a W7 64 bit machine. When starting to run the script, the CPU load on the dual core machine is about 70%. After a while, let's say an hour, the CPU load is 100%. Task Manager shows that one of the svchost.exe processes is grabing a lot of memory and a lot of CPU. Stop the script and the svchost still takes mem and about 50% CPU time, which means, one of the cores is solely busy to server this svchost process. Exit mintty and this svchost drops to 0% CPU and the memory usage goes down a lot. The svchost in question is the one running the following services: Windows Audio Endpoint Builder Offline Files Network Conections Program Compatibility Assistent Service Superfetch Distributed Link Tracking Client Remote Desktop Service UserMode Port Redirector Desktop Windows Manager Session Manager WLAN AutoConfig Windows Driver Foundation - User-mode Driver Framework After some testing it turned out that the culprit is the "Program Compatibility Assistent Service" service. If I stop this service, the svchost in question behaves harmless. Superfetch is no saint either in terms of memory usage, but it has by far not the influence and sticks to about 3% CPU usage after the PCA service has been stopped. Another way to fix this problem is to run the script in a Windows console window, so it's something to do with mintty. I have not the faintest idea why the PCA service thinks it has to "help" mintty along. I'm starting it from a desktop shortcut which has no compatibility mode set. Anyway, stoppping the PCA service and setting its start mode to "Manual" does the trick for me. While I was at it I also disabled Superfetch, which drops the memory usage of this svchost to a fraction of what it used before, and the CPU usage to 0%, and I don't see any performance difference. Corinna Are you aware that the Superfetch service deliberately tries to use most of the memory not otherwise in use as a cache for the most frequently accessed disk files, in order to speed up accesses to those files? I've found it rather slow to release this cache memory when some other program needs it, though. Robert Miles -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Corinna Vinschen writes: > > Which raises the question why the Cygwin version of lyx uses > cygwin_conv_path at all. Does it call Windows functions with the paths? > If so, why? If not, why are the paths converted to Windows? Because the user *could* enter Windows paths (e.g., for including images) or a document created with a native Windows version could be opened with the Cygwin version. The Cygwin version of lyx works internally with posix paths, which are to be converted from the native Windows form. Then, there is a case where the posix->windows conversion is needed. Indeed, lyx allows to use either a Cygwin or native-Windows TeX engine. There is a configuration check for this case. If a native-Windows TeX engine is detected, all paths going to latex files should be converted to Windows, otherwise the TeX engine would not understand them. This is symmetric, i.e., if you compile a native Windows version of lyx and use a Cygwin TeX engine, all paths going to latex files gets converted to posix form. But this case is not of interest here, of course. However, I experimented a bit with the last snapshot, and even using Greek or Japanese characters in file names, lyx seems to be working fine. In part, this may be due to the fact that, for compiling a latex file, all needed ancillary files are copied to a temporary directory with their names mangled such that only pure ascii characters are used. Anyway, when converting from/to Windows, lyx assumes that cygwin_conv_path does not play tricks with the encoding. It was so until now. If this changes, I think it is bound to fail in some way. -- Enrico -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
rt sshd. (/var/log/sshd.log contains the same "PRNG is not seeded" error message.) Sigh. I screwed up select() so the test is suspect. No problem. I redid the test: $ uname -a CYGWIN_NT-6.1-WOW64 fiona 1.7.10s(0.255/5/3) 20111208 06:50:31 i686 Cygwin $ cat ~kbrown-admin/*.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610CD801 eax=010C ebx=0028C880 ecx= edx=0028C95C esi= edi=0028C860 ebp=0028C7C8 esp=0028C7A0 program=C:\cygwin\bin\mintty.exe, pid 6532, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0028C7C8 610CD801 (010C, 0028C95C, 0028C880, 0028C860) 0028C938 610CDB76 (0002, 0028C95C, , ) 20052208 610D1F25 (00630072, , 0018, 0033) 20052590 (6E776F72, 6D64612D, 2E2F6E69, 746E696D) End of stack trace The strace output is still at http://www.math.cornell.edu/~kbrown/cygwin/strace_20111208_snap.out -- 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: Machine very sluggish while compiling
On 08/12/2011 6:18 AM, Robert Miles wrote: On 12/4/2011 4:06 AM, Corinna Vinschen wrote: Anyway, stoppping the PCA service and setting its start mode to "Manual" does the trick for me. While I was at it I also disabled Superfetch, which drops the memory usage of this svchost to a fraction of what it used before, and the CPU usage to 0%, and I don't see any performance difference. Are you aware that the Superfetch service deliberately tries to use most of the memory not otherwise in use as a cache for the most frequently accessed disk files, in order to speed up accesses to those files? I've found it rather slow to release this cache memory when some other program needs it, though. In my experience Superfetch does a phenomenally bad job of predicting which files I (or my wife) actually plan to use. The machine is sluggish not (just) because the memory is uselessly tied up, but because the disk is constantly busy fetching data that will never be used and penalizes access to the data I actually do need. The memory wastage just compounds the problem by contributing additional swapping on top of all this other extra disk activity. Both computers at my house saw *significant increases* in performance and responsiveness when I disabled Superfetch a few months 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: Unable to install Cygwin on Windows XP: the actual messages.
marco atzeri gmail.com> writes: > > On 12/8/2011 11:40 AM, Helio C. Bortolon wrote: > > Dear colleagues, > > > > > > Pressing 'retry', the window keeps refreshing continuously. Pressing > > 'continue' leads to a hang in the process, and canceling it leads to: > > > > ""Cannot open log file D:\"Documents and > > Settings"\CXZH/var/log/setup.log for writing"" > > > > do not install in a directory with space in the name like > "Documents and Settings" > > Try using the standard > D:\cygwin > ... > > Regards > Marco > > Wonderful! It worked fine. I had to find another point to install, but everything is going on now. There was a message complaining about the spaces in the very beginning, but the process seemed to disregard it. I got fooled. I hope I will get the X working by this week, after this I will no more use Windows ports of Linux apps. Thank you very much. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Enrico Forestieri writes: > > However, I experimented a bit with the last snapshot, and even using Greek > or Japanese characters in file names, lyx seems to be working fine. Sorry, it was a cursory test. Actually, cygwin_conv_path is only called for absolute paths. Using an absolute Windows path containing any nonascii character, makes lyx fail miserably. I know this is a no-no for you (even if absolute Windows paths can sneak in by opening a document created by a Windows version), so I will not insist, but knowlingly breaking backward compatibility is not nice. -- Enrico -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Andy Koppe writes:
>
> On 8 December 2011 00:33, Enrico Forestieri wrote:
> > Corinna Vinschen writes:
> >>
> >> Just so it's clear why I did that, maybe you want to have a look into
> >> the brief discussion on the cygwin-developers list:
> >> http://cygwin.com/ml/cygwin-developers/2011-11/msg0.html
> >
> > All good reasons, but you are going to break backward compatibility.
> > At least, lyx is going to be affected. It currently works with unicode
> > without a glitch
>
> That's impossible if it's using Ansi APIs.
That is not the issue. No Windows API is directly used, but there is the
need to convert from posix to Windows paths when the TeX engine is native
Windows. The assumption that cygwin_conv_path does not change the encoding
is made (this is so until 1.7.9) and if this is going to change it will cause
havoc. Indeed, the path should be written to the latex file according to the
encoding used (e.g., \usepackage[cp852]{inputenc}), and lyx takes care of the
needed conversion. But, if the encoding is changed by cygwin_conv_path ...
--
Enrico
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On 12/8/2011 9:48 AM, Enrico Forestieri wrote:
Andy Koppe writes:
On 8 December 2011 00:33, Enrico Forestieri wrote:
Corinna Vinschen writes:
Just so it's clear why I did that, maybe you want to have a look into
the brief discussion on the cygwin-developers list:
http://cygwin.com/ml/cygwin-developers/2011-11/msg0.html
All good reasons, but you are going to break backward compatibility.
At least, lyx is going to be affected. It currently works with unicode
without a glitch
That's impossible if it's using Ansi APIs.
That is not the issue. No Windows API is directly used, but there is the
need to convert from posix to Windows paths when the TeX engine is native
Windows. The assumption that cygwin_conv_path does not change the encoding
is made (this is so until 1.7.9) and if this is going to change it will cause
havoc. Indeed, the path should be written to the latex file according to the
encoding used (e.g., \usepackage[cp852]{inputenc}), and lyx takes care of the
needed conversion. But, if the encoding is changed by cygwin_conv_path ...
I don't use lyx (though I use tex extensively), so maybe there's
something I don't understand. But is it really necessary for Cygwin's
lyx to support a native Windows tex? Wouldn't it be more reasonable for
users of a native Windows tex to use a native Windows lyx?
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
make with g++
Alright so I'm a complete newbie when it comes to anything linux related. And so I cannot figure out how make is supposed to work under cygwin, even creating the simplest makefile produces "Error: 'g++' not found" Which doesn't make much sense to me, given that I can run g++ from the cygwin command line just fine.. Here is one of the many makefiles I've tried.. all: g++ main.cpp -o test .PHONY: all Which produces the above error.. So are all the tutorials wrong online, or does my make just not work correctly? Thanks -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Ken Brown writes: > > I don't use lyx (though I use tex extensively), so maybe there's > something I don't understand. But is it really necessary for Cygwin's > lyx to support a native Windows tex? Necessary? No. Useful? Yes. > Wouldn't it be more reasonable for > users of a native Windows tex to use a native Windows lyx? Until recently, the only Cygwin TeX engine was teTeX, which does not support XeTeX. If you wanted a Cygwin version of lyx, you could not have used XeTeX, unless you used MikTeX, for example. -- Enrico -- 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: make with g++
Hi, On Thu, Dec 8, 2011 at 4:34 PM, Fitzy wrote: > Alright so I'm a complete newbie when it comes to anything linux related. > > And so I cannot figure out how make is supposed to work under cygwin, > even creating the simplest makefile produces > > "Error: 'g++' not found" Did you actually run make? Was this the *exact message* you received? This is the error I get when I try to run a bogus program from make: make: g+++: Command not found Note that the makefile fragment you provided looks suspicious: it appears to contain seven spaces as the indentation of the g++ line, although I suspect it might have been mangled by gmail, otherwise you would have gotten a different error message from make. > > Which doesn't make much sense to me, given that I can run g++ from > the cygwin command line just fine.. (snip) > So are all the tutorials wrong online, or does my make just not work > correctly? It's more likely that you made a mistake somewhere or your Cygwin environment is not set up correctly. To help us diagnose the latter, please follow: > Problem reports: http://cygwin.com/problems.html , especially http://www.cygwin.com/problems.html#cygcheck This will help us to understand what your Cygwin environment contains and how it's set up. Just for curiosity, try changing your makefile to the following and running make: all: which g++ g++ main.cpp -o test Hope this helps, Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
With the DLL from 20111208, a bug seems to have returned: Wildcard match fail from a windows shell with non-ASCII characters http://cygwin.com/ml/cygwin/2009-12/msg01079.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: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On 12/8/2011 10:56 AM, Enrico Forestieri wrote: Ken Brown writes: I don't use lyx (though I use tex extensively), so maybe there's something I don't understand. But is it really necessary for Cygwin's lyx to support a native Windows tex? Necessary? No. Useful? Yes. Wouldn't it be more reasonable for users of a native Windows tex to use a native Windows lyx? Until recently, the only Cygwin TeX engine was teTeX, which does not support XeTeX. If you wanted a Cygwin version of lyx, you could not have used XeTeX, unless you used MikTeX, for example. That changed a couple of years ago. TeX Live has supported Cygwin since TL2009. 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: make with g++
>Just for curiosity, try changing your makefile to the following and >running make: >all: which g++ g++ main.cpp -o test >Hope this helps, >Csaba Hi Csaba, When I run that it shows this in the cygwin console: $ make which g++ /user/bin/g++ It doesn't run g++ though, not sure if it was supposed to.. When I run the original make that I posted it shows this: $ make g++ main.cpp -o test Error: 'g++' not found I do have cygwin installed twice, the first one somehow lost track of g++(it was working and then it couldn't find g++ one day) so I installed it again(in a different location since the updater didn't seem keen on overwriting), perhaps make from my second cygwin is somehow getting confused by this? -- 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 slow on x64 systems?
Tim McDaniel: BLODA is the Big List Of Dodgy Apps, apparently from http://cygwin.com/faq/faq.using.html#faq.using.bloda 44. What applications have been found to interfere with Cygwin? In case anyone cares about the details of my datum, and in case anyone ever searches for the exact system in the archives: It lists "Norton/McAfee/Symantec antivirus or antispyware". In my case, the exact installable is called Symantec Endpoint Protection. "Integrated antivirus, antispyware, firewall, and intrusion prevention as well as device control and application control" and "Powerful central management of security", so it's antivirus and antispyware and more. Before uninstalling Symantec Endpoint Protection (note: no Superfetch, and Program Compatibility Assistant disabled in gpedit policy edit, but the PCA Service running): $ time echo hi | read x real0m1.928s user0m0.031s sys 0m0.031s After uninstalling Symantec Endpoint Protection (no changes to Superfetch or PCA Service): $ time echo hi | read x real0m0.093s user0m0.000s sys 0m0.061s Unfortunately, now I'm required to reinstall. -- Tim McDaniel, t...@panix.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Ken Brown writes: > > On 12/8/2011 10:56 AM, Enrico Forestieri wrote: [...] > > Until recently, the only Cygwin TeX engine was teTeX, which does not > > support XeTeX. If you wanted a Cygwin version of lyx, you could not > > have used XeTeX, unless you used MikTeX, for example. > > That changed a couple of years ago. TeX Live has supported Cygwin since > TL2009. What I meant to say is that there was a reason to support a native TeX engine. -- Enrico -- 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 slow on x64 systems?
On Thu, Dec 8, 2011 at 11:46 AM, Tim McDaniel wrote: > After uninstalling Symantec Endpoint Protection (no changes to > Superfetch or PCA Service): > > $ time echo hi | read x > > real 0m0.093s > user 0m0.000s > sys 0m0.061s > > Unfortunately, now I'm required to reinstall. Any chance they will allow you to add a "User defined exception" (in Centralized Exceptions) to exclude your cygwin folder? That works for me. Marco Moreno -- 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 slow on x64 systems?
On Thu, 8 Dec 2011, Marco Moreno wrote: On Thu, Dec 8, 2011 at 11:46 AM, Tim McDaniel wrote: (You quoted my e-mail address there, which may get you dinged by the admins, but I'm cool with my e-mail addy going out -- I put it in my sig and all.) After uninstalling Symantec Endpoint Protection (no changes to Superfetch or PCA Service): $ time echo hi | read x real 0m0.093s user 0m0.000s sys 0m0.061s Unfortunately, now I'm required to reinstall. Any chance they will allow you to add a "User defined exception" (in Centralized Exceptions) to exclude your cygwin folder? That works for me. After reinstalling: $ time echo hi | read x real0m0.094s user0m0.015s sys 0m0.046s WHOHOO! Now the X server won't start ... -- Tim McDaniel, t...@panix.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote: >With the DLL from 20111208, a bug seems to have returned: > >Wildcard match fail from a windows shell with non-ASCII characters > >http://cygwin.com/ml/cygwin/2009-12/msg01079.html PLEASE be precise when reporting problems. Returned from where? 1.7.9? A snapshot from a week ago? A snapshot from a day ago? cgf -- 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
Starting Z-shell via telnet connection to XP box
While I can use remote desktop to get from my Solaris server to the XP box, doing so while at some place other than the LAN, the DSL connection speed tends to cause the RD to fail and close. And since I don't really need a graphical connection, I figured that I would just start the XP Pro telnet server and connect that way. Ya, well, not so good there either. I want to be able to start zsh from the telnet session so that I have full access to the cygwin stuff, specifically being able to change crontab. But, when I enter "zsh" nothing happens. I do not get a Z-shell prompt based upon my Z-shell config files. Instead the telnet session hangs. I have to so a ^] and quit the telnet session. Can the cygwin tools be accessed via a telnet connection and if so how? Thanks. MB -- e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ | http://vidiot.net/ / \ HTML 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
Re: CALL FOR TESTING: Cygwin 1.7.10
I'm having problems with cpan/perl run in an xterm. I searched the recent list archives for cpan/perl but found nothing. Running Windows XP SP3 and this snapshot: CYGWIN_NT-5.1 LTDENA-REISERT 1.7.10s(0.255/5/3) 20111208 06:50:31 i686 Cygwin This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int It's pretty easy to reproduce, in an xterm (Cygwin-X): 1. start cpan 2. install a package 3. when cpan returns to a prompt, start typing another command. The X window will ultimately hang (hourglass) Clicking on the red X in the upper-right of the X terminal kills the xterm (and Xwin) but the perl process is still running. I even killed only the perl process, and the xterm was still hung. I tried the same in mintty and there was no hang. The problem gets stranger: I ran rebaseall, re-started the X server then created a new xterm. I ran cpan, but didn't have the package name to cut/paste, so typed quit. I changed to the directory with my Perl program. I typed: perl -v by mistake. Then when I tried to recall the last command to edit it (up-arrow), the xterm hung. Perl wasn't even running. I have the .dll and .dbg for this cygwin1 version, how can we go about debugging the problem? -- Jim Reisert AD1C, , http://www.ad1c.us -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Christopher Faylor wrote: >On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote: >>With the DLL from 20111208, a bug seems to have returned: >> >>Wildcard match fail from a windows shell with non-ASCII characters >> >>http://cygwin.com/ml/cygwin/2009-12/msg01079.html > >PLEASE be precise when reporting problems. Returned from where? >1.7.9? A snapshot from a week ago? A snapshot from a day ago? >From the time I reported the bug in the link. This bug behaves identically. Should I describe it again or can you click the link? -- 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
dll search path
How do I influence the run-time search path for dlls? I tried
LD_LIBRARY_PATH, and PATH, with no success.
I've build a binary against the build directory of a library, which leaves
the library in ${SRC}/.libs (a libtool convention, I believe), by passing in
-L${SRC}/.libs. The link went ok, but when I run it reports "error while
loading shared libraries: foo.dll: cannot open shared object file: No such
file or directory".
I also note that ldd doesn't behave as I'd hoped. It lists ntdll, kernel32,
and KERNELBASE, but not the library I've linked against. How do I get the
list of libraries I've linked against?
Could the "No such file" error be due to a transitive dependency?
--
View this message in context:
http://old.nabble.com/dll-search-path-tp32937705p32937705.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: Confusion with ACLs and Perl's file tests...maybe bug???
Thanks for the nice testcase. I'll try to take it upstream. But I'm not too confident that p5p will fix it, e.g. they refused to fix File::Copy::cp, keeping the perms as with /bin/cp for several years. I could recently fix the cygwin write check if you had admin rights though. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Thu, Dec 08, 2011 at 11:00:11PM +0100, Bengt Larsson wrote: >Christopher Faylor wrote: >>On Thu, Dec 08, 2011 at 05:06:21PM +0100, Bengt Larsson wrote: >>>With the DLL from 20111208, a bug seems to have returned: >>> >>>Wildcard match fail from a windows shell with non-ASCII characters >>> >>>http://cygwin.com/ml/cygwin/2009-12/msg01079.html >> >>PLEASE be precise when reporting problems. Returned from where? >>1.7.9? A snapshot from a week ago? A snapshot from a day ago? > >From the time I reported the bug in the link. This bug behaves >identically. Should I describe it again or can you click the link? Your use of "seem to have returned" implies that the problem went away at some point. Since the above link is from a time when the problem was extant it isn't really useful to point at it. Again, what would be useful is some hint of when you think the problem went away. Again, if you are reporting that it worked in 1.7.9 but stopped working in a snapshot then that is something useful to know. If you are just saying that you reported a bug two years ago and you notice that the bug is still there, that is not something that we urgently need to fix in 1.7.10 since it isn't a regression. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On 12/7/2011 8:56 AM, marco atzeri wrote: For the spinning problem I put the test case here: http://matzeri.altervista.org/works/test_case/prova2.tar.bz2 running ./system_test.sh some of the tests should dump and return. ++ ./xprobe_3dnow.exe ./system_test.sh: line 14: 3256 Illegal instruction (core dumped) ./xprobe_3dnow.exe on 2024 that works, while from 2029 to 20111207 the programs never return and stay frozen. At least on my CYGWIN_NT-6.1-WOW64 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz stepping: 5 cpu MHz : 2394 cache size : 256 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm TLB size: 0 4K pages clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: The issue is still present from 2029 to current CVS (fith select). Any clue ? I also noticed on another program that on crashing it frozes instead of return. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Wed, 2011-12-07 at 12:18 +0100, Corinna Vinschen wrote: > On Dec 7 04:33, Yaakov (Cygwin/X) wrote: > > On Tue, 2011-12-06 at 22:08 -0500, Christopher Faylor wrote: > > > On Tue, Dec 06, 2011 at 06:45:35PM +0100, Corinna Vinschen wrote: > > > >On Dec 6 15:39, marco atzeri wrote: > > > >> On 12/6/2011 10:37 AM, Corinna Vinschen wrote: > > > >> >A lot of changes and fixes have been made in Cygwin since 1.7.9 has > > > >> >been released, so we're looking forward to release Cygwin 1.7.10 soon. > > > >> >[...] > > > >> > > > >> Hi Corinna, > > > >> I have the impression that 2024 is working better than 2029, > > > >> and that 20111204 and 05 have some additional problems. > > > >> > > > >> On 2029, building atlas on W7/x64 I see the custom config > > > >> spinning and never ending, while on 2024 is goes smooth. > > > > > > > >I can't say a lot about the FIFO stuff, but as far as these weird hangs, > > > >busy or not busy, are concerned, they were one of the problems we > > > >tackled in the last couple of days. > > > > > > The FIFO problem will be fixed in the next snapshot. > > > > Are you sure? I'm now unable to build any KDE4 packages due to a "hang" > > in automoc4[1]. strace attached. > > And it worked with the previous snapshot? I don't see automoc4 using > fifos in the strace. I was referring more to the "weird hangs" above. In any case, automoc4 still doesn't work with CVS HEAD (including tonight's "fifth time's the charm" commit). Yaakov -- 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
