Why does nedit complain about these missing fonts?
I'm using Xming as X server. xlsfonts lists the following fonts as available: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 6x13 cursor fixed In the nedit preferences, I set the primary font to -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 and then clicked on Fill highlight fonts from primary. However, when I invoke Cygwin's 'nedit', I get the error messages: Cannot convert string -*-helvetica-medium-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-helvetica-bold-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-helvetica-medium-o-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-courier-medium-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-courier-bold-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-courier-medium-o-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct I wonder why nedit is searching for helvetica and courier fonts. What's the best to do in this case? Just for completeness (though it likely doesn't matter here): I also searched the Xming documentation. There is a command (mkfontscale) which makes Windows fonts available to X. I have executed it, and it created a file c:\windows\fonts\fonts.dir, which seems to be a mapping between Windows font files (.TTF, .FON) and X font names. I don't know if or to what extend this could help me with the nedit problem; in any case, this list also doesn't contain helvetica or courier. Ronald -- Ronald Fischer rona...@eml.cc + If a packet hits a pocket on a socket on a port, + and the bus is interrupted and the interrupt's not caught, + then the socket packet pocket has an error to report. + (cited after Peter van der Linden) -- 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: no display specified
Do you get the same slowdown when logging in with ssh -Y from a Linux workstation? No. No slowdown when connecting from a linux machine. -- View this message in context: http://old.nabble.com/cygwin-octave-x11-tp33864360p33871359.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: Why does nedit complain about these missing fonts?
On 2012-05-18 07:42, Ronald Fischer wrote: I'm using Xming as X server. This is not a support forum for Xming. Yaakov Cygwin/X -- 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: no display specified
Maybe check to see if different extensions are negotiated on the Linux X server vs CygwinX ? On Fri, May 18, 2012 at 11:54 AM, Chillosaurus ottobo...@gmx.de wrote: Do you get the same slowdown when logging in with ssh -Y from a Linux workstation? No. No slowdown when connecting from a linux machine. -- View this message in context: http://old.nabble.com/cygwin-octave-x11-tp33864360p33871359.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/ -- 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/
Making Unix like paths work when using java program from Cygwin
I am working in a team where everyone else has a Linux/Mac OS X workstation, but I have a windows workstation. Our project uses a shell script and a java program to automate some deployment/setup etc, which needs to create some directories of the sort /ABC/XYZ. Obviously such paths are not valid in Windows. I was hoping if I executed these scripts from within a Cygwin terminal, the problem might be solved (with /ABC/XYZ mapping to C:\cygwin\ABC\XYZ While the issue gets solved for the shell scripts, it does not for the java program. I realize this happens because the Cygwin executes the very same java.exe program which is installed on Windows (even though I selected 'java' related packages for installation while installing Cygwin). Is there a way to get the equivalent of the native javac and java programs one would find on a typical Linux workstation. If not, can I accomplish what I want using the gcc java compiler gjc? (Note: I am a relative newbie to Linux, and a complete newbie to Cygwin... my apologies :) -- View this message in context: http://old.nabble.com/Making-Unix-like-paths-work-when-using-java-program-from-Cygwin-tp33869106p33869106.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: Can't access 'some' SMB network drives from ssh or cron
On 17 May 2012, at 10:00, Gareth Howell wrote: Hi I asked this a day or so ago but got no responses. I'm posting again just in case it just got missed. I have cygwin (latest) running on an XP machine. It needs to access two workstations running Win95 and one running Win98. At the windows level, there are drive maps to the 'C' drives on the three workstations as X:, Y: and Z: and the filesystems can be seen. Cygwin's fstab has lines to mount the same network shares (using UNC paths) under the /mnt directory. The two Win95 shares and the single Win98 share show up just fine as type vfat when I do a 'mount' when running cygwin terminal on the XP machine. If I log in remotely using ssh (as Administrator), the two Win95 shares show up as before, but the Win98 share shows up as type unknown and I can't access the filesystem. The same occurs if a job is run using the Administrator's crontab. I can see it's probably a permissions issue, but I can't get to the bottom of it or understand why the behaviour is different between Win95 and Win98. Any guidance would be welcome. Gareth I've avoided the problem by accessing the three old machines via another proxy at the remote site. This one can see all three workstations OK over SSH. There is a new problem now, but I'll start a new thread for that. Gareth -- 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
'some files vanished' when using rsync over ssh
Hi This is a follow on from the question I asked about accessing SMB filesystems via SSH. The full scenario is that a client is using rsnapshot to back up a load of workstations to a QNAP. The QNAP has rsnapshot installed and most of the Windows targets have cygwin installed. Three very old machines don't have the capability to run cygwin (too little mem and disk space), so I configured another Windows machine to act as a proxy. RSnapshot backs up these machines as extra drives on the proxy, which has them mounted as SMB drives on /mnt When I log in to the proxy using ssh, I can see all three mounted drives. When I run rsync over ssh to the proxy and try to back up the drives I get the error # /opt/bin/rsync -a --delete --numeric-ids --relative --delete-excluded --rsh=/usr/bin/ssh -o BatchMode=yes login@proxy:/mnt/win98/dir . file has vanished: /mnt rsync warning: some files vanished before they could be transferred (code 24) at main.c(1518) [Receiver=3.0.8] According to the literature, this error indicates something changed during the rsync session, but I can't see what. If I ssh into proxy I can see the drives OK $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) //win98/c on /mnt/win98 type vfat (binary,user) //win95/c on /mnt/win95 type vfat (binary,user) //ano/c on /mnt/ano type vfat (binary,user) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type iso9660 (binary,posix=0,user,noumount,auto) I can also rsync them to a local rep whilst logged into the proxy. Gareth -- 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: Making Unix like paths work when using java program from Cygwin
Is there a way to get the equivalent of the native javac and java programs one would find on a typical Linux workstation. If not, can I accomplish what I want using the gcc java compiler gjc? Even if you compile with gjc, you still need the virtual machine, which is as far as I know not available. But you have another option. You can make your Java program OS-independent (as it should be) and run it from the shell script in Cygwin using a usual Java VM for Windows. For that, you need to fix paths in environment variables appropriately (unix-windows) using the cygpath utility before starting java. You can see examples of this in startup scripts of some well-established Java projects like Tomcat, ActiveMQ or JBoss. -- Filipp Gunbin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
Greetings, as I got no response to my first question, I tried two older Cygwin versions to narrow down the problem. Maybe this’ll help someone to figure out the cause. I tried 1.7.9 and 1.7.12-1, with the results of 1.7.12-1 being exactly like the ones from 1.7.14-2 and 1.7.15-1. Unfortunately I couldn’t dig up any versions between 1.7.9 and 1.7.12-1. Results from 1.7.12-1 (for semaphores, detailed results in my last mail): Test 1: Main thread hangs on pthread_cancel() (PTHREAD_CANCEL_DEFERRED) Test 2: Threads ignore pthread_cancel() (PTHREAD_CANCEL_ASYNCHRONOUS) Test 3: Signals often wake the wrong thread Test 4: Wrong thread wakes up once, then nothing Test 5: Some threads exit, depending on whether the signal reached the right thread Test 6: Thread isn't cancelled even after a waking it with a signal On 1.7.9 things are a bit different: Test 1: PTHREAD_CANCEL_DEFERRED semaphore/pause: All threads are cancelled via pthread_cancel() read: No thread is cancelled Test 2: PTHREAD_CANCEL_ASYNCHRONOUS Threads ignore pthread_cancel() Test 3: semaphore/read: No thread wakes up or executes the signal handler, sleep() doesn't sleep any more after the first signal (returns immediately) pause: All threads wake up on every signal, correct thread executes signal handler Test 4: semaphore/read: No thread wakes up or executes the signal handler, sleep() doesn't sleep any more after the first signal (returns immediately) pause: All threads wake up on every signal, correct thread executes signal handler Test 5: semaphore: No thread is killed, sleep() doesn't sleep any more pause: First thread cancelled, other threads won't pause() any more and run amok read: Some threads are killed, sleep() doesn't sleep any more Test 6: semaphore/pause: No thread is killed, sleep() doesn't sleep any more pause: First thread cancelled, other threads won't pause() any more and run amok Sorry if I’m mixing two (or three?) problems, but they all seem pthreads-related. pthread_cancel deferred: Worked on threads blocked in sem_wait() and pause() in 1.7.9, doesn’t work any more in 1.7.12-1 and newer and instead hangs calling thread. I’d consider this one a regression. Didn’t work on threads blocked in read() in any tested version. pthread_cancel asynchronous: No thread is cancelled in any tested version. Calling thread doesn’t hang, though. pthread_kill: In 1.7.9 a signal to any thread wakes up all threads blocked in pause() and the correct thread executes the signal handler. Doesn’t wake threads blocked in sem_wait() or read(). After delivering a signal, pause() and sleep() don’t block any more and return immediately. In 1.7.12-1 and newer sleep() and pause() won’t break and not all threads are woken up. Instead only one thread is woken, but unfortunately not always the correct one. While signal handling mostly seems to have improved, cancelling got worse. Especially the fact that the calling thread blocks in pthread_cancel can be quite a show-stopper. Any suggestions or ideas? Cheers, Otto -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected
On Fri, May 18, 2012 at 6:23 AM, Otto Meta wrote: Any suggestions or ideas? You should always try the most recent http://cygwin.com/snapshots. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Making Unix like paths work when using java program from Cygwin
On Fri, May 18, 2012 at 4:56 AM, himoundary wrote: I am working in a team where everyone else has a Linux/Mac OS X workstation, but I have a windows workstation. Our project uses a shell script and a java program to automate some deployment/setup etc, which needs to create some directories of the sort /ABC/XYZ. Obviously such paths are not valid in Windows. You spread falsities about Windows. Try the following in cmd.exe and you will be in a shock for your life. mkdir /ABC/XYZ I was hoping if I executed these scripts from within a Cygwin terminal, the problem might be solved (with /ABC/XYZ mapping to C:\cygwin\ABC\XYZ While the issue gets solved for the shell scripts, it does not for the java program. I realize this happens because the Cygwin executes the very same java.exe program which is installed on Windows (even though I selected 'java' related packages for installation while installing Cygwin). Is there a way to get the equivalent of the native javac and java programs one would find on a typical Linux workstation. You probably want to use the capabilities of cygpath for this and modify your script. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Making Unix like paths work when using java program from Cygwin
On Fri, May 18, 2012 at 1:51 PM, Earnie Boyd wrote: On Fri, May 18, 2012 at 4:56 AM, himoundary wrote: I am working in a team where everyone else has a Linux/Mac OS X workstation, but I have a windows workstation. Our project uses a shell script and a java program to automate some deployment/setup etc, which needs to create some directories of the sort /ABC/XYZ. Obviously such paths are not valid in Windows. You spread falsities about Windows. Try the following in cmd.exe and you will be in a shock for your life. mkdir /ABC/XYZ Well, I tried it. Maybe you should have, too. H:\mkdir /ABC/XYZ The syntax of the command is incorrect. When it comes to computers, it takes more than that to shock me :) 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
Is the Latest Release of Cygwin supported on Windows Server 8/2012
Was wondering with major changes to the base distro of Windows Server 8/2012 is anyone running compatibility tests on the platform and if so what observed results were? Will or Does Cygwin run on Windows Server 8/2012? I have seen some comments about difficulties with Cygwin on Windows 8 desktop but have not heard much about Server Edition. Trying to determine if Cygwin latest release is an option to run Unix/Posix Products on Windows Server 8/2012 Are there any efforts to make 64bit Releases under consideration? The reason for the question is it does not make sense to have a 64 bit Server with a 32 bit emulator for POSIX running any major products on any Server Operating System Product. This is like having Porsche running with a small VW Engine under the hood. Yes it is hopped up and can run fast. But it is not going to run like the turbo charged Porsche. So why pay the price of a Porsche when you really are running a VW? Regards, Cary Cary D. Conover Phone 309-929-4918 Google Voice gmail carydcono...@gmail.com Calls Follow Me! -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 05/18/2012 07:46 AM, Cary Conover wrote: Was wondering with major changes to the base distro of Windows Server 8/2012 is anyone running compatibility tests on the platform and if so what observed results were? Will or Does Cygwin run on Windows Server 8/2012? I have seen some comments about difficulties with Cygwin on Windows 8 desktop but have not heard much about Server Edition. Trying to determine if Cygwin latest release is an option to run Unix/Posix Products on Windows Server 8/2012 Don't know about Windows 8 Server. Is anybody running that? Is it even released? Are there any efforts to make 64bit Releases under consideration? The reason for the question is it does not make sense to have a 64 bit Server with a 32 bit emulator for POSIX running any major products on any Server Operating System Product. This is like having Porsche running with a small VW Engine under the hood. Yes it is hopped up and can run fast. But it is not going to run like the turbo charged Porsche. So why pay the price of a Porsche when you really are running a VW? 64-bit does not make things go any faster than 32-bit. 64-bit is wasteful as programs grow to double in size. 64-bit is only required/useful/etc if you have memory requirements 4 gig. I don't think any Cygwin executable has such requirements... -- Andrew DeFaria http://defaria.com Why is it called Alcoholics Anonymous when the first thing you do is stand up and say, My name is Bob, and I am an alcoholic? -- 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: Making Unix like paths work when using java program from Cygwin
On Fri, May 18, 2012 at 9:22 AM, Csaba Raduly wrote: On Fri, May 18, 2012 at 1:51 PM, Earnie Boyd wrote: On Fri, May 18, 2012 at 4:56 AM, himoundary wrote: I am working in a team where everyone else has a Linux/Mac OS X workstation, but I have a windows workstation. Our project uses a shell script and a java program to automate some deployment/setup etc, which needs to create some directories of the sort /ABC/XYZ. Obviously such paths are not valid in Windows. You spread falsities about Windows. Try the following in cmd.exe and you will be in a shock for your life. mkdir /ABC/XYZ Well, I tried it. Maybe you should have, too. I have before but not working today! ;p However rmdir /abc/xyz did, note the quotes; the mkdir command did not. The one thing I find in Windows, nothing is consistent. H:\mkdir /ABC/XYZ The syntax of the command is incorrect. When it comes to computers, it takes more than that to shock me :) I'm still surprised occasionally but not often. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Making Unix like paths work when using java program from Cygwin
The java aspect looks like a red herring as not relevant to the problem. You want to run a *nix shell script and presumably don't want to write your own bat file doing the same job. I'm probably missing something but given that there's cygwin, and it's a *nux script, what about just editing the script for your computer, amending the paths in the script, with a find and replace, so /ABC/XYZ is replaced with /cygdrive/c/ABC/XYZ and running the script in cygwin. --- On Fri, 18/5/12, Earnie Boyd wrote: From: Earnie Boyd Subject: Re: Making Unix like paths work when using java program from Cygwin To: cygwin Date: Friday, 18 May, 2012, 15:58 On Fri, May 18, 2012 at 9:22 AM, Csaba Raduly wrote: On Fri, May 18, 2012 at 1:51 PM, Earnie Boyd wrote: On Fri, May 18, 2012 at 4:56 AM, himoundary wrote: I am working in a team where everyone else has a Linux/Mac OS X workstation, but I have a windows workstation. Our project uses a shell script and a java program to automate some deployment/setup etc, which needs to create some directories of the sort /ABC/XYZ. Obviously such paths are not valid in Windows. You spread falsities about Windows. Try the following in cmd.exe and you will be in a shock for your life. mkdir /ABC/XYZ Well, I tried it. Maybe you should have, too. I have before but not working today! ;p However rmdir /abc/xyz did, note the quotes; the mkdir command did not. The one thing I find in Windows, nothing is consistent. H:\mkdir /ABC/XYZ The syntax of the command is incorrect. When it comes to computers, it takes more than that to shock me :) I'm still surprised occasionally but not often. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Making Unix like paths work when using java program from Cygwin
On Fri, May 18, 2012 at 11:11 AM, Marilo wrote: The java aspect looks like a red herring as not relevant to the problem. You want to run a *nix shell script and presumably don't want to write your own bat file doing the same job. I'm probably missing something but given that there's cygwin, and it's a *nux script, what about just editing the script for your computer, amending the paths in the script, with a find and replace, so /ABC/XYZ is replaced with /cygdrive/c/ABC/XYZ and running the script in cygwin. http://cygwin.com/acronyms/#TOFU Why invent that wheel when you have cygpath already to do the job? And java isn't going to understand /cygdrive/c either. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Making Unix like paths work when using java program from Cygwin
--- On Fri, 18/5/12, Earnie Boyd wrote: From: Earnie Boyd Subject: Re: Making Unix like paths work when using java program from Cygwin Date: Friday, 18 May, 2012, 16:15 On Fri, May 18, 2012 at 11:11 AM, Marilo wrote: The java aspect looks like a red herring as not relevant to the problem. You want to run a *nix shell script and presumably don't want to write your own bat file doing the same job. I'm probably missing something but given that there's cygwin, and it's a *nux script, what about just editing the script for your computer, amending the paths in the script, with a find and replace, so /ABC/XYZ is replaced with /cygdrive/c/ABC/XYZ and running the script in cygwin. http://cygwin.com/acronyms/#TOFU Why invent that wheel when you have cygpath already to do the job? And java isn't going to understand /cygdrive/c either. Still use /cygdrive/c in the shell script. I wasn't suggesting using /cygdrive/c in his java program. His java program is not so much a cygwin issue, as his shell script is. If his java program has file paths that need amending, then since you point out that a cygwin program could be used to help convert the paths in his java program, then, I see, the java program could be relevant to cygwin in that sense. Note java wouldn't understand c:\blah\a.txt it could have c:\\blah\a.txt though. A search and replace might be easier though, possibly using regex. How do you get cygpath to do make /v into c:\v ? $ cygpath -aw /v C:\cygwin\v and not that i'm suggesting it but out of curiousity, can cygpath take a file and convert any linux paths in it to windows paths? how? and if it can't then i'm not sure its use for 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: Making Unix like paths work when using java program from Cygwin
On Fri, May 18, 2012 at 11:50 AM, Marilo wrote: Still use /cygdrive/c in the shell script. It is possible but the OP stated that he mounted the directory to /ABC/XYZ. I wasn't suggesting using /cygdrive/c in his java program. His java program is not so much a cygwin issue, as his shell script is. If his java program has file paths that need amending, then since you point out that a cygwin program could be used to help convert the paths in his java program, then, I see, the java program could be relevant to cygwin in that sense. Note java wouldn't understand c:\blah\a.txt it could have c:\\blah\a.txt though. A search and replace might be easier though, possibly using regex. The issue is conversion of POSIX to WINDOWS paths for the native program. The OP needs to give the native java a Windows path but it is getting the POSIX path and not able to find it. How do you get cygpath to do make /v into c:\v ? $ cygpath -aw /v C:\cygwin\v $ cygpath -aw /cygdrive/c/v or mount c:/v as /v. and not that i'm suggesting it but out of curiousity, can cygpath take a file and convert any linux paths in it to windows paths? how? and if it can't then i'm not sure its use for this. http://cygwin.com/faq/faq-nochunks.html#faq.using.converting-paths -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Can't access 'some' SMB network drives from ssh or cron
From: Andrey Repin Greetings, Nick Lowe! Is SMB encrypted in this case? You need to make some serious configuration tweaking to make it NOT encrypted. Are you referring to the authentication part of the SESSION_SETUP? The only part of SMB that remember seeing encrypted are the authentication credentials, either in SESSION_SETUP or when setting up the trust relationship between domain controllers. Everything else has been unencrypted. -- 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: SIGINT not passed to java process
python has the same problem. If you send it a Ctrl-C under cmd.com it will print KeyboardInterrupt whereas under Cygwin it prints nothing. Is python more to your taste? On 5/17/2012 7:23 PM, Christopher Faylor wrote: On Thu, May 17, 2012 at 05:30:26PM +0200, Olivier Lefevre wrote: On 5/11/2012 7:29 PM, Franz Kettwig wrote: After updating to the latest cygwin, my Java processes no longer receive SIGINT signals. [...] I can attest that Franz is not the only one with this problem. I just upgraded to Cygwin 1.7.15-1 but in vain. Is a fix in the works? Not from me. I don't do Java. -- 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: SIGINT not passed to java process
On Fri, May 18, 2012 at 06:48:56PM +0200, Olivier Lefevre wrote: On 5/17/2012 7:23 PM, Christopher Faylor wrote: On Thu, May 17, 2012 at 05:30:26PM +0200, Olivier Lefevre wrote: On 5/11/2012 7:29 PM, Franz Kettwig wrote: After updating to the latest cygwin, my Java processes no longer receive SIGINT signals. [...] I can attest that Franz is not the only one with this problem. I just upgraded to Cygwin 1.7.15-1 but in vain. Is a fix in the works? Not from me. I don't do Java. python has the same problem. If you send it a Ctrl-C under cmd.com it will print KeyboardInterrupt whereas under Cygwin it prints nothing. Is python more to your taste? Presumably you are referring to a native windows version of python, since: d:\cyginstbash bash-4.1$ python Python 2.6.7 (r267:88850, Feb 2 2012, 23:50:20) [GCC 4.5.3] on cygwin Type help, copyright, credits or license for more information. Hit CTRL-C here KeyboardInterrupt I know this is an astonishing, maybe even revolutionary idea, but maybe somebody who wants to use these native windows applications under Cygwin might want to step up to debug this type of thing. -- 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 Commands
From: m...@kalani.com [mailto:m...@kalani.com] When I enter: admin@mypc ~ $cd admin@mypc ~ $ The Cygwin/POSIX cd command is different from the Windows cd command. Cygwin/POSIX cd without arguments: change the current directory to the user's home directory Windows cd without arguments: display the current directory The Cygwin/POSIX command to display the current directory is pwd, short for print working directory. admin@mypc ~ $dir admin@mypc ~ $ The Cygwin/GNU dir command is different from the Windows dir command. Cygwin/GNU dir: list files except those that start with a dot (.) Windows dir: list files except those with the hidden attribute flag set The Cygwin/GNU command to list all files, including ones that start with a dot, is dir -a (a is short for all). You might find the following link useful. It's an introduction to Linux commands for Windows users. Since Cygwin emulates Linux commands, most of what it says about Linux commands also applies to Cygwin commands: http://tldp.org/HOWTO/DOS-Win-to-Linux-HOWTO.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: SIGINT not passed to java process
On Fri, May 18, 2012 at 1:10 PM, Christopher Faylor wrote: d:\cyginstbash bash-4.1$ python Python 2.6.7 (r267:88850, Feb 2 2012, 23:50:20) [GCC 4.5.3] on cygwin Type help, copyright, credits or license for more information. Hit CTRL-C here KeyboardInterrupt I know this is an astonishing, maybe even revolutionary idea, but maybe somebody who wants to use these native windows applications under Cygwin might want to step up to debug this type of thing. I'm not offering to do that but will venture to guess that the text back to the terminal is perhaps causing a block on the pipe leaving a hung process. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Making Unix like paths work when using java program from Cygwin
On 5/18/2012 8:11 AM, Marilo wrote: The java aspect looks like a red herring as not relevant to the problem. You want to run a *nix shell script and presumably don't want to write your own bat file doing the same job. I'm probably missing something but given that there's cygwin, and it's a *nux script, what about just editing the script for your computer, amending the paths in the script, with a find and replace, so /ABC/XYZ is replaced with /cygdrive/c/ABC/XYZ and running the script in cygwin. That's a bad thing to do! Now you have deviated and have a unique version of this script. It will not work 6 months down the road when the script is updated on the Unix/Linux side and you have to again port it. Instead carefully test to make sure you're in Cygwin and when in Cygwin use cygpath appropriately. Then contribute the code back from whence it came so you have a hope that the next version will at least have your portability changes if not the modifier will simply follow suit and take into account Cygwin users as you've shown can be done. -- Andrew DeFaria http://defaria.com As the shopper placed her groceries on the checkout stand, the bagger asked her paper or plastic? Doesn't matter, she replied, I'm bisackual. -- 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: SIGINT not passed to java process
On Fri, May 18, 2012 at 01:33:08PM -0400, Earnie Boyd wrote: On Fri, May 18, 2012 at 1:10 PM, Christopher Faylor wrote: ??d:\cyginstbash ??bash-4.1$ python ??Python 2.6.7 (r267:88850, Feb ??2 2012, 23:50:20) ??[GCC 4.5.3] on cygwin ??Type help, copyright, credits or license for more information. ?? Hit CTRL-C here ??KeyboardInterrupt I know this is an astonishing, maybe even revolutionary idea, but maybe somebody who wants to use these native windows applications under Cygwin might want to step up to debug this type of thing. I'm not offering to do that but will venture to guess that the text back to the terminal is perhaps causing a block on the pipe leaving a hung process. There's no pipe when you're running in cmd.com, as was reported for python. -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
64-bit does not make things go any faster than 32-bit. Not true for some applications. For one of our applications that uses very large in-memory trees and is therefore heavy on the recursion, simply switching the compiler to 64-bit provided a 10% performance boost. Other commonly used compilers and configurations provided an even bigger boost - e.g. 15% to 20%. Seems like I recall reading somewhere that x64 has more registers available for parameter passing, so recursive algorithms get a boost like this. Other applications aren't affected so much by the change. For example, I would expect a simple math intensive app that doesn't use much memory or recursion to run at about the same speed. And other applications are detrimentally affected. For example, the 2x larger pointer size can negatively affect algorithms that store many pointers, which means that not as much data can be stored in the fast CPU cache. 64-bit is wasteful as programs grow to double in size. Not true. Some programs grow slightly and some might not grow so severely. Example: - comparing an otherwise identically-compiled program, it is 583 KB for 64-bit and 613 KB for 32-bit. So the 64-bit version is actually smaller. Another example program is 1364 KB for 32-bit and 1956 KB for 64-bit. In that case the 64-bit version is larger, but not even close to 2x larger. Besides, who cares that much about the image size these days? We don't, within reason. 64-bit is only required/useful/etc if you have memory requirements 4 gig. I don't think any Cygwin executable has such requirements... And 640 KB of RAM will be enough for anybody. You say you get 4 GB but for many applications that is only a dream: * Most applications are not compiled to be large address aware, which means that they only get 2 GB of address space - not 4 GB. Windows gets the rest. In order to be large address aware, you have to be 100% sure that no code is storing pointers in signed integers and then doing math/comparisons with it. If you are large address aware, you still only get a limited amount of memory on 32-bit operating systems - not the full 4 GB. * You could use Address Windowing Extensions to access more than 4 GB in 32-bit, but the application has to be specially coded for it because you are swapping the pages in and out of the 32-bit address space and there are other limitations (e.g. is not pagefile backed). * So, assuming you only have 2 GB of user-mode address space. Windows DLLs will gobble up a few hundred megabytes at the upper end of the space to map its DLL images. * Your program and dependencies also have to be mapped into memory. If you're smart, you take the time to rebase them and/or turn on ASLR so that they occupy a contiguous block of memory. Otherwise, you could badly fragment the address space further. * Your program will fragment the address space as it runs. How badly will depend on the memory allocator and the pattern of memory allocations you make. * An external program outside of your control might load/inject a hook DLL into your process, and load it smack in the middle of your address space, fragmenting it. Or maybe it's a 3rd-party DLL/driver that you load, but it's beyond your control. When it's all said and done, for many applications if you properly rebase, you might get 1.5 GB contiguous space on a clean install of Windows. But it's too easy for that to fragment. Realistically, you can't allocate blocks more than maybe a couple hundred MBs to be safe. And you should try to allocate much more than 1 GB total. Fire up VMMap and point it at the average process on your computer - especially a more complicated one that's been running for a while. You might be surprised how small the largest free space block there is for some programs. Sure there's an argument that you should split your data into smaller allocations, but big allocations are awfully convenient for some pieces of data. In our case, we use a 3rd-party library that requires us to store our large data sets in contiguous memory, so fragmentation is a big problem. For us, supporting the limited 4 GB 32-bit address space has turned into a big annoyance in some of our applications. It's not a theoretical discussion. To the OP: there has been lots of discussion about 64-bit on the Cygwin developer list; you may want to read up on the conversations there... -- 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: SIGINT not passed to java process
On Fri, May 18, 2012 at 1:54 PM, Christopher Faylor wrote: On Fri, May 18, 2012 at 01:33:08PM -0400, Earnie Boyd wrote: On Fri, May 18, 2012 at 1:10 PM, Christopher Faylor wrote: ??d:\cyginstbash ??bash-4.1$ python ??Python 2.6.7 (r267:88850, Feb ??2 2012, 23:50:20) ??[GCC 4.5.3] on cygwin ??Type help, copyright, credits or license for more information. ?? Hit CTRL-C here ??KeyboardInterrupt I know this is an astonishing, maybe even revolutionary idea, but maybe somebody who wants to use these native windows applications under Cygwin might want to step up to debug this type of thing. I'm not offering to do that but will venture to guess that the text back to the terminal is perhaps causing a block on the pipe leaving a hung process. There's no pipe when you're running in cmd.com, as was reported for python. I thought the conversation stemmed from inter-process communication of a signal between Cygwin runtime and native runtime applications. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
Interpreting a gdb backtrace
I'm trying to debug an emacs crash and am having trouble getting a useful backtrace after the crash. Here's an example: #0 0x00289c08 in ?? () No symbol table info available. #1 0x007ba148 in _malloc_mutex () No symbol table info available. #2 0x in ?? () No symbol table info available. Aside from the lack of information, the most salient feature of this is that _malloc_mutex is actually a variable, not a function, so the information for frame #1 makes no sense. I'm not very experienced at debugging, but I'm wondering if I can get anything out of this sort of backtrace. Or does it just indicate that the stack got corrupted? Thanks in advance for any suggestions. 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: Interpreting a gdb backtrace
On 2012-05-19 AM 6:08, Ken Brown wrote: I'm trying to debug an emacs crash and am having trouble getting a useful backtrace after the crash. Here's an example: #0 0x00289c08 in ?? () No symbol table info available. #1 0x007ba148 in _malloc_mutex () No symbol table info available. #2 0x in ?? () No symbol table info available. i think you should provide symbol file of emacs to gdb. if it was stripped, you had better to build emacs from source code with -g (at least gcc 4.5 for CFI that gdb need to backtrace the stack frame with ease). -- Regards. -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/18/2012 10:58 AM, James Johnston wrote: 64-bit does not make things go any faster than 32-bit. Not true for some applications. For one of our applications that uses very large in-memory trees and is therefore heavy on the recursion, simply switching the compiler to 64-bit provided a 10% performance boost. Other commonly used compilers and configurations provided an even bigger boost - e.g. 15% to 20%. Seems like I recall reading somewhere that x64 has more registers available for parameter passing, so recursive algorithms get a boost like this. Other applications aren't affected so much by the change. For example, I would expect a simple math intensive app that doesn't use much memory or recursion to run at about the same speed. And other applications are detrimentally affected. For example, the 2x larger pointer size can negatively affect algorithms that store many pointers, which means that not as much data can be stored in the fast CPU cache. OK, OK. Tack on for most applications to my statement (I thought it was assumed). 64-bit is wasteful as programs grow to double in size. Not true. Some programs grow slightly and some might not grow so severely. Example: - comparing an otherwise identically-compiled program, it is 583 KB for 64-bit and 613 KB for 32-bit. So the 64-bit version is actually smaller. Another example program is 1364 KB for 32-bit and 1956 KB for 64-bit. In that case the 64-bit version is larger, but not even close to 2x larger. How can 1000 machine instructions of 32 bit be larger than 1000 machine instructions twice that size! Unless vastly different code generation happens with 64 bit compilers the number of instructions emitted should be just about the same yet with 64 bit instructions are obviously twice as big as 32 bit instructions. Besides, who cares that much about the image size these days? We don't, within reason. I, for one, do. These larger binary images need to fit in memory and reserve swap space and virtual memory. I see virtual memory foot prints in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly takes 1-2 gig of virtual memory and hundreds of megs of real memory. If you run many things like I do you quickly get to the point where your swapping and thrashing and waiting for the OS to manage many, many more fragments of memory. All my systems have 4 gig (XP at work, a couple of Ubuntu boxes at home) and they all come under memory pressure at times. Small is beautiful. 64-bit is only required/useful/etc if you have memory requirements 4 gig. I don't think any Cygwin executable has such requirements... And 640 KB of RAM will be enough for anybody. That's totally unfair as I didn't say that nor did I imply it at all. As such that was a stupid thing to say IMHO. You say you get 4 GB but for many applications that is only a dream: I didn't say anything of the sort. Re-read it. * Most applications are not compiled to be large address aware, which means that they only get 2 GB of address space - not 4 GB. Windows gets the rest. In order to be large address aware, you have to be 100% sure that no code is storing pointers in signed integers and then doing math/comparisons with it. If you are large address aware, you still only get a limited amount of memory on 32-bit operating systems - not the full 4 GB. I didn't say that either. I said that 64 bit allows you to address more than 4 gig. * You could use Address Windowing Extensions to access more than 4 GB in 32-bit, but the application has to be specially coded for it because you are swapping the pages in and out of the 32-bit address space and there are other limitations (e.g. is not pagefile backed). * So, assuming you only have 2 GB of user-mode address space. Windows DLLs will gobble up a few hundred megabytes at the upper end of the space to map its DLL images. * Your program and dependencies also have to be mapped into memory. If you're smart, you take the time to rebase them and/or turn on ASLR so that they occupy a contiguous block of memory. Otherwise, you could badly fragment the address space further. * Your program will fragment the address space as it runs. How badly will depend on the memory allocator and the pattern of memory allocations you make. * An external program outside of your control might load/inject a hook DLL into your process, and load it smack in the middle of your address space, fragmenting it. Or maybe it's a 3rd-party DLL/driver that you load, but it's beyond your control. When it's all said and done, for many applications if you properly rebase, you might get 1.5 GB contiguous space on a clean install of Windows. But it's too easy for that to fragment. Realistically, you can't allocate blocks more than maybe a couple hundred MBs to be safe. And you should try to allocate much more than 1 GB total. Fire up VMMap and point it at the average process on your computer -
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/19/2012 06:45, Andrew DeFaria wrote: On 5/18/2012 10:58 AM, James Johnston wrote: 64-bit does not make things go any faster than 32-bit. Not true for some applications. For one of our applications that uses very large in-memory trees and is therefore heavy on the recursion, simply switching the compiler to 64-bit provided a 10% performance boost. Other commonly used compilers and configurations provided an even bigger boost - e.g. 15% to 20%. Seems like I recall reading somewhere that x64 has more registers available for parameter passing, so recursive algorithms get a boost like this. Other applications aren't affected so much by the change. For example, I would expect a simple math intensive app that doesn't use much memory or recursion to run at about the same speed. And other applications are detrimentally affected. For example, the 2x larger pointer size can negatively affect algorithms that store many pointers, which means that not as much data can be stored in the fast CPU cache. OK, OK. Tack on for most applications to my statement (I thought it was assumed). I believe the same was said when transitioning from 16bit to 32bit. 64-bit is wasteful as programs grow to double in size. Not true. Some programs grow slightly and some might not grow so severely. Example: - comparing an otherwise identically-compiled program, it is 583 KB for 64-bit and 613 KB for 32-bit. So the 64-bit version is actually smaller. Another example program is 1364 KB for 32-bit and 1956 KB for 64-bit. In that case the 64-bit version is larger, but not even close to 2x larger. How can 1000 machine instructions of 32 bit be larger than 1000 machine instructions twice that size! Unless vastly different code generation happens with 64 bit compilers the number of instructions emitted should be just about the same yet with 64 bit instructions are obviously twice as big as 32 bit instructions. Those are just pointers, instructions do not necessary double in size, we are talking about CISC CPUs after all, besides, nearly all registers in 64bit long mode doubled in size, not to mention the number of them increased, see AMD64 GPRs compared to x86 GPRs. Besides, who cares that much about the image size these days? We don't, within reason. I, for one, do. These larger binary images need to fit in memory and reserve swap space and virtual memory. I see virtual memory foot prints in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly takes 1-2 gig of virtual memory and hundreds of megs of real memory. If you run many things like I do you quickly get to the point where your swapping and thrashing and waiting for the OS to manage many, many more fragments of memory. All my systems have 4 gig (XP at work, a couple of Ubuntu boxes at home) and they all come under memory pressure at times. Small is beautiful. No modern OS actually loaded the entire executable into memory, not since the MSDOS days, they are mapped, like pagefiles. 64-bit is only required/useful/etc if you have memory requirements 4 gig. I don't think any Cygwin executable has such requirements... And 640 KB of RAM will be enough for anybody. That's totally unfair as I didn't say that nor did I imply it at all. As such that was a stupid thing to say IMHO. You say you get 4 GB but for many applications that is only a dream: I didn't say anything of the sort. Re-read it. * Most applications are not compiled to be large address aware, which means that they only get 2 GB of address space - not 4 GB. Windows gets the rest. In order to be large address aware, you have to be 100% sure that no code is storing pointers in signed integers and then doing math/comparisons with it. If you are large address aware, you still only get a limited amount of memory on 32-bit operating systems - not the full 4 GB. I didn't say that either. I said that 64 bit allows you to address more than 4 gig. * You could use Address Windowing Extensions to access more than 4 GB in 32-bit, but the application has to be specially coded for it because you are swapping the pages in and out of the 32-bit address space and there are other limitations (e.g. is not pagefile backed). * So, assuming you only have 2 GB of user-mode address space. Windows DLLs will gobble up a few hundred megabytes at the upper end of the space to map its DLL images. * Your program and dependencies also have to be mapped into memory. If you're smart, you take the time to rebase them and/or turn on ASLR so that they occupy a contiguous block of memory. Otherwise, you could badly fragment the address space further. * Your program will fragment the address space as it runs. How badly will depend on the memory allocator and the pattern of memory allocations you make. * An external program outside of your control might load/inject a hook DLL into your process, and load it smack in the middle of your address
Re: Interpreting a gdb backtrace
On 5/18/2012 6:45 PM, jojelino wrote: On 2012-05-19 AM 6:08, Ken Brown wrote: I'm trying to debug an emacs crash and am having trouble getting a useful backtrace after the crash. Here's an example: #0 0x00289c08 in ?? () No symbol table info available. #1 0x007ba148 in _malloc_mutex () No symbol table info available. #2 0x in ?? () No symbol table info available. i think you should provide symbol file of emacs to gdb. if it was stripped, you had better to build emacs from source code with -g (at least gcc 4.5 for CFI that gdb need to backtrace the stack frame with ease). I built emacs with -g -O0. gdb had the symbol table at the start of the debugging session. It's just after the crash that everything is messed up. 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
Installing cygwin on new box, getting cygwin1.dll is missing
Today I started trying to install Cygwin on a new Win7 box. It took a long time to get to the end, which included many Can't open (null) for reading: No such file dialogs along the way. When it finally got close to finishing, I got a dialog which just says: The program can't start because cygwin1.dll is missing from your computer. I've searched for occurrences of this particular symptom, but I didn't see anything useful. What's curious is that when I try to dismiss the dialog, it just redisplays. Fortunately, it's not a modal dialog, so it lets me click Cancel on the setup dialog. Also curiously, that doesn't even cause the The program ... dialog to go away. Clicking OK at that point makes it go away. I've tried this several times, with the same result. -- 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: Interpreting a gdb backtrace
On 2012-05-19 AM 9:30, Ken Brown wrote: I built emacs with -g -O0. gdb had the symbol table at the start of the debugging session. It's just after the crash that everything is messed up. Ken Then, i suspect that some function is called with function pointer type with different calling convention from itself, eventually stack frame is broken and return address goes into wrong place. if it is the case, there is nothing we can expect from gdb backtrace. but at least we can inspect esp register ?? for example, type following x $esp x $esp-4 x $esp-8 x $esp-c ... or x $esp-0x40(or greater than) and just enter until you get value which seems to be return address. and you can know what the return address is supposed to be(if it isn't relocated but it is scarce.) i hope you can find return address. then you can breakpoint the annoying procedure. -- Regards. -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/18/2012 4:37 PM, JonY wrote: OK, OK. Tack on for most applications to my statement (I thought it was assumed). I believe the same was said when transitioning from 16bit to 32bit. If so then they were wrong. Those are just pointers, instructions do not necessary double in size, I was under the impression that the instruction size matches the natural word size of the machine. Therefore they would be 64 bit instructions. we are talking about CISC CPUs after all, besides, nearly all registers in 64bit long mode doubled in size, not to mention the number of them increased, see AMD64 GPRs compared to x86 GPRs. I believe my AMD64 is considered a RISC computer. According to http://www.tek-tips.com/faqs.cfm?fid=788 The K5 and K6 series are internally a highly parallel RISC processor using an x86 decoding front-end. And according to https://en.wikipedia.org/wiki/Instruction_set: In some architectures, notably most reduced instruction set computers (RISC), instructions are a fixed length, typically corresponding with that architecture's word size. Things might be different now. I really don't keep up with processors anymore. Besides, who cares that much about the image size these days? We don't, within reason. I, for one, do. These larger binary images need to fit in memory and reserve swap space and virtual memory. I see virtual memory foot prints in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly takes 1-2 gig of virtual memory and hundreds of megs of real memory. If you run many things like I do you quickly get to the point where your swapping and thrashing and waiting for the OS to manage many, many more fragments of memory. All my systems have 4 gig (XP at work, a couple of Ubuntu boxes at home) and they all come under memory pressure at times. Small is beautiful. No modern OS actually loaded the entire executable into memory, not since the MSDOS days, they are mapped, like pagefiles. So what. All of this is irrelevant to the request to make say /bin/ls 64 bit. And why not? And why not what? Your question doesn't make sense. Even if the rest of the system has transitioned to 64bit? Even if the rest transitioned what? Your question doesn't make sense again. If you didn't know, GCC does win64 applications fine. The hard part for porting Cygwin to win64 is the LP64 vs LLP64 issue. The former is used by newlib, it is not easy to transition to Win64 LLP64. I still don't understand what having a 64 bit version of ls or grep will do for ya... -- Andrew DeFaria http://defaria.com I've taken a vow of poverty -- to annoy me, send money -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/19/2012 09:15, Andrew DeFaria wrote: On 5/18/2012 4:37 PM, JonY wrote: OK, OK. Tack on for most applications to my statement (I thought it was assumed). I believe the same was said when transitioning from 16bit to 32bit. If so then they were wrong. Those are just pointers, instructions do not necessary double in size, I was under the impression that the instruction size matches the natural word size of the machine. Therefore they would be 64 bit instructions. No, we are talking about x86, not MIPS/ARM type RISC. we are talking about CISC CPUs after all, besides, nearly all registers in 64bit long mode doubled in size, not to mention the number of them increased, see AMD64 GPRs compared to x86 GPRs. I believe my AMD64 is considered a RISC computer. According to http://www.tek-tips.com/faqs.cfm?fid=788 The K5 and K6 series are internally a highly parallel RISC processor using an x86 decoding front-end. And according to https://en.wikipedia.org/wiki/Instruction_set: In some architectures, notably most reduced instruction set computers (RISC), instructions are a fixed length, typically corresponding with that architecture's word size. Things might be different now. I really don't keep up with processors anymore. Which do not apply to CISC CPUs, whatever implementation underneath is tangent to the user code ISA, the opcodes did not double in size. Please at least look at the x86 opcode, they are known to have variable lengths. Besides, who cares that much about the image size these days? We don't, within reason. I, for one, do. These larger binary images need to fit in memory and reserve swap space and virtual memory. I see virtual memory foot prints in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly takes 1-2 gig of virtual memory and hundreds of megs of real memory. If you run many things like I do you quickly get to the point where your swapping and thrashing and waiting for the OS to manage many, many more fragments of memory. All my systems have 4 gig (XP at work, a couple of Ubuntu boxes at home) and they all come under memory pressure at times. Small is beautiful. No modern OS actually loaded the entire executable into memory, not since the MSDOS days, they are mapped, like pagefiles. So what. Binary sizes do not correspond to memory usage, not anymore. All of this is irrelevant to the request to make say /bin/ls 64 bit. And why not? And why not what? Your question doesn't make sense. Even if the rest of the system has transitioned to 64bit? Even if the rest transitioned what? Your question doesn't make sense again. If you didn't know, GCC does win64 applications fine. The hard part for porting Cygwin to win64 is the LP64 vs LLP64 issue. The former is used by newlib, it is not easy to transition to Win64 LLP64. I still don't understand what having a 64 bit version of ls or grep will do for ya... Since 64-bit mode cannot be avoided, there is simply no reason to keep legacy mode applications and all that baggage if you can easily rebuild and move to 64-bit mode. You don't keep 16-bit programs lying about when there are 32-bit programs doing the same thing right? signature.asc Description: OpenPGP digital signature
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 05/18/2012 07:39 PM, JonY wrote: I was under the impression that the instruction size matches the natural word size of the machine. Therefore they would be 64 bit instructions. No, we are talking about x86, not MIPS/ARM type RISC. Really? OK - Show me! Because the first mention of even CISC was *your* posting two posts ago. Just because you were talking about x86 does not mean that I was talking about x86. Which do not apply to CISC CPUs, whatever implementation underneath is tangent to the user code ISA, the opcodes did not double in size. Please at least look at the x86 opcode, they are known to have variable lengths. I was not talking about your x86 - you were. I still don't understand what having a 64 bit version of ls or grep will do for ya... Since 64-bit mode cannot be avoided, Excuse me but it seems to me that right now it is being avoided quite successfully. Cannot be avoided? Really? there is simply no reason to keep legacy mode applications and all that baggage if you can easily rebuild and move to 64-bit mode. If a 32 bit executable will run on a 64 bit machine, but a 64 bit executable will not run on a 32 bit machine, there's no good justification to have to maintain two different builds and sets of bits. You don't keep 16-bit programs lying about when there are 32-bit programs doing the same thing right? When 32 bit just came around, you betcha I did - and so did you. All that said, I'd like to see it all move to 64 bit and I know it will, eventually. But I can understand the rational for not doing it at this time. -- Andrew DeFaria http://defaria.com I'm not into working out. My philosophy is no pain, no pain. -- 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: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 5/19/2012 11:25, Andrew DeFaria wrote: On 05/18/2012 07:39 PM, JonY wrote: I was under the impression that the instruction size matches the natural word size of the machine. Therefore they would be 64 bit instructions. No, we are talking about x86, not MIPS/ARM type RISC. Really? OK - Show me! Because the first mention of even CISC was *your* posting two posts ago. Just because you were talking about x86 does not mean that I was talking about x86. Which do not apply to CISC CPUs, whatever implementation underneath is tangent to the user code ISA, the opcodes did not double in size. Please at least look at the x86 opcode, they are known to have variable lengths. I was not talking about your x86 - you were. Cygwin runs only on x86 Windows, which is on a CISC CPU, with variable length instructions. You maintained that instruction sizes are doubled. This is not true of CISC, especially the entire x86 line. You veered into AMD64 having a RISC implementation underneath, which is of little consequence since it is at the microcode level. This technique is in use since the Pentium Pro days. I still don't understand what having a 64 bit version of ls or grep will do for ya... Since 64-bit mode cannot be avoided, Excuse me but it seems to me that right now it is being avoided quite successfully. Cannot be avoided? Really? there is simply no reason to keep legacy mode applications and all that baggage if you can easily rebuild and move to 64-bit mode. If a 32 bit executable will run on a 64 bit machine, but a 64 bit executable will not run on a 32 bit machine, there's no good justification to have to maintain two different builds and sets of bits. This is no reason to hold back on transitioning to 64bit though. Once you do, there is little reason to keep the baggage if all your programs don't need it. This was what OP was concerned about. You don't keep 16-bit programs lying about when there are 32-bit programs doing the same thing right? When 32 bit just came around, you betcha I did - and so did you. All that said, I'd like to see it all move to 64 bit and I know it will, eventually. But I can understand the rational for not doing it at this time. You have to start somewhere somehow, perhaps with a tiny step, how it goes depends on the Cygwin development committee. signature.asc Description: OpenPGP digital signature
