How to write to shared memory?
Hi, I have a bash loop which I have significantly sped up by using: for ((i=0;i<=Z;i++)); do echo $i; done instead of other format for loops as well as using internal math like: NEWX=$(($EAST+$DX)) Instead of let or expr. This process is now heaps faster but I want to echo the data to a file but not have to write to a file on each loop cycle as it slows it down. On native linux you would write: echo $NEWX > /dev/shm/new and then at the end of all the loops at the end of the script write to a file with: cat /dev/shm/new > $OUT --> Finally to the question. How do you do this with Cygwin?? Cheers, Barrett. -- 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: Sending signals to a subprocess
On 20 October 2010 04:17, Ken Brown wrote:
> Emacs creates a subprocess that runs an interactive bash shell. Emacs wants
> to get the PGID of the foreground process group associated to the tty of
> this shell, and it does this on Linux via TIOCGPGRP (or equally well
> tcgetpgrp). I think it uses the file descriptor of the master of the pty
> for this purpose. If you (or some other programmer reading this) could give
> me the code for setting all this up, I could play with it and try to figure
> out why I'm seeing a difference between Linux and Cygwin here. I just don't
> know how to create a subprocess, give it a terminal, etc.
Here's a test along those lines that does show a difference between
Linux and Cygwin:
#include
#include
int main(void)
{
int pid, fd;
pid = forkpty(&fd, 0, 0, 0);
if (!pid)
sleep(2);
else {
sleep(1);
printf("pid=%i fd=%i pgrp=%i\n", pid, fd, tcgetpgrp(fd));
}
}
On Linux, where it requires -lutil to link, this gives:
pid=13308 fd=3 tcgetpgrp(fd)=13308
On Cygwin:
pid=268 fd=3 tcgetpgrp(fd)=0
Neither of those looks POSIX-compliant to me, because tcgetpgrp should
return -1 since fd 3 isn't the controlling terminal of the calling
process, but the Linux behaviour is rather useful. Perhaps they
decided to apply that restriction only to the slave side?
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: Sending signals to a subprocess
On Tue, Oct 19, 2010 at 11:17:39PM -0400, Ken Brown wrote: >On 10/19/2010 10:15 AM, Christopher Faylor wrote: >I would like to create a STC that would let me investigate this further, >but I don't know enough programming to do it. It ought to be completely >trivial. Here's what happens: > >Emacs creates a subprocess that runs an interactive bash shell. Emacs >wants to get the PGID of the foreground process group associated to the >tty of this shell, and it does this on Linux via TIOCGPGRP (or equally >well tcgetpgrp). I think it uses the file descriptor of the master of >the pty for this purpose. If you (or some other programmer reading >this) could give me the code for setting all this up, I could play with >it and try to figure out why I'm seeing a difference between Linux and >Cygwin here. I just don't know how to create a subprocess, give it a >terminal, etc. I provided a simple text case here: http://cygwin.com/ml/cygwin/2010-10/msg00395.html 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: Where to get source for setup.exe?
On Wed, Oct 20, 2010 at 11:20:29AM +0800, Pan ruochen wrote: >Where can I get the source package for the latest setup.exe. I used to >implement a package filter on version 2.573.2.3. But now the old >version of setup gets errors during installation. And I still want to >apply filtering on setup. http://lmgtfy.com/?q=source+setup.exe+cygwin -- 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
Where to get source for setup.exe?
Hi All, Where can I get the source package for the latest setup.exe. I used to implement a package filter on version 2.573.2.3. But now the old version of setup gets errors during installation. And I still want to apply filtering on setup. PRC Oct 20,2010 -- 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: Sending signals to a subprocess
On 10/19/2010 10:15 AM, Christopher Faylor wrote:
On Tue, Oct 19, 2010 at 09:32:34AM -0400, Ken Brown wrote:
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p->infd, TIOCGPGRP,&gid) == -1&& ! NILP (p->tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p->tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,&gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from "man 4 tty_ioctl" on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
I just tried an experiment, and now I'm thoroughly confused. I inserted
"#undef TIOCGPGRP" into process.c in the emacs source and rebuilt it on
Linux. [Technical note if anyone wants to try to reproduce this: I also
inserted "#undef SIGNALS_VIA_CHARACTERS", since SIGNALS_VIA_CHARACTERS
provides an alternate method of sending signals to processes; this is in
fact my workaround on Cygwin.] Then trying to kill a process running in
an emacs shell with C-c C-c fails the same way it fails in Cygwin. So
somehow TIOCGPGRP is doing the right thing under Linux in the emacs code
above, in spite of its limitations. I don't understand why. When I get
a chance (not today), I'll try running emacs under gdb to see if I can
figure out what's going on.
I guess this should mean that if you implement TIOCGPGRP in Cygwin and
make it emulate Linux, it should work for emacs in Cygwin too. I can
also try to see if tcgetpgrp works instead of TIOCGPGRP. I'm
embarrassed to say that I didn't actually try this before, because my
understanding of the documentation was that it wouldn't work. You can
see I don't think like a programmer.
As I mentioned, my test case shows that when run on Linux, TIOCPGRP and
tcgetpgrp are the same. So, given that, if I implemented TIOCPGRP it
wouldn't solve your problem.
You're right. I'm convinced now that TIOCGPGRP and tcgetpgrp are the
same on Linux, so implementing TIOCGPGRP would not help me. To
double-check, I rewrote the emacs code to use tcgetpgrp instead of
TIOCGPGRP, and it worked on Linux just as well as before. But the same
code fails on Cygwin. I don't understand why it works on Linux, because
it appears to me to be using tcgetpgrp in the situation where it's
supposed to fail
I would like to create a STC that would let me investigate this further,
but I don't know enough programming to do it. It ought to be completely
tri
[ANNOUNCEMENT] Updated: cygport-0.10.1-1
The following package has been updated for the Cygwin distribution: *** cygport-0.10.1-1 This is a bug-fix release with the following improvements: * More fixes for cross-compiling scenarios. * More refinements for automatic exclusion rules. * Better detection of OCaml bytecode during postinstall. * Source .gem's no longer require rubygems to unpack. * autotools.cygclass: error if CYGCONF_SOURCE is specified but incorrect. * gst-plugins0.10.cygclass: adapt to latest openmax and resindvd plugins. * qt4-qmake.cygclass: DLLs in /usr/lib are moved to /usr/bin. * ruby.cygclass: install into vendor_ruby. * ruby-gnome2.cygclass: install into vendor_ruby. Yaakov -- CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Re: can't compile opengl using w32api with gcc
On 2:59 PM, André Bleau wrote: Your problem is the consequence of the libGL-devel package (Mesa GL) taking over /usr/include/GL in 2008. If you want native GL, you need to install the opengl package, and compile with -I/usr/include/opengl , as stated in /usr/share/doc/opengl-1.1.0/README.txt . Thanks for the explanation, André. I hadn't read the new /usr/share/doc/cygwin for the opengl package and was sending this post from a computer running 1.5.25 and not 1.7.x. Using -I/usr/include/opengl worked like a charm. Cheers, Chris -- 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
umounting drives
Is there any possibility to umount a drive letter the UNIX way in Cygwin 1.7.7.1? Whenever I umount a drive, it reappears with parameters different from the ones in /etc/fstab. -- 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: missing dep ecj1.exe 4.5.0 -> libgcj11
On Tue, 2010-10-19 at 22:57 +0200, Samuel Thibault wrote: > I installed version 4.5.0 of gcc4-java, and there seems to be a missing > dependency on libgcj11, as that one didn't get installed, and running > gcj brings > > /usr/lib/gcc/i686-pc-cygwin/4.5.0/ecj1.exe: error while loading shared > libraries: cyggcj-11.dll: cannot open shared object file: No such file > or directory That's because gcc4-java 4.5.0-1 is a 'test' release, where the current 4.3.4-3 release uses libgcj9, and there is no way to specify different dependencies for test/curr/prev releases. This should be rectified whenever Dave pushed a stable 4.5.x. 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
Re: Bash problems, strace, performance, etc.
On 10/19/2010 5:46 PM, Lee D. Rothstein wrote: I'm confused. Something is wrong with my Cygwin configuration that has slowed Cygwin operation down drastically. The performance issue follows several problems with 'bash' that occurred while running nested scripts. The residual effect is slow performance. I've tried 'rebaseall', and that too failed (although frankly, I've never understood when that's called for or what it fixes, except in the most abstract of senses.). (See attached 'Rebaseall_Out.txt.) The "Bash problem" generates a complaint and a stack trace. The complaint is: C:\_0\bin\bash.exe: *** fatal error - WFSO timed out after longjmp The stack traces are listed in the attached file -- Bash_Problem_Output.txt The highest level script that generated the problem was 'mkperlmanpdfs' (attached). 'mkperlmanpdfs', in turn, invokes 'man2pdf' (attached) repeatedly. During several of the 'man2pdf' invocations, errors are reported by 'man'/'groff' in rendering the 'man' "page" to Postscript. I've learned to live with these, and only rarely do they actually lead to omissions in the eventual PDF file. No big deal. In at least two of the cases, however, Bash itself seems to be reporting an error. I've tried shutting down all Cygwin/'mintty' windows, and killing all residual Cygwin processes/apps, using Task Manager. No help, whatsoever. I tried rebooting. That did help. I've also attached Cygcheck output. (The 'cygcheck' follows the reboot.) Attachments: -Bash_Problem_Output.txt -mkperlmanpdfs -man2pdf -Rebaseall_Out.txt -cygcheck-hvscr+2010-10-19+17-35-48.txt The two 'man2pdf' runs that cause the Bash crashes/straces are 'cpan.1' and 'cpanp.1'. I have eye-balled each and neither appears unusual. They are, as are the 163 others Perl man pages, 'pod2man' renderings. (All of these are from the Cygwin Perl distribution.) Also, following the reboot, performance seems to have picked up to the usual slothfulness of a Cygwin configuration on a Vista 64-bit, ahem, OS. ;-) Lee Lee -- 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: Win7 64bit, why so slow?
On 19 October 2010 22:56, Gerrit P. Haase wrote: > Norton Security is running, this may well be a problem, I'll try to > disable this for now. Yes, much better now, seems to run very much faster now without Norton running... I guess I need to trash it. G. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New package: enchant-1.6.0-1
The following packages have been added to the Cygwin distribution: *** enchant-1.6.0-1 *** libenchant1-1.6.0-1 *** libenchant-devel-1.6.0-1 Enchant provides an extensible abstraction for various spell checking libraries. This release includes support for Aspell, Ispell, and Myspell dictionaries. Yaakov -- CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
missing dep ecj1.exe 4.5.0 -> libgcj11
Hello, I installed version 4.5.0 of gcc4-java, and there seems to be a missing dependency on libgcj11, as that one didn't get installed, and running gcj brings /usr/lib/gcc/i686-pc-cygwin/4.5.0/ecj1.exe: error while loading shared libraries: cyggcj-11.dll: cannot open shared object file: No such file or directory Samuel -- 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: Win7 64bit, why so slow?
Hi Reini, > I have a similar laptop here. Ultrafast new Win7 laptop with latest cygwin, > but 32bit only. > cygwin is slower than on XP but not THAT slow. > 64bit is reported to be slower but not THAT slow. But it is that slow here, make on xmlroff-0.62 is still running now after 17 hours ;) > Maybe you are accessing network paths (// prefix)? > Try disabling the network, cards or service. Well, I have this wireless adapter to connect to internet, but this should be not a problem, I have also no network paths attached. Norton Security is running, this may well be a problem, I'll try to disable this for now. Gerrit -- 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: Win7 64bit, why so slow?
On 19 October 2010 22:18, Steve Thompson wrote: > On Tue, 19 Oct 2010, Gerrit P. Haase wrote: > >> anyone can tell me how long it lasts to build xmlroff on Linux? > > On my CentOS 5.5 system, x86_64 dual quad cores at 2.33 GHz, SATA, it takes: > > configure 11 seconds elapsed > make -j4 88 seconds elapsed (248 sec CPU) > > for xmlroff-0.6.2. Wow, I really run the wrong operating system on my nice hardware :) Gerrit -- 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: Win7 64bit, why so slow?
On 19 October 2010 22:04, Edward Lam wrote: > On 10/19/2010 3:30 PM, Gerrit P. Haase wrote: >> >> I don't get it. What is the problem? What can I do? Where to look >> first? How to fix this disagreeableness? > > This is probably the same problem as tracked down previously: > http://cygwin.com/ml/cygwin/2010-08/msg00964.html Can this dll_crt thing, can this be really the single cause of all evil? Why does it affect x64 more and x86 systems not so much? Where is the logic? > This is the last I heard about it: > http://cygwin.com/ml/cygwin/2010-09/msg00796.html Oh my ;) > Also, you might also be running into this problem: > http://cygwin.com/ml/cygwin/2010-05/msg00190.html No bash completion here: $ time bash -i -c echo real0m0.312s user0m0.015s sys 0m0.076s And this wouldn't cause sh, m4 or perl scripts to run that slow like here, like all the autotools are incredible slow for me. bash is noticeable slower with completion activated, this I can confirm: $ time bash -i -c echo real0m1.731s user0m0.325s sys 0m0.699s Gerrit -- 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: Win7 64bit, why so slow?
On Tue, 19 Oct 2010, Gerrit P. Haase wrote: anyone can tell me how long it lasts to build xmlroff on Linux? On my CentOS 5.5 system, x86_64 dual quad cores at 2.33 GHz, SATA, it takes: configure 11 seconds elapsed make -j488 seconds elapsed (248 sec CPU) for xmlroff-0.6.2. On a 9-yr old Pentium III 866 MHz system, IDE: configure 25 seconds elapsed make -j2486 seconds elapsed (871 sec CPU) -Steve -- 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: Win7 64bit, why so slow?
On 10/19/2010 3:30 PM, Gerrit P. Haase wrote: I don't get it. What is the problem? What can I do? Where to look first? How to fix this disagreeableness? This is probably the same problem as tracked down previously: http://cygwin.com/ml/cygwin/2010-08/msg00964.html This is the last I heard about it: http://cygwin.com/ml/cygwin/2010-09/msg00796.html Also, you might also be running into this problem: http://cygwin.com/ml/cygwin/2010-05/msg00190.html Regards, -Edward -- 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: Win7 64bit, why so slow?
2010/10/19 Gerrit P. Haase: > Yes, again... > > Please help me, I have a new laptop, the fastest piece of hardware I > ever owned, and now I am s disappointed because everything on > Cygwin is slower than I have ever experienced before. I have compiled > a lot of packages, some maybe remember my name, I was Perl maintainer > and also maintained some other packages. I have a similar laptop here. Ultrafast new Win7 laptop with latest cygwin, but 32bit only. cygwin is slower than on XP but not THAT slow. 64bit is reported to be slower but not THAT slow. > I can not believe, that my ultra fast 64bit Win7 laptop can not > perform better. It is doing nothing all the the time, besides waiting > for the output of the next line. I called "make" today at 06:10 > today, after configure finished in the night before, now it is 21:25 > and the build is not finished, really! More than 15 hours... not > counted the several hours it lasted to wait for configure to finish, > just for building xmlroff... which is not really a huge package. Maybe you are accessing network paths (// prefix)? Try disabling the network, cards or service. > I expected the whole thing to be about 100 times faster, 1 hour to > run make, well ok that would be ok... anyone can tell me how long it > lasts to build xmlroff on Linux? > > I don't get it. What is the problem? What can I do? Where to look > first? How to fix this disagreeableness? -- Reini Urban -- 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
Win7 64bit, why so slow?
Yes, again... Please help me, I have a new laptop, the fastest piece of hardware I ever owned, and now I am s disappointed because everything on Cygwin is slower than I have ever experienced before. I have compiled a lot of packages, some maybe remember my name, I was Perl maintainer and also maintained some other packages. I can not believe, that my ultra fast 64bit Win7 laptop can not perform better. It is doing nothing all the the time, besides waiting for the output of the next line. I called "make" today at 06:10 today, after configure finished in the night before, now it is 21:25 and the build is not finished, really! More than 15 hours... not counted the several hours it lasted to wait for configure to finish, just for building xmlroff... which is not really a huge package. I expected the whole thing to be about 100 times faster, 1 hour to run make, well ok that would be ok... anyone can tell me how long it lasts to build xmlroff on Linux? I don't get it. What is the problem? What can I do? Where to look first? How to fix this disagreeableness? Mit freundlichen Grüssen, Gerrit -- 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: OpenGL under Cygwin with GtkGlExt
libgl and libglu seem to be installed correctly.. I can compile with those libs at gcc.. So there really maybe a problem with the configure script. Can I maybe download the GtkGlExt lib as binaries? I just found the sources.. -- View this message in context: http://old.nabble.com/OpenGL-under-Cygwin-with-GtkGlExt-tp3118p30003221.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: peflags and STATUS_ACCESS_VIOLATION
On 10/19/2010 12:16 PM, Hadi Hadizadeh wrote: Dear All, I compiled a program under the latest version of Cygwin (1.7.7). But when I run my executable file, I get a STATUS_ACCESS_VIOLATION exception. Are you sure your code isn't buggy? That's usually the sign of a NULL dereference or other bad code. > I tried "peflags --tsaware=true myprogram.exe" and even "peflagsall" (in ash) but none of them could solve the problem. Which makes sense - they solve problems related to the ability to execute a program, but not problems related to bugs in the program once it is executed. > Does anybody know how can I solve this problem? Thanks, Run it under gdb, and figure out where your bad code is. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.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
peflags and STATUS_ACCESS_VIOLATION
Dear All, I compiled a program under the latest version of Cygwin (1.7.7). But when I run my executable file, I get a STATUS_ACCESS_VIOLATION exception. I tried "peflags --tsaware=true myprogram.exe" and even "peflagsall" (in ash) but none of them could solve the problem. Does anybody know how can I solve this problem? 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: OpenGL under Cygwin with GtkGlExt
On Tue, 2010-10-19 at 09:39 -0700, Stedy wrote: > Yes, Im using X11.. As you must, since our GTK+ is also X11. > In the meanwhile I've installed every GL package I found at Cygwin setup > incl. libGL-devel and libGL1 but I still get the error :-/ Building GtkGLExt also requires libGLU-devel, and of course libgtk2.0-devel. Binary packages are available from Cygwin Ports, but if you want to build it yourself, you will also need a patch: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=gnome/gtkglext1.0 HTH, 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
Re: OpenGL under Cygwin with GtkGlExt
Stedy wrote: > Hi AndrÃ, > > Yes, Im using X11.. > In the meanwhile I've installed every GL package I found at Cygwin setup > incl. libGL-devel and libGL1 but I still get the error :-/ > do I have to manual install this libs? > I just run cygwin setup process If you have installed the packages, you have installed the libs. This seems to be a configure script problem. You will have to discuss this with the GtkGlExt author(s). André Bleau, Cygwin's volunteer OpenGL package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not to directly to 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: OpenGL under Cygwin with GtkGlExt
Hi André, Yes, Im using X11.. In the meanwhile I've installed every GL package I found at Cygwin setup incl. libGL-devel and libGL1 but I still get the error :-/ do I have to manual install this libs? I just run cygwin setup process -- View this message in context: http://old.nabble.com/OpenGL-under-Cygwin-with-GtkGlExt-tp3118p30002045.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: OpenGL under Cygwin with GtkGlExt
Stedy wrote: > Hi, Hi Stedy, > > I'm using Cygwin under Windows Vista and have installed the OpenGL Libs at > Cygwin setup. > > Now im trying to configure GtkGlExt (with ./configure). But I get a message > "GL not installed".. Are you configuring to use OpenGL in an X11 window? If yes, you need the libGL* packages, not the opengl package, which is meant for native Win32 graphics. > > Can you help me? > > Regards André Bleau, Cygwin's volunteer OpenGL package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not to directly to 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: side effects after installing gcc-3.4.4.999
I've got a simple solution that I am not sure if it has been mentioned here. take the link g++, and rename it g++.bak and make a copy of the g++ you want to use g++-3 or 4 and rename it g++ No more access denied problem. Ted Akakima wrote: > > After updating gcc in my cygwin installation, i discovered > that i cannot run gcc.exe from the native winxp console (cmd.exe). > > gcc.exe has been replaced by gcc-3.exe. > > Of course, this works fine under bash and ash, but it does not work > anymore > under cmd.exe. > > since i prefer to work under cmd.exe. i tried to fix this problem by: > adding .LNK to PATHEXT > and adding /usr/bin/alternatives to the PATH > > and now if i type "gcc", cmd finds gcc-3.exe and launch it. > But, this is not perfect. gcc (or someone else) wait until i press > enter to continue. > > Anybody knows a better solution ? > > I would prefer not to be forced to use bash. > > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > > -- View this message in context: http://old.nabble.com/side-effects-after-installing-gcc-3.4.4.999-tp22282325p30001579.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: Sending signals to a subprocess
On Tue, Oct 19, 2010 at 09:32:34AM -0400, Ken Brown wrote:
>On 10/18/2010 4:18 PM, Christopher Faylor wrote:
>> On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
>>> On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
> On 10/16/2010 1:17 PM, Ken Brown wrote:
>> I could use some help fixing a longstanding bug in the Cygwin build of
>> emacs, in which emacs is unable to send signals to subprocesses. A
>> symptom from the user's point of view is that one cannot interrupt a
>> process in shell mode by typing C-c C-c. I've found a workaround that
>> handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
>> as I'm fixing this, I'd like to do it right and figure out how to handle
>> all signals.
>>
>> This boils down to finding the right process group ID to pass to 'kill'.
>> On systems that have TIOCGPGRP, emacs uses the following code (in
>> src/process.c) to get this ID:
>>
>> /* Return the foreground process group for the tty/pty that
>>the process P uses. */
>> static int
>> emacs_get_tty_pgrp (p)
>> struct Lisp_Process *p;
>> {
>> int gid = -1;
>>
>> #ifdef TIOCGPGRP
>> if (ioctl (p->infd, TIOCGPGRP,&gid) == -1&&! NILP
>> (p->tty_name))
>> {
>> int fd;
>> /* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
>> master side. Try the slave side. */
>> fd = emacs_open (SDATA (p->tty_name), O_RDONLY, 0);
>>
>> if (fd != -1)
>> {
>>ioctl (fd, TIOCGPGRP,&gid);
>>emacs_close (fd);
>> }
>> }
>> #endif /* defined (TIOCGPGRP ) */
>>
>> return gid;
>> }
>>
>> What's the right way to do this in Cygwin?
>
> I guess it's clear from the context, but I should have said that the
> problem only arises when emacs has to communicate with the subprocess
> through a tty that is not the controlling tty of emacs. So tcgetpgrp()
> doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from "man 4 tty_ioctl" on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group
on this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
>>>
>>> The difference is that, according to POSIX, tcgetpgrp is required to
>>> fail unless fd references the controlling terminal of the calling
>>> process. Ironically, Cygwin's tcgetpgrp used to succeed in this
>>> situation until Corinna fixed it a year ago:
>>>
>>>http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
>>
>> Yes, I got that but TIOCGPGRP seems to have that same limitation on
>> Linux. That's why I quoted the above man page. A simple test case
>> (tm) seems to bear out the fact that the two are the same.
>
>I just tried an experiment, and now I'm thoroughly confused. I inserted
>"#undef TIOCGPGRP" into process.c in the emacs source and rebuilt it on
>Linux. [Technical note if anyone wants to try to reproduce this: I also
>inserted "#undef SIGNALS_VIA_CHARACTERS", since SIGNALS_VIA_CHARACTERS
>provides an alternate method of sending signals to processes; this is in
>fact my workaround on Cygwin.] Then trying to kill a process running in
>an emacs shell with C-c C-c fails the same way it fails in Cygwin. So
>somehow TIOCGPGRP is doing the right thing under Linux in the emacs code
>above, in spite of its limitations. I don't understand why. When I get
>a chance (not today), I'll try running emacs under gdb to see if I can
>figure out what's going on.
>
>I guess this should mean that if you implement TIOCGPGRP in Cygwin and
>make it emulate Linux, it should work for emacs in Cygwin too. I can
>also try to see if tcgetpgrp works instead of TIOCGPGRP. I'm
>embarrassed to say that I didn't actually try this before, because my
>understanding of the documentation was that it wouldn't work. You can
>see I don't think like a programmer.
As I mentioned, my test case shows that when run on Linux, TIOCPGRP and
tcgetpgrp are the same. So, given that, if I implemented TIOCPGRP it
wouldn't solve your problem.
How about if you modify the test case that I provided and show me what's
different? Is this an issue with opening the wrong side of a pty, like
trying to run tcgetpgrp on the master rather than the slave or vice versa?
cgf
Re: Sending signals to a subprocess
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p->infd, TIOCGPGRP,&gid) == -1&&! NILP (p->tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p->tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,&gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from "man 4 tty_ioctl" on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
I just tried an experiment, and now I'm thoroughly confused. I inserted
"#undef TIOCGPGRP" into process.c in the emacs source and rebuilt it on
Linux. [Technical note if anyone wants to try to reproduce this: I also
inserted "#undef SIGNALS_VIA_CHARACTERS", since SIGNALS_VIA_CHARACTERS
provides an alternate method of sending signals to processes; this is in
fact my workaround on Cygwin.] Then trying to kill a process running in
an emacs shell with C-c C-c fails the same way it fails in Cygwin. So
somehow TIOCGPGRP is doing the right thing under Linux in the emacs code
above, in spite of its limitations. I don't understand why. When I get
a chance (not today), I'll try running emacs under gdb to see if I can
figure out what's going on.
I guess this should mean that if you implement TIOCGPGRP in Cygwin and
make it emulate Linux, it should work for emacs in Cygwin too. I can
also try to see if tcgetpgrp works instead of TIOCGPGRP. I'm
embarrassed to say that I didn't actually try this before, because my
understanding of the documentation was that it wouldn't work. You can
see I don't think like a programmer.
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
OpenGL under Cygwin with GtkGlExt
Hi, I'm using Cygwin under Windows Vista and have installed the OpenGL Libs at Cygwin setup. Now im trying to configure GtkGlExt (with ./configure). But I get a message "GL not installed".. Can you help me? Regards -- View this message in context: http://old.nabble.com/OpenGL-under-Cygwin-with-GtkGlExt-tp3118p3118.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: gfortran 4.3.4: NINT() intrinsic triggers undefined references to '_llround' and '_llroundf'
--- Mar 19/10/10, Cornelis de Gier ha scritto: > Data: Martedì 19 ottobre 2010, 12:54 > 2010/10/18 Marco Atzeri : > > > next cygwin release/snapshot will solve it. > > > > http://cygwin.com/ml/cygwin-patches/2010-q4/msg5.html > > > > $ gfortran -Wall testninit.f90 -o testninit > > > > $ ./testninit > > 2 > > 1 > > > > Marco > > Great, thank you for the patch. Next cygwin release llround > functions > may be removed from this list then: > http://cygwin.com/cygwin-api/std-notimpl.html > > > Cornelis > that page need an update. I will look later as also the C99 complex, except long double, are now available and they should be removed from the list. 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
Unusual comments from the setup routine
Hello! For reasons that need not concern us here I needed to reinstall Cygwin. After running setup (again) to remove a package I know I do not need, I saw this on the last screen provided by the program: "Package: No package boxes.sh exit code 2 exim.sh exit code 1 mined.sh exit code 1" Would someone correct me if I presume too much here? Simply that there is nothing to worry about there. - Gregg C Levine gregg.drwho8 atsign gmail.com "This signature fought the Time Wars, time and again." -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: ocaml-3.12.0-4
Version 3.12.0-4 of ocaml has been uploaded. OCaml is a functional programming language with imperative features, objects, and modules. This update splits the package into the base system and the camlp4 subsystem, and adds packages for the emacs mode and the (optional) compiler libraries. -- Damien Doligez *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gfortran 4.3.4: NINT() intrinsic triggers undefined references to '_llround' and '_llroundf'
2010/10/18 Marco Atzeri : > next cygwin release/snapshot will solve it. > > http://cygwin.com/ml/cygwin-patches/2010-q4/msg5.html > > $ gfortran -Wall testninit.f90 -o testninit > > $ ./testninit > 2 > 1 > > Marco Great, thank you for the patch. Next cygwin release llround functions may be removed from this list then: http://cygwin.com/cygwin-api/std-notimpl.html Cornelis -- 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
Grants for business owners
Let me introduce myself I'm Sally, I work with Window firms all through the US. We supply Grant Help for Small Company. Did you understand that there is more than 288 billion dollars offered in Grant income accessible for business enterprise owners? The provision of this funds is subject to exacting standards. My family continues to be involved in assorted authorities applications for over 20 many years. We have aided quite a few businesses reach a new degree of solvency. I can allow you understand in less than a 5 minutes chat if you've any eligibility for these money. There's no cost for an analysis. Please return this e-mail with: Your Name Company name How long you have been in business? How much do you require? Telephone number Finest time to call Sally Trudeau -- 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: getting 'clear' to work in Emacs shell
On 19.10.2010 11:55, Oleksandr Gavenko wrote: shell-mode does not understand terminal ESC sequences. For example there exist special functions: ansi-color-for-comint-mode-on ansi-color-for-comint-mode-off I want say that some useful terminal ESC sequences Emacs shell-mode can handle properly. Other like generated by clear is not. But in shell-mode Emacs set TERM=dumb, from manual for 'clear' it uses terminfo db, so must not generate any output. So or your terminfo db damaged or you have invalid TERM env var in shell-mode (for example it can be set in ~/.bashrc). -- 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: getting 'clear' to work in Emacs shell
On 18.10.2010 16:53, Jeff Rancier wrote: GNU Emacs 21.3.1 (i386-msvc-nt5.1.2600) of 2003-03-27 on buffy GNU bash, version 3.2.51(24)-release (i686-pc-cygwin) CYGWIN_NT-5.1 1.7.7(0.230/5/3) 2010-08-31 09:58 Microsoft Windows XP Pro - Version 2002, SP3 The 'clear' work's in a Cygwin Bash session, c106...@usliny2r86krp8 ~ $ alias clear alias clear='cat ~/.cls' c106...@usliny2r86krp8 ~ $ less .cls ESC[2J .cls (END) But doesn't within Emacs: C-z runs the command shell which is an interactive compiled Lisp function in `shell'. (shell&optional BUFFER) All I get within an Emacs shell session is the following, without clearing the screen. Is there some envionment variable I need to set here? bash-3.2$ clear [2J bash-3.2$ As I understand you run M-x shell and type 'clear RET' and expect that Emacs buffer cleared and contain only new prompt. shell-mode does not designed to work as terminal. Try use M-x term witch try emulate terminal behavior (thus allow run ncurses apps). I run Emacs in 'mintty', type M-x term, I was asked for shell, select default '/bin/sh', type RET and get prompt. Under prompt type 'ls', get list of file, type 'clear', get error sh-3.2$ clear 'eterm-color': unknown terminal type next type 'export TERM=xterm RET' and 'clear'. I get 'sh-3.2$' prompt and all previous output cleared. As I understand that is you want. shell-mode does not understand terminal ESC sequences. For example there exist special functions: ansi-color-for-comint-mode-on ansi-color-for-comint-mode-off When you type in shell-mode 'ls --color' with ansi-color-for-comint-mode-off you get such output: ^[[0m^[[01;34mApplication Data^[[0m ^[[01;34mNetHood^[[0m ^[[01;32mntuser.ini^[[0m ^[[01;34mSendTo^[[0m \ ^[[01;34mМои документы^[[0m When you type in shell-mode 'ls --color' with ansi-color-for-comint-mode-on you get colorized output like in terminal: Application Data NetHood ntuser.ini SendToМои документы -- 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
