Uncompilable 'setup' program !
Hello poeple ! Currently, for my diploma work, I'm working on a port of RPM-4.1 for Cygwin (which is actually nearly functionnal...), and I'd like to modify the setup program to enable installations of programs in RPM format (hopefully!). But here comes my problem : I just can't recompile setup-2.249.2.5-1-src.tar.bz2 (which is expanded into setup-2.249.2.5.tar.bz2, and then into setup-0), even whithout having changed anything in the source. On cygwin (DLL version: 1.3.12, Host: Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2), I got the following error message : make[2]: Entering directory `/cygdrive/d/setup/setup-0_cygwin' source='archive.cc' object='archive.o' libtool=no \ depfile='.deps/archive.Po' tmpdepfile='.deps/archive.TPo' \ depmode=gcc /bin/bash ./cfgaux/depcomp \ g++ -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\setup\ -DVERSION=\0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ERRNO_H=1 -DHAVE_STRING=1 -DHAVE_STRING_H=1 -I. -I. -I./bz2lib -I./libgetopt++/include -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -g -O2 -c -o archive.o `test -f 'archive.cc' || echo './'`archive.cc In file included from archive.cc:31: io_stream.h:34: conflicting types for `typedef long int ssize_t' /usr/include/sys/types.h:164: previous declaration as `typedef _ssize_t ssize_t' make[2]: *** [archive.o] Error 1 make[2]: Leaving directory `/cygdrive/d/setup/setup-0_cygwin' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/d/setup/setup-0_cygwin' make: *** [all] Error 2 I just did a './configure' and then a 'make'. What am I doing wrong ? In which environment did Mr Delorie build his 'setup' tool ? Thanks in advance Yann Crausaz --- Yann Crausaz EIVD - University of Applied Sciences of Western Switzerland Route de Cheseaux 1 1400 Yverdon-les-Bains Switzerland mailto:yann.crausaz;eivd.ch mailto:yann_crausaz;bluemail.ch ---
Re: Uncompilable 'setup' program !
Subject: Uncompilable 'setup' program ! From: Yann Crausaz [EMAIL PROTECTED] Currently, for my diploma work, I'm working on a port of RPM-4.1 for Cygwin (which is actually nearly functionnal...), and I'd like to modify the setup program to enable installations of programs in RPM format (hopefully!). But here comes my problem : I just can't recompile setup-2.249.2.5-1-src.tar.bz2 (which is expanded into setup-2.249.2.5.tar.bz2, and then into setup-0), even whithout having changed anything in the source. io_stream.h:34: conflicting types for `typedef long int ssize_t' /usr/include/sys/types.h:164: previous declaration as `typedef _ssize_t ssize_t' I just did a './configure' and then a 'make'. What am I doing wrong ? In which environment did Mr Delorie build his 'setup' tool ? Robert Collins is primary setup maintainer now. That error is a bug. Setup can be compiled in 2 modes: -mno-cygwin (since obviously setup can't depend on cygwin, since it hasn't been installed yet), and normal Cygwin dependant mode (some people prefer to debug it that way). The Cygwin mode is broken slightly, through lack of maintenance. See http://sources.redhat.com/ml/cygwin-apps/2002-11/msg00085.html for a patch. Also, setup has changed a lot in CVS since then. There is one bug: See http://sources.redhat.com/ml/cygwin-apps/2002-11/msg00128.html But it only impacts autoselection. Your descision to tolerate the bug until it is fixed, or to need to forward-port your changes to the latest version of setup. Max.
Re: Uncompilable 'setup' program !
On Wed, 2002-11-13 at 21:28, Max Bowsher wrote: Subject: Uncompilable 'setup' program ! From: Yann Crausaz [EMAIL PROTECTED] Currently, for my diploma work, I'm working on a port of RPM-4.1 for Cygwin (which is actually nearly functionnal...), and I'd like to modify the setup program to enable installations of programs in RPM format (hopefully!). Neato. Also, setup has changed a lot in CVS since then. There is one bug: See http://sources.redhat.com/ml/cygwin-apps/2002-11/msg00128.html But it only impacts autoselection. Your descision to tolerate the bug until it is fixed, or to need to forward-port your changes to the latest version of setup. I *strongly* suggest that CVS HEAD be used for new development. The current release is a) feature frozen - your changes won't be accepted. b) relatively speaking, very old. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: initscripts package available for review/upload
On Tue, Nov 12, 2002 at 07:31:29PM -0500, Sergey Okhapkin wrote: I did it already, but I can change the script if that's incorrect. I'd like to avoid introduction of *-config script... I think (but I'm not sure) people are most confused if their config files are changed w/o further notice. We should avoid that. However, in case of the inittab stuff, this could be accomplished most easily by a postinstall script. INstead of an /etc/inittab file have a /etc/inittab.default (or so) nd copy it to /etc/inittab if it doesn't already exist. That's all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin;cygwin.com Red Hat, Inc.
Cygwin setup and mounts
What are the reasons for setup program to create these mounts unconditionally (file install.cc, function do_install_thread)? create_mount (/usr/bin, cygpath (/bin), istext, issystem); create_mount (/usr/lib, cygpath (/lib), istext, issystem); The resulting cygwin installation has a mix of /usr/bin and /bin files in /bin (the same for /lib) and empty /usr/bin and /usr/lib directories. Sergey Okhapkin
Re: Cygwin setup and mounts
Earnie Boyd wrote: Hi Sergei, You must have been away too long. ;) 1) Wrong list. ^ Earnie, The last time I checked, this was the appropriate list for setup-related discussion. Cheers, Nicholas
Re: cygwin setup and mounts
On Wed, Nov 13, 2002 at 02:42:44PM -0500, Nicholas Wourms wrote: Earnie Boyd wrote: Hi Sergei, You must have been away too long. ;) 1) Wrong list. ^ Earnie, The last time I checked, this was the appropriate list for setup-related discussion. Yes. Setup bug reports and design discussions are ok here. Rehashing the Why did you set up the mounts this way? discussion really isn't, though. Unless you have a death wish, of course. cgf
Re: initscripts package available for review/upload
Creating a new inittab.default will not activate the package. That's why I prefer to save an existing inittab and create a new one. Sergey Okhapkin Somerset, NJ - Original Message - From: Corinna Vinschen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 7:30 AM Subject: Re: initscripts package available for review/upload On Tue, Nov 12, 2002 at 07:31:29PM -0500, Sergey Okhapkin wrote: I did it already, but I can change the script if that's incorrect. I'd like to avoid introduction of *-config script... I think (but I'm not sure) people are most confused if their config files are changed w/o further notice. We should avoid that. However, in case of the inittab stuff, this could be accomplished most easily by a postinstall script. INstead of an /etc/inittab file have a /etc/inittab.default (or so) nd copy it to /etc/inittab if it doesn't already exist. That's all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin;cygwin.com Red Hat, Inc.
Re: initscripts package available for review/upload
Sergey Okhapkin [EMAIL PROTECTED] wrote: Creating a new inittab.default will not activate the package. That's why I prefer to save an existing inittab and create a new one. /etc/inittab should absolutely not be packaged as such, because otherwise setup will delete it (and may therefore destroy user configuration) at package reinstalls/upgrades/uninstalls. The configfile.default + postinstall script copying configfile.default to configfile if it does not exist is a reasonably well accepted Cygwin packaging method. Why not do that? Max.
Re: initscripts package available for review/upload
--- Sergey Okhapkin [EMAIL PROTECTED] wrote: I see no reason to release a new version just to rename a file, I'd like to get some feedback from users first. Well, if I count as a user I'd really like to avoid filename collisions like this. But when would a new version be released otherwise? I suppose waiting a couple of days to see if the mailing list explodes with posts is OK, but it's been a couple of days now. That's why I want to make initscripts package available via setup ASAP. Agreed. I have tested this package on Win98 and 2000 with no problems. I vote for this package. __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
Re: initscripts package available for review/upload
Sergey Okhapkin wrote: I see no reason to release a new version just to rename a file, I'd like to get some feedback from users first. Moreover, /etc/inittab is very easy and clear file, initscripts package provides a ready-to-use-for-all version of the file. That's why I want to make initscripts package available via setup ASAP. Sergey, you just don't get it. Filename collisions are a BIG deal, and will lead (have led) to major furballs on the main mailing list. Your cavalier attitude about them -- vis a vis: you still advocated the premature uploading of sysvinit even AFTER it was pointed out that it conflicted with a pre-existing package -- my cygutils package. What we REALLY need is a package linter, so these problems are flagged automatically. But that'll be a while. Here's the pattern: 1) you publish sysvinit-1.00. The tarball explicitly contains /etc/inittab. setup.exe records this file as belonging to sysvinit. 2) you publish initscripts-1.00, which ALSO contains /etc/inittab. Setup unpacks it and clobbers the original version (from sysvinit). setup now records /etc/inittab as belonging to initscripts (but it still thinks it ALSO belongs to sysvinit. Setup doesn't yet have a comprehensive database to keep track of conflicts like this) 3) you publish a new version of sysvinit (-1.01 ?) for some other reason -- but while you're making the important change, you also remember to remove its copy of /etc/inittab. Setup, when it installs the new tarball, does this: a) first, look in the database for sysvinit, and deletes all files from the original sysvinit tarball. This includes /etc/inittab -- buh bye. There goes the initscripts version; it's gone. b) then, setup unpacks the new sysvinit tarball. End result: /etc/inittab is gone. This also was the result of the premature uploading of sysvinit in the first place; anyone who installed sysvinit and THEN upgraded cygutils lost last.exe and utmpdump.exe. What *SHOULD* have happened is that you waited until I had a chance to remove last.exe and utmpdump.exe from cygutils, and put that on sourceware. Then, folks would have upgraded cygutils FIRST (removing last.exe and utmpdump.exe), and then installed sysvinit SECOND (thus regaining the lost files). [As it happens, if cygutils were updated and sysvinit were installed during the SAME execution of setup.exe on a user's machine, then there will not be a problem either, because setup uninstalls all packages that are to be upgraded, and then installs any updated/new packages.] Admittedly, this is difficult to coordinate when the packages in question are owned by different people -- even though I gave fair warning on the list that is would be a problem, and that I was acting very rapidly to make it a non-problem. But it's much easier when both packages are owned by the same person -- you! YOU have the power to prevent the scenario above, w.r.t. sysvinit and inittab! YES, sometimes it IS important to release a new package when only a single file changes. It's not like sysinit is a 5MB behemoth download like perl. (Besides, you already have one change to make in sysvinit anyway -- the postinstall snippet I sent you. This makes two.) One other minor niggle: sysvinit contains a number of section 8 manpages for programs that are not included in the sysvinit package (shutdown, reboot, poweroff? halt?). Should those manpages be moved into Corinna's shutdown package, or should Corinna's windows version of shutdown be absorbed into your sysvinit package? But that's between you and Corinna. If status quo w.r.t. those manpages, while confusing, is okay with you two, then I guess that's fine. --Chuck
Re: pine-4.44-3
*** Eduardo Chappa ([EMAIL PROTECTED]) escribio en Oct 7, 2002: :) I am the maintainer of the Pine package. [snip] :) Therefore I am making this the last release of pine-4.44 before :) pine-4.50 I did not think that I would have to take my word back, but I am. A few days ago a denial of service bug was discovered (see bugtraq, I don't have the link off hand). I am releasing a version of Pine which does not suffer from this vulnerability. Please upgrade the new version of Pine. http://www.math.washington.edu/~chappa/cygwin/pine-4.44-4.tar.bz2 http://www.math.washington.edu/~chappa/cygwin/pine-4.44-4-src.tar.bz2 http://www.math.washington.edu/~chappa/cygwin/setup.hint -- Eduardo http://www.math.washington.edu/~chappa/pine/
Re: pine-4.44-3
On Wed, Nov 13, 2002 at 09:15:49PM -0800, Eduardo Chappa wrote: *** Eduardo Chappa ([EMAIL PROTECTED]) escribio en Oct 7, 2002: :) I am the maintainer of the Pine package. [snip] :) Therefore I am making this the last release of pine-4.44 before :) pine-4.50 I did not think that I would have to take my word back, but I am. A few days ago a denial of service bug was discovered (see bugtraq, I don't have the link off hand). I am releasing a version of Pine which does not suffer from this vulnerability. Please upgrade the new version of Pine. http://www.math.washington.edu/~chappa/cygwin/pine-4.44-4.tar.bz2 http://www.math.washington.edu/~chappa/cygwin/pine-4.44-4-src.tar.bz2 http://www.math.washington.edu/~chappa/cygwin/setup.hint Uploaded. FYI, I modified setup.hint slightly. There is no reason to include explicit prev and curr fields when the defaults will do. Also, indenting the ldesc doesn't make sense since if/when it is displayed, it won't be displayed with a leading ldesc: field. Thanks, cgf
an idea for building win32 based xfd
Please let me have your comments on my idea that (Baims to build win32 based x font server which is capable of (Bexporting fonts installed on a Windows machine. (BBy using this server, cygwin/xfree users do not need to (Binstall X-specific fonts aside from Windows fonts. (BThis server is expected to behave as xfd. So any X server (Bwill benefit from this server. (BSince font installation is done in Windows side, almost no (Bfont configuration effort is required in X side. (BI'd like to have your opinion about this. I guess this kind of (Bidea has already poped up in many peoples' mind. (BThere might be a similar project or software proposed by (Bsomeone else before... (BAny comment? (B (BThanks, (BTaishin
RE: Cygwin Connection Tool for Windows
Oh, Cygwin running X-Server on Vmware. What a ...= don't know how to say that :) UPS, havent tested it on XP Yet ;( I will try to fix this as soon as i have installed XP on VMWare ;P Did you get it running on Win2k? ___ Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Emacs in XWin is performing oddly
On Tue, 12 Nov 2002, Jim Drash wrote: I have installed all of the cygwin emacs packages and I now am experiencing problems with emacs with the X server. Launching emaces causes one of the following: 1) the application never displays its window (CPU utilization to 100%) 2) the application displays its window but it is unresponsive (CPU utilization to 100%) 3) About 1 in 4 times it runs correctly even after a clean reboot of the PC Has anyone tested cygwin emacs with linux xserver? Does the same happen?
RE: Cygwin Connection Tool for Windows
On Wed, 13 Nov 2002, Sylvain Petreolle wrote: Oh, Cygwin running X-Server on Vmware. What a ...= don't know how to say that :) UPS, havent tested it on XP Yet ;( I will try to fix this as soon as i have installed XP on VMWare ;P Did you get it running on Win2k? Guess what I'm doing all the time. I have a cross-compiler running on linux and test all cygwin/Cygwin XFree changes in a VmWare. This was the only way to fix some bugs in the cygwin network handling on _very_ old win95. This was _much_ better than breaking my workstation. bye ago
Re: Cygwin Connection Tool for Windows
--- Rasjid Wilcox [EMAIL PROTECTED] a écrit : On Wed, 13 Nov 2002 9:16 pm, Sylvain Petreolle wrote: Oh, Cygwin running X-Server on Vmware. What a ...= don't know how to say that :) Excuse if I made you misunderstand me. Is because of my bad english. But I was really surprised to see someone using VmWare for that. (I'm currently trying to run Cygwin under Wine ;)) And what is wrong with that?? How else do you test Cygwin when you run Linux at home?? (Or, Why dual boot when you can VMWare? ;-) Rasjid. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Emacs in XWin is performing oddly
I have installed all of the cygwin emacs packages and I now am experiencing problems with emacs with the X server. Launching emaces causes one of the following: 1) the application never displays its window (CPU utilization to 100%) 2) the application displays its window but it is unresponsive (CPU utilization to 100%) 3) About 1 in 4 times it runs correctly even after a clean reboot of the PC I have exactly the same problem! I am not sure if this is emacs problem. It looks like new version of XWin have this problem. Emacs in terminal works well. Tried to return to previous versions of X, hm it doesn't work. Now I have real problem so please if someone knows how to avoid this send message. Artur -- Artur Hefczyc[EMAIL PROTECTED] Open Source Developer http://wttools.sourceforge.net/
RE: an idea for building win32 based xfd
Please let me have your comments on my idea that aims to build win32 based x font server which is capable of exporting fonts installed on a Windows machine. By using this server, cygwin/xfree users do not need to install X-specific fonts aside from Windows fonts. This server is expected to behave as xfd. So any X server will benefit from this server. Since font installation is done in Windows side, almost no font configuration effort is required in X side. I'd like to have your opinion about this. I guess this kind of idea has already poped up in many peoples' mind. There might be a similar project or software proposed by someone else before... Any comment? Thanks, Taishin First of all, don't you mean xfs, not xfd? Secondly, how is this different from running the stock xfs that's in the XFree86 distro using free-type to support the Windows fonts? _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Two colormaps ?
Hello, I try to explain my problem. I have a graphic application running fine on HP-UX, and displaying OK on HP workstation. I try to have it display (correctly ! ) on my notebook. The notebook : HP VT 6200 , 15 , 1400x1050 resolution, Windows XP Pro. I installed Cygwin version 1.3.13-2 including XFree 86 4.2.15 twm is the only window manager installed. So I use it. The application (staticcaly linked with X11R5 lib) requires 2 colormaps... and use XtConvertAndStore for various colors. So I need PseudoColor mode, I use : startx -- -emulatepseudo -depth 8 -fullscreen I rlogin Hp-Ux-Workstation and start the application. It is mostly OK but ...: The application opens windows, with drawings... and it is not re-drawn (I have to ask for redraw through an application fonctionality) ! Any suggest whould be welcome ! The other problem is for the drawings requiring the second colormap, of course.. Is there a way to have it ? By now, I have only tried Cygwin, but I expect to install Mandrake 9 soon (but I miss the disk driver !). May be Xf86config will help ? I hope that someone can help me to solve that. (And that my english can be understood) Thanks a lot. Christian
Colormap problems
Hello , I try to explain my problem. I have a graphic application running fine on HP-UX, and displaying OK on HP workstation. I try to have it display (correctly ! ) on my notebook. The notebook : HP VT 6200 , 15 , 1400x1050 resolution, Windows XP Pro. I installed Cygwin version 1.3.13-2 including XFree 86 4.2.15 twm is the only window manager installed. So I use it. The application (staticcaly linked with X11R5 lib) uses XtConvertAndStore for various colors. So I need PseudoColor mode, I use : startx -- -emulatepseudo If I only do that it is the 3rd Visual which is in PseudoColor, and I don't know how to use it ? Is there a bug or a good way to use it ? So I have used startx -- -emulatepseudo -depth 8 -fullscreen I rlogin Hp-Ux-Workstation and start the application. It is mostly OK but XtConvertAndStore do not all succeed : OK for from_value.addr = * #94949494949494 * #dededededede * #adadadadadad * #424242424242 * #bdbdbdbdbdbd * #212121212121 * # * #c2c2c2c2c2c2 * #4fff4fff4fff And fails for * #737373737373 * #636363636363 * #280028002800 Do you have any idea of what can be the reason ? I hope that one can tell me how to solve this. (And that my english can be understood) Thanks Christian
Re: Emacs in XWin is performing oddly
Hmm... I am beginning to wonder if I built the last release with the munged binutils release that was only around for a day or two. That same release of binutils caused my class project code to segfault on startup everytime... updating to the latest bintuils cured the problem. Maybe I will make a new release soon... Harold Artur Hefczyc wrote: I have installed all of the cygwin emacs packages and I now am experiencing problems with emacs with the X server. Launching emaces causes one of the following: 1) the application never displays its window (CPU utilization to 100%) 2) the application displays its window but it is unresponsive (CPU utilization to 100%) 3) About 1 in 4 times it runs correctly even after a clean reboot of the PC I have exactly the same problem! I am not sure if this is emacs problem. It looks like new version of XWin have this problem. Emacs in terminal works well. Tried to return to previous versions of X, hm it doesn't work. Now I have real problem so please if someone knows how to avoid this send message. Artur -- Artur Hefczyc[EMAIL PROTECTED] Open Source Developer http://wttools.sourceforge.net/
Re: Two colormaps ?
Christian, Do NOT use the -emulatepseudo parameter. It does not do what you think it does. ONLY use the following parameters: startx -- -depth 8 -fullscreen Give that a try and report back. Harold Christian SARDIN wrote: Hello, I try to explain my problem. I have a graphic application running fine on HP-UX, and displaying OK on HP workstation. I try to have it display (correctly ! ) on my notebook. The notebook : HP VT 6200 , 15 , 1400x1050 resolution, Windows XP Pro. I installed Cygwin version 1.3.13-2 including XFree 86 4.2.15 twm is the only window manager installed. So I use it. The application (staticcaly linked with X11R5 lib) requires 2 colormaps... and use XtConvertAndStore for various colors. So I need PseudoColor mode, I use : startx -- -emulatepseudo -depth 8 -fullscreen I rlogin Hp-Ux-Workstation and start the application. It is mostly OK but ...: The application opens windows, with drawings... and it is not re-drawn (I have to ask for redraw through an application fonctionality) ! Any suggest whould be welcome ! The other problem is for the drawings requiring the second colormap, of course.. Is there a way to have it ? By now, I have only tried Cygwin, but I expect to install Mandrake 9 soon (but I miss the disk driver !). May be Xf86config will help ? I hope that someone can help me to solve that. (And that my english can be understood) Thanks a lot. Christian
Re: Emacs in XWin is performing oddly
On Wednesday 13 Nov 02, Harold L Hunt II writes: Hmm... I am beginning to wonder if I built the last release with the munged binutils release that was only around for a day or two. That same release of binutils caused my class project code to segfault on startup everytime... updating to the latest bintuils cured the problem. Maybe I will make a new release soon... Harold Harold, I've been posting to the main cygwin list. I don't know about your segfaults, but the spinning described below is reproducible outside of X. Regards, David Artur Hefczyc wrote: I have installed all of the cygwin emacs packages and I now am experiencing problems with emacs with the X server. Launching emaces causes one of the following: 1) the application never displays its window (CPU utilization to 100%) 2) the application displays its window but it is unresponsive (CPU utilization to 100%)
Re: Emacs in XWin is performing oddly
David, Excellent. I believe I can now punt this problem over to the emacs packagers. :) Hey, are you the emacs packager for Cygwin? Harold David Starks-Browning wrote: On Wednesday 13 Nov 02, Harold L Hunt II writes: Hmm... I am beginning to wonder if I built the last release with the munged binutils release that was only around for a day or two. That same release of binutils caused my class project code to segfault on startup everytime... updating to the latest bintuils cured the problem. Maybe I will make a new release soon... Harold Harold, I've been posting to the main cygwin list. I don't know about your segfaults, but the spinning described below is reproducible outside of X. Regards, David Artur Hefczyc wrote: I have installed all of the cygwin emacs packages and I now am experiencing problems with emacs with the X server. Launching emaces causes one of the following: 1) the application never displays its window (CPU utilization to 100%) 2) the application displays its window but it is unresponsive (CPU utilization to 100%)
Re: Emacs in XWin is performing oddly
On Wednesday 13 Nov 02, Harold L Hunt II writes: David, Excellent. I believe I can now punt this problem over to the emacs packagers. No, it's not just emacs, either. Hey, are you the emacs packager for Cygwin? No, just a grateful user. Regards, David
Re: an idea for building win32 based xfs
Thanks for dropping me your comments. First of all, don't you mean xfs, not xfd? That's my mistake. It's xfs. Sorry. Secondly, how is this different from running the stock xfs that's in the XFree86 distro using free-type to support the Windows fonts? I should have stated my point more clearly. I want to get rid of fonts.dir file. mkfontdir doesn't work for me. Although FreeType provides decent font handling functions, win32 API does it better because fonts for Windows are made for Windows use. And I believe cygwin/xfree gains better performance with more exploitation of win32 API. So I have three options: 1) remake mkfontdir using win32 API the easiest work but still inside of fonts.dir world. 2) remake xfs using win32 API don't know how much work should be done but worth to try? 3) replace Xft layer of XFree86 with win32-based code may be...but I'm not an X guru! Fontconfig will eventually resolve this problem but I wonder if win32-based xfs sounds no nice? Taishin
Re: an idea for building win32 based xfs
On Thu, 14 Nov 2002, Kin Taishin wrote: Thanks for dropping me your comments. First of all, don't you mean xfs, not xfd? That's my mistake. It's xfs. Sorry. Secondly, how is this different from running the stock xfs that's in the XFree86 distro using free-type to support the Windows fonts? I should have stated my point more clearly. I want to get rid of fonts.dir file. mkfontdir doesn't work for me. Although FreeType provides decent font handling functions, win32 API does it better because fonts for Windows are made for Windows use. And I believe cygwin/xfree gains better performance with more exploitation of win32 API. So I have three options: 1) remake mkfontdir using win32 API the easiest work but still inside of fonts.dir world. there is a mkfontdir for truetype fonts. (ttmkfdir) 2) remake xfs using win32 API don't know how much work should be done but worth to try? A lot. the fontserver renders the truetype font to a bitmap font if it receives a request for font x at size y. You would have to do this for all characters. 3) replace Xft layer of XFree86 with win32-based code may be...but I'm not an X guru! never. This would break a lot of remote programs which require X11 fonts. Better idea: Take xfs, strip all font handling except TTF and replace reading of fonts.dir by an inline ttmkfdir or build the datastructure using simple w32api TrueType functions. bye ago
Re: rootless mode and mousing to other windows
So how was it that you start rootless mode again? Just kidding. I guess I should have mentioned that I was about to go on vacation for over a week after I sent my last message. My impression of XOpenWin was that it was going to replace the low-level graphic calls from Windows with calls to X. Ambitious, but sounds like a great deal of overhead. This does solve some of the problems you'll run into trying to get Windows to manage X applications, though. I'll have to join the win32-x11 mailing list and see what's happening there. The current direction you're taking is to allow Windows to manage the X windows (please keep this a separate feature from -rootless). I hope somebody's thinking about keeping this compatible with XOpenWin, since there could be some serious benefits to using both together. There are a number of other ways that integration between Windows and X could have been approached, although these are the most straightforward approaches. Both approaches wrap everything of interest, albeit at opposite ends (and the end results look totally different). But right now I'm interested in something much simpler: just removing focus from all windows when X itself loses focus. I've looked at this briefly, but I'd better follow up in another e-mail, rather than causing this thread to fork too much. -Jerry
Re: Lesstif problem ?
Of course: the problem appears after the rebuilding of the Lesstif modules... -- Philippe
About editres
Sorry, the beginning of this thread does not appear on the gname server... To reply to Alexander: well step by step... Start a xterm start editres Menu:Commands|Get Tree Click on the xterm window Select vt100 in the tree Menu:Commands|Show Resource Box OK Click with mouse button 2 (the one in the middle) on color0 You should see black in the window below NOK (there is a black cursor; and no color...) Enter text red NOK (I cannot modify the value) Click on Apply A+ Philippe Bastiani
Re: Adding a german keyboard to a default installation ...
-1- Copy .Xmodmap in your c:\cygwin\etc\X11\xinit -2- Add the following command in the in your startxwin.bat: start /B xmodmap /usr/X11R6/lib/X11/xinit/.Xmodmap A+ Philippe
Re: Adding a german keyboard to a default installation ...
Philippe, Be careful, the ``/B'' is not supported on Windows 95/98/Me. Besides, the startxwin.bat file is now distributed with the ``run.exe'' program that performs the same function as ``start /B'' on all Windows platforms, so you should have said: -2- Add the following command in your startxwin.bat: ``run xmodmap /usr/X11R6/lib/X11/xinit/.Xmodmap'' Harold Philippe Bastiani wrote: -1- Copy .Xmodmap in your c:\cygwin\etc\X11\xinit -2- Add the following command in the in your startxwin.bat: start /B xmodmap /usr/X11R6/lib/X11/xinit/.Xmodmap A+ Philippe
xterm consumes all cpu
[ This is a bug report. ] What happens: boot winxp, start cygwin, run startxwin.bat, and XWin starts normally. If the first action is anything other than to close the xterm, for example, open the desktop menu, then everything will run fine. However, if the first action is to close the xterm, either by typing 'exit' or by clicking on the button in the window bar, the xterm process will consume 100% of my cpu (according to winxp task manager, assuming that was opened previously, because it will take forever to open after.) Interestingly, after killing the zombie xterm and window manager processes in winxp task manager and restart xwin, I can close xterm either by typing exit or clicking on the button in the window bar first and everything will run fine. So, it is only the first time after rebooting that this happens. I've tried this with wmaker, twm and fvwm2 window managers, and the problem persists except for the window manager that forces me to click to place the xterm, because that forces a first action other than to close the xterm. As this is a very strange and unlikely to be stumbled upon, I thought you'd want to know about it. Config attached. [ Thanks, Mark Harig. ] Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Nov 13 13:44:47 2002 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\Program Files\Microsoft SQL Server\80\Tools\Binn\ c:\Program Files\SSH Communications Security\SSH Secure Shell C:\cygwin\usr\X11R6\bin SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\Jake' MAKE_MODE = `unix' PWD = `/home/Jake' USER = `Jake' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Jake\Application Data' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `CYPHER' COMSPEC = `C:\WINDOWS\system32\cmd.exe' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Jake' INCLUDE = `C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\include\' LIB = `C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Lib\' LOGONSERVER = `\\CYPHER' MANPATH = `:/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/usr/bin' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 6 Stepping 5, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0605' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `[\u\H]$ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\Jake\LOCALS~1\Temp' TERM = `cygwin' TMP = `c:\DOCUME~1\Jake\LOCALS~1\Temp' USERDOMAIN = `CYPHER' USERNAME = `Jake' USERPROFILE = `C:\Documents and Settings\Jake' VSCOMNTOOLS = `C:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\' WINDIR = `C:\WINDOWS' _ = `/usr/bin/cygcheck.exe' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS8158Mb 75% CP CS UN PA FC XP d: hd NTFS 24466Mb 48% CP CS UN PA FC STORAGE e: hd FAT 133Mb 32% CPUN DOS f: hd FAT32 2090Mb 17% CPUN SHARE g: hd NTFS 7Mb 99% CP CS UN PA FC End h: cd N/AN/A C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive userbinmode,cygdrive Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cpp.exe Found:
RE: Cygwin Connection Tool for Windows -- new release
Hi Mario, At 07:36 PM 11/13/2002 +0100, Mario Ohnewald wrote: Hi! You can find the new release at www.thelinuxbeat.com -- projects -- cygwin tool Is the website down. I could not connect it. Thanks Stephen Liu The Setup error is fixed and the binary setup file shrank to 2,4MB (from ~8MB). Check it out!!
Re: xfree leaking memory?
On Tue, Nov 05, 2002 at 09:07:56PM -0500, Christopher Faylor wrote: On Tue, Nov 05, 2002 at 05:00:55PM -0500, Harold L Hunt II wrote: It was mentioned that the memory size increased when a new X window (such as an xterm) is opened, but that it does not decrease when that window is destroyed. This indicates one of a few things to me: 1) We are not freeing our window privates (directly or indirectly). This seems plausible, but I don't think our window privates are even 1 kilobyte. I thought I should point out that Cygwin doesn't currently return deallocated memory to the windows pool. So, the heap only gets larger. I thought I should point out that, while I wrote the function in question, the above statement was completely wrong. I was investigating sbrk() operation for an unrelated matter and noticed that it was dutifully releasing unused memory back to the system. I don't know why I thought things behaved any differently than this but I thought I should correct any misperceptions that I caused. cgf
RE: Cygwin Connection Tool for Windows -- new release
nope, it worked for me ;) -Original Message- From: [EMAIL PROTECTED] [mailto:cygwin-xfree-owner;cygwin.com]On Behalf Of Stephen Liu Sent: Thursday, November 14, 2002 3:31 AM To: Mario Ohnewald; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Cygwin Connection Tool for Windows -- new release Hi Mario, At 07:36 PM 11/13/2002 +0100, Mario Ohnewald wrote: Hi! You can find the new release at www.thelinuxbeat.com -- projects -- cygwin tool Is the website down. I could not connect it. Thanks Stephen Liu The Setup error is fixed and the binary setup file shrank to 2,4MB (from ~8MB). Check it out!!
Re: an idea for building win32 based xfs
Thank you for your comments. Alexander Gottwald wrote: there is a mkfontdir for truetype fonts. (ttmkfdir) I forgot to mention. But ttmkfdir does not support TrueType Collection files (*.ttc). And this one is based on FreeType 1, I guess. 2) remake xfs using win32 API don't know how much work should be done but worth to try? A lot. the fontserver renders the truetype font to a bitmap font if it receives a request for font x at size y. You would have to do this for all characters. I will use w32api to render fonts. Anti-aliasing would be a thing to be implemented later. 3) replace Xft layer of XFree86 with win32-based code may be...but I'm not an X guru! never. This would break a lot of remote programs which require X11 fonts. Better idea: Take xfs, strip all font handling except TTF and replace reading of fonts.dir by an inline ttmkfdir or build the datastructure using simple w32api TrueType functions. I see. I'll take the latter approach. I really appreciate your giving me an advice! Thanks, Taishin
Re: ntsec patch 1: uid==gid, chmod, alloc_sd, is_grp_member
On Tue, Nov 12, 2002 at 02:43:51PM -0500, Pierre A. Humblet wrote:
It's just a flaw in is_grp_member() but it's still needed to get the
information about the group membership. is_grp_member() shouldn't check
the current token if the uid isn't myself-uid but otherwise it's ok.
That's the heart of the matter. How do you propose to fix is_grp_member()?
I believe it would involve contacting the PDC for domain users. IMHO it's
unacceptable for performance reasons.
That's why I would only insist on B1), not B3).
I think I found an easy (not necessaily fast) solution which doesn't
involve calling the PDC. Basically we do already depend on /etc/group
heavily so we can do this here, too, IMHO:
Index: grp.cc
===
RCS file: /cvs/src/src/winsup/cygwin/grp.cc,v
retrieving revision 1.56
diff -u -p -r1.56 grp.cc
--- grp.cc 30 Sep 2002 15:17:44 - 1.56
+++ grp.cc 13 Nov 2002 12:34:45 -
-342,6 +342,7 getgroups32 (int gidsetsize, __gid32_t *
read_etc_group ();
if (allow_ntsec
+ strcasematch (username, cygheap-user.name ())
OpenProcessToken (hMainProc, TOKEN_QUERY, hToken))
{
if (GetTokenInformation (hToken, TokenGroups, NULL, 0, size)
This skips the GetTokenInformation and just uses the group info
found in /etc/group. What do you think (besides trying to speed
up getgroups32)?
Why are you turning around the order of the conditionals? I don't see
a reason.
One side is a cygsid, the other is a PSID. I would like the cygsid ==
operator to apply. Apparently the order matters (I didn't know it).
Ah, ok.
to test. I should really replace the last line above by owner_sid == group_sid,
although that returns TRUE if both are NULL, so there is a small difference
(but that case should never arise).
Yep.
+{
+ allow = ~(S_IRGRP | S_IWGRP | S_IXGRP);
This line is essentially superfluous. It's job has been done two lines
before.
Uh?
I'm sorry, I misread the situation.
Why do you remove this check? It's still needed when called by
set_security_attribute(). Or set_security_attribute() needs that check.
set_security_attribute() is only called when a file has acls, which AFAIK
can only happen on NT. So it's OK.
Hmm, you're right.
Why do you remove this check? It's still an interesting info, isn't it?
Yes, it's just for uniformity of interface. None of the other security
routines go into that level of detail when they read passwd.
The information is available from the remaining debug_printf.
Ok.
- owner_sid.debug_print (alloc_sd: owner SID =);
And this one?
I thought that was a debug leftover from the time you introduced the
caching. It's not done anywhere else.
No, I was already often happy to see the SID at this point. It helped
debugging. I'd like to keep it.
if (!AddAce (acl, ACL_REVISION,
ace-Header.AceType == ACCESS_DENIED_ACE_TYPE ?
-(owner_deny ? 1 : 0) : MAXDWORD,
+ace-Mask owner_allow ? owner_off + 1 : owner_off++
Could you explain how that should work? I'm not sure about that.
owner_off is the position of the owner_allow ACE. Since the above
test already filters all related ACEs, the incoming ACE is unrelated
to the owner entry. So why do you check the content of the ACE
against the bits set in the owner_allow mask?!?
Good question. I was puzzled by the original comment and code:
* Add unrelated ACCESS_DENIED_ACE to the beginning but
* behind the owner_deny, ACCESS_ALLOWED_ACE to the end.
The ACCESS_DENIED_ACE part made no sense to me because if there are a
bunch of ACCESS_DENIED following each other, their order doesn't matter.
So I thought that the intention of the original code was that unrelated
ACE should not affect the owner and should thus be positioned after the
ACCESS_ALLOWED_ACE of the owner (i.e. the original author meant
owner_allow, not owner_deny, in the comment).
No, the original code actually knows that the current situation is
either
owner_allow
group_ace
...
or
owner_deny
owner_allow
group_ace
...
The code just differs between having or having not an owner_deny.
All denies are going to the beginning of the ACL, maintaining the
canonical order. The canonical order places user ACEs in from of
group ACEs. To keep this order, the remaining unrelated deny
ACEs are positioned after the owner ACE. That's all and that's
correct, AFAICS.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developermailto:cygwin;cygwin.com
Red Hat, Inc.
Re: ntsec patch 1: uid==gid, chmod, alloc_sd, is_grp_member
Corinna Vinschen wrote: On Tue, Nov 12, 2002 at 02:43:51PM -0500, Pierre A. Humblet wrote: It's just a flaw in is_grp_member() but it's still needed to get the information about the group membership. is_grp_member() shouldn't check the current token if the uid isn't myself-uid but otherwise it's ok. That's the heart of the matter. How do you propose to fix is_grp_member()? I believe it would involve contacting the PDC for domain users. IMHO it's unacceptable for performance reasons. That's why I would only insist on B1), not B3). I think I found an easy (not necessaily fast) solution which doesn't involve calling the PDC. Basically we do already depend on /etc/group heavily so we can do this here, too, IMHO: Yes, that works (most of the time) assuming that /etc/group was build with mkgroup -u. But still, I wouldn't do it, for many reasons: - it adds overhead to stat (), which is already slow - it only considers the gid of the file, but not the unrelated groups that may be present in the file acl, so it doesn't achieve B3 nor B2. - it doesn't help at all if mkgroup wasn't run with -u - it doesn't help at all when the acl was built by cygwin - it doesn't help at all in the usual case where the owner permissions are wider than those of groups - it assumes that all processes with a given uid will always run with the groups derived from /etc/passwd and /etc/group. Although this is typical, it is not necessarily true. setgid () or setgroups () might have been called to change that. - the permission for the owner should reflect the permission given to the uid itself, independently of the groups that the process may or may not be in at the time it accesses a file. - We rely on /etc/group mostly to map gid = sid. Relying on it even more exposes us to user screw up and unexpected behavior. Again, the permission given to a uid in Unix are independent of what's in /etc/group. Unfortunately the Windows and Unix models of security diverge here, and Cygwin is caught in between. I would go for simplicity. - owner_sid.debug_print (alloc_sd: owner SID =); And this one? I thought that was a debug leftover from the time you introduced the caching. It's not done anywhere else. No, I was already often happy to see the SID at this point. It helped debugging. I'd like to keep it. OK, then for consistency let's also debug_print the group SID. Good question. I was puzzled by the original comment and code: * Add unrelated ACCESS_DENIED_ACE to the beginning but * behind the owner_deny, ACCESS_ALLOWED_ACE to the end. The ACCESS_DENIED_ACE part made no sense to me because if there are a bunch of ACCESS_DENIED following each other, their order doesn't matter. So I thought that the intention of the original code was that unrelated ACE should not affect the owner and should thus be positioned after the ACCESS_ALLOWED_ACE of the owner (i.e. the original author meant owner_allow, not owner_deny, in the comment). No, the original code actually knows that the current situation is either owner_allow group_ace ... or owner_deny owner_allow group_ace ... The code just differs between having or having not an owner_deny. All denies are going to the beginning of the ACL, maintaining the canonical order. The canonical order places user ACEs in from of group ACEs. To keep this order, the remaining unrelated deny ACEs are positioned after the owner ACE. That's all and that's correct, AFAICS. OK, what you are proposing is actually close to what the patch I sent at the beginning of October was doing. The existing code behaves as follows: in the first case above it inserts the unrelated deny acl at the top, in the second case it inserts it after the owner_deny. There is no reason for this dual behavior, my October patch was always inserting the unrelated deny acl at the top. The reason why I changed the behavior between October and November is very much related to the discussion on is_grp_member(). The new method insures that the group membership of the owner does not impede a right that was given explicitly given to the owner. In other words, if I chmod a file 700, it shouldn't be the case that the owner only has 600 because she happens to be in some unrelated group that was in the old acl. Doing so (changing the right) is actually closer to the Windows security model than to the Unix one. Pierre
Re: ntsec patch 1: uid==gid, chmod, alloc_sd, is_grp_member
On Wed, Nov 13, 2002 at 11:18:33AM -0500, Pierre A. Humblet wrote: Corinna Vinschen wrote: I think I found an easy (not necessaily fast) solution which doesn't involve calling the PDC. Basically we do already depend on /etc/group heavily so we can do this here, too, IMHO: Yes, that works (most of the time) assuming that /etc/group was build with mkgroup -u. But still, I wouldn't do it, for many reasons: - it adds overhead to stat (), which is already slow It doesn't add any overhead which isn't already there. - it only considers the gid of the file, but not the unrelated groups that may be present in the file acl, so it doesn't achieve B3 nor B2. Agree. - it doesn't help at all if mkgroup wasn't run with -u - it doesn't help at all when the acl was built by cygwin - it doesn't help at all in the usual case where the owner permissions are wider than those of groups The whole thing is a result of the divergence between Win and Posix. Unfortunately it's not always the usual case to have owner permissions wider that group permissions. Often there aren't even owner permissions in the ACL since the permissions are given by only group permissions. And in contrast to Posix the permissions add up to each other. - it assumes that all processes with a given uid will always run with the groups derived from /etc/passwd and /etc/group. Although this is typical, it is not necessarily true. setgid () or setgroups () might have been called to change that. - the permission for the owner should reflect the permission given to the uid itself, independently of the groups that the process may or may not be in at the time it accesses a file. The problem we're trying to circumvent is the following: Owner: User_foo Group: Admins ACL:Admins rwx Everyone r-- Following your suggestion we get: $ ls -l ---rwxr-- 1 User_foo Admins ... bar This doesn't reflect the real permissions of the user at all, not even approximately. The current code creates: $ ls -l rwxrwxr-- 1 User_foo Admins ... bar which reflects the truth somewhat better *and* solves a lot of problems we had in earlier implementations. Granted that the implementation isn't complete. - We rely on /etc/group mostly to map gid = sid. Relying on it even more exposes us to user screw up and unexpected behavior. But that invalidates your attempts to rely more on /etc/group instead of calling LookupAccountSid/Name. That's somewhat chicken-egg, isn't it? I try to avoid time lags by not calling LookupAccountSid means to rely more on the correctness of /etc/group and vice versa... Again, the permission given to a uid in Unix are independent of what's in /etc/group. But not in Windows. Unfortunately the Windows and Unix models of security diverge here, and Cygwin is caught in between. I would go for simplicity. The above ls -l example shows the result if we don't use is_grp_member(). We already had a lot of problems due to this some time ago. I won't return to the old state. I, for one, would better like to improve is_grp_member(). OK, then for consistency let's also debug_print the group SID. Ok. The code just differs between having or having not an owner_deny. All denies are going to the beginning of the ACL, maintaining the canonical order. The canonical order places user ACEs in from of group ACEs. To keep this order, the remaining unrelated deny ACEs are positioned after the owner ACE. That's all and that's correct, AFAICS. OK, what you are proposing is actually close to what the patch I sent at the beginning of October was doing. The existing code behaves as follows: in the first case above it inserts the unrelated deny acl at the top, in the second case it inserts it after the owner_deny. There is no reason for this dual behavior, my October patch was always inserting the unrelated deny acl at the top. The canonical order places user ACEs in from of group ACEs. The reason why I changed the behavior between October and November is very much related to the discussion on is_grp_member(). The new method insures that the group membership of the owner does not impede a right that was given explicitly given to the owner. In other words, if I chmod a file 700, it shouldn't be the case that the owner only has 600 because she happens to be in some unrelated group that was in the old acl. Doing so (changing the right) is actually closer to the Windows security model than to the Unix one. Sigh, yes, the Windows security model. It's lovely, isn't it? If there's any order which would make sense, then it's user_denies user_allows group_denies group_allows everyone but that's probably too sophisticated... I agree that moving the group_denies after the user_allow is closer to what *we* want. I recall a discussion on the cygwin ML (was it in 2000? I don't know) about Cygwin being incompatible to NT4
Re: ntsec patch 1: uid==gid, chmod, alloc_sd, is_grp_member
Oops, there is an error in our examples. The Everyone permission should propagate. Here is the correct output. Pierre A. Humblet wrote: Corinna Vinschen wrote: On Wed, Nov 13, 2002 at 11:18:33AM -0500, Pierre A. Humblet wrote: Corinna Vinschen wrote: I think I found an easy (not necessaily fast) solution which doesn't involve calling the PDC. Basically we do already depend on /etc/group heavily so we can do this here, too, IMHO: Yes, that works (most of the time) assuming that /etc/group was build with mkgroup -u. But still, I wouldn't do it, for many reasons: - it adds overhead to stat (), which is already slow It doesn't add any overhead which isn't already there. If already is before the patch, it scans the group file instead of scanning the token groups. If already is after the patch, it scans the group file instead of scanning the token groups or doing nothing, depending if the uid of the file owner differs from the uid of the process. The problem we're trying to circumvent is the following: Owner: User_foo Group: Admins ACL:Admins rwx Everyone r-- Following your suggestion we get: $ ls -l ---rwxr-- 1 User_foo Admins ... bar This doesn't reflect the real permissions of the user at all, not even approximately. The current code creates: $ ls -l rwxrwxr-- 1 User_foo Admins ... bar which reflects the truth somewhat better *and* solves a lot of problems we had in earlier implementations. The fundamental problem is that there is not enough information to know the real permissions of the owner. Is User_foo a member of Admins or not, at the time she accesses the file ? You make a lot of assumptions in your example. A more detailed description of the way the code works today (before patch) is this: If the process running ls -l is a member of Admins: rwxrwxr-- If the process running ls -l in not a member of Admins: ---rwxr-- and that's the case *whether or not* User_foo is *nominally* a member of Admins. Note the dependency on the process running the command and the absence of dependency on what User_foo actually belongs to !!! Your example implicitly assumes that User_foo is a member of Admins and the ls -l is run by a member of Admins. With the current patch, the output of ls -l would be r--rwxr-- if ls -l is run by somebody else than User_foo It would be rwxrwxr-- if ls -l is run by User_foo if User_foo is *currently* a member of Admins, and r--rwxr-- if ls -l is run by User_foo if User_foo is NOT *currently* a member of Admins To me, that's slightly better than currently. Note also that your example assumes implicitly that the ACL was not created by Cygwin. With the current patch, if the chmod is 774, the acl would be User_foo rwx Adminsrwx Everyone r-- if the chmod is 074, the acl would be User_foo deny rwx Admins rwx Everyone r-- if the chmod is 474 the acl would be User_foo deny -wx User_foo r__ Admins rwx Everyone r-- So there is absolutely no dependency on whether User_foo is or isn't a member of Admins at the time she accesses the file. Everything is completely determined by the chmod and it is not necessary to scan the token groups. Pierre
Re: ioctl.cc fix
On Mon, Nov 04, 2002 at 07:17:51PM -0500, Sergey Okhapkin wrote: I see no output from debug_printf (returning %d, res); in trace file without this fix... gcc bug? 2002-11-04 Sergey Okhapkin [EMAIL PROTECTED] * ioctl.cc (ioctl): Add default case. I reorganized this function slightly into something I think makes a little more sense. It should solve this problem. Thanks for the heads up. Did you see the serial issues that were reported in the cygwin mailing list, btw? cgf
Re: ioctl.cc fix
I remember only one message about a serial port troubles with W98. Did you see something else? Sergey Okhapkin Somerset, NJ - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 5:37 PM Subject: Re: ioctl.cc fix On Mon, Nov 04, 2002 at 07:17:51PM -0500, Sergey Okhapkin wrote: I see no output from debug_printf (returning %d, res); in trace file without this fix... gcc bug? 2002-11-04 Sergey Okhapkin [EMAIL PROTECTED] * ioctl.cc (ioctl): Add default case. I reorganized this function slightly into something I think makes a little more sense. It should solve this problem. Thanks for the heads up. Did you see the serial issues that were reported in the cygwin mailing list, btw? cgf
Re: ioctl.cc fix
On Wed, Nov 13, 2002 at 06:23:52PM -0500, Sergey Okhapkin wrote: I remember only one message about a serial port troubles with W98. Did you see something else? That was it. Subject: Serial port problems with cygwin1.dll 1.3.15 on Win98SE cgf
Re: ioctl.cc fix
I think the recent changes in fhandler_serial uncovered some old bugs... I'll try to investigate. Sergey Okhapkin Somerset, NJ - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 13, 2002 6:44 PM Subject: Re: ioctl.cc fix On Wed, Nov 13, 2002 at 06:23:52PM -0500, Sergey Okhapkin wrote: I remember only one message about a serial port troubles with W98. Did you see something else? That was it. Subject: Serial port problems with cygwin1.dll 1.3.15 on Win98SE cgf
Re: ntsec patch 1: uid==gid, chmod, alloc_sd, is_grp_member
On Wed, Nov 13, 2002 at 10:35:09PM -0500, Pierre A. Humblet wrote: At 05:50 PM 11/13/2002 +0100, Corinna Vinschen wrote: The above ls -l example shows the result if we don't use is_grp_member(). We already had a lot of problems due to this some time ago. I won't return to the old state. I, for one, would better like to improve is_grp_member(). Hello Corinna, Sorry, didn't respond to that paragraph in my previous e-mail. I agree that is_grp_member () is useful and withdraw my suggestion to eliminate it. I have nothing useful to add here other than the fact that I am really loving this dialog. I like to see things being hashed out like this. Pierre, I really appreciate your delving into issues here. And, of course I appreciate all that Corinna has done with ntsec. I am sure that she regrets ever listening to me when I suggested that she do something with Windows permissions years ago. Not that I am trying to insert any claim to helping with ntsec. This is all a black box to me. Anyway, I think between the two of you, we'll eventually have things working as well as humanly possible on Windows. I'm happy to see you working on these issues. My 2c. cgf
RE: Cygwin Emacs-X uses 99% of cpu
I have the same problem. Here is strace output (the part I found interesting :)): 139 22504711 [main] emacs 2192 mount_info::conv_to_win32_path: src_path /home/pavel, dst C:\cygwin\home\pavel, flags 0xA, rc 0 482 22505193 [main] emacs 2192 symlink_info::check: not a symlink 177 22505370 [main] emacs 2192 symlink_info::check: 0 = symlink.check (C:\cygwin\home\pavel, 0x22E318) (0xA) 151 22505521 [main] emacs 2192 path_conv::check: root_dir(C:\), this-path(C:\cygwin\home\pavel\.Xdefaults), set_has_acls(8) 218 22505739 [main] emacs 2192 dtable::build_fhandler: fd 6, fh 0x615D0A30 149 22505888 [main] emacs 2192 fhandler_base::open: (C:\cygwin\home\pavel\.Xdefaults, 0x10) query_open 0 533 22506421 [main] emacs 2192 fhandler_base::open: 0x = CreateFile (C:\cygwin\home\pavel\.Xdefaults, 0x8000, 0x7, 0x22E758, 0x3, 0x280, 0) 220 22506641 [main] emacs 2192 seterrno_from_win_error: /netrel/src/cygwin-1.3.15-2/winsup/cygwin/fhandler.cc:457 windows error 2 148 22506789 [main] emacs 2192 geterrno_from_win_error: windows error 2 == errno 2 158 22506947 [main] emacs 2192 fhandler_base::open: 0 = fhandler_base::open (C:\cygwin\home\pavel\.Xdefaults, 0x10) 144 22507091 [main] emacs 2192 fhandler_disk_file::open: 0 = fhandler_disk_file::open (C:\cygwin\home\pavel\.Xdefaults, 0x0) 150 22507241 [main] emacs 2192 open: -1 = open (/home/pavel/.Xdefaults, 0x0) 2175 22509416 [win] emacs 2192 wndproc 275 WM_TIMER 1 0 214 22509630 [win] emacs 2192 kill: kill (2192, 14) 138 22509768 [win] emacs 2192 sig_send: pid 2192, signal 14, its_me 1 After this it repeats the follwing until I have chance to kill emacs: 141 22509909 [sig] emacs 2192 wait_sig: awake 219 22510128 [sig] emacs 2192 wait_sig: processing signal 14 106 22510234 [sig] emacs 2192 wait_sig: Got signal 14 121 22510355 [sig] emacs 2192 sig_handle: signal 14 108 22510463 [sig] emacs 2192 sig_handle: signal 14, about to call 0x201240A4 125 22510588 [sig] emacs 2192 setup_handler: suspending mainthread 187 22510775 [win] emacs 2192 sig_send: Waiting for thiscomplete 0xB4 210 22510985 [sig] emacs 2192 interruptible: pc 0x77E9E8BB, h 0x77E8, interruptible 1, testvalid 1 180 22511165 [sig] emacs 2192 interruptible: pc 0x77E9E8BB, h 0x77E8, interruptible 0, testvalid 0 131 22511296 [sig] emacs 2192 setup_handler: couldn't send signal 14 112 22511408 [sig] emacs 2192 setup_handler: ResumeThread returned 1 117 22511525 [sig] emacs 2192 setup_handler: returning 0 103 22511628 [sig] emacs 2192 sig_handle: returning 0 121 22511749 [sig] emacs 2192 wait_sig: looping Total file size is about 50Mb (could not kill it earlier) and repeating part is about 70% of the file. Looks like emacs gets flooded by timer signals. -Original Message- From: Igor Pechtchanski [mailto:pechtcha;cs.nyu.edu] Sent: Wed, November 13, 2002 2:41 AM To: Huang. Cc: [EMAIL PROTECTED] Subject: Re: Cygwin Emacs-X uses 99% of cpu On Wed, 13 Nov 2002, Huang. wrote: J. Scott Edwards [EMAIL PROTECTED] wrote: [snip] Oh! I have this problem too. For the archives: This is an example of a completely useless message. It doesn't add anything at all to the discussion, and takes up list bandwidth. Attaching the output of cygcheck would have made it marginally useful (i.e., reporting that the problem can be reproduced on a particular configuration). A good contribution would have been to run emacs under strace, for example, and provide the output (hopefully bzipped, preferably with repeated patterns removed, ideally with some analysis attached). Another would be to run emacs under gdb, break execution when in 100% cpu mode, and post the stack trace. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Water molecules expand as they grow warmer (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bug with installing tetex-base 20020911-1
Nicolai Josuttis [EMAIL PROTECTED] writes: The problem might be caused by an error message I get when I install tetex-base 20020911-1. ... readlink: not found Yes, it is. You should (re)install the cygutils package, it contains readlink. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pico and nano: number of lines displayed
Actually there is something going on here. I reverted to an earlier version of Cygwin and even in a non-fullscreen rxvt environment, any of nano, pico and vim use the entire available depth of the window to display the text file being edited (so that for instance in pico and nano the Help menu appears at the bottom of the page and 50+ lines of the file are visible). The latest current version of Cygwin now displays only 20 lines of the file being edited to screen, exactly as in a basic bash window. Sorry not to be more specific about when the change occurred, but I think it is absolutely recent. I use this size of window for these editors the whole time, and the altered presentation caught my eye immediately. Unfortunately all of cygwin, login and Goodness knows what have been updated recently and I am not competent to isolate cause, only consequence! (Surely somebody out there uses viim in a rxvt windows and has also noticed this difference, yesterday or the day before??) Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pico and nano: number of lines displayed
Sorry, but it works fine for me with pico/nano in an rxvt (2.7.2.14) window, with cygwin 1.3.15.2. Can you describe your problem in any more detail? Thank you, Robert. I've done some more fiddling about. Please could you try starting up using C:\Cygwin\bin\rxvt.exe -geometry 80x58+0+0 -tn cygwin Do you get a $ prompt and find you are in /usr/bin? Now type man something. Works fine. Response fills page. Navigates fine using arrow keys. Then type login yourusername at the $ prompt followed again by man something. Now the response starts halfway down the page and navigation keys throw the user all over the place, with visible ESC sequences, etc. Either there's something wrong with login? or I need to re-construct my .bash_profile, .bashrc and .inputrc files? (But why?) Thank you too to other readers. I am very sorry if it turns out I am filling the list with what turns out to be a piece of daft local mismanagement. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Text problems with Cygwin 1.1.14 and TinyFugue
On Wednesday 13 November 2002 07:32 am, Jonathan Fosburgh wrote: On Tuesday 12 November 2002 09:10 pm, Jeremy Hetzler wrote: When I tested under bash that was using the Cygwin console, which is cmd.exe. HOwever, when I get a chance, I will reinstall 1.1.15 and try from a command prompt with no Cygwin shell, at least for comparison. Same problem from the DOS prompt. Also, I saw the same thing with the most recent snapshot of cygwin1.dll (11/6). While playing around, I did notice that the characters I typed wound up being passed to the shell after I killed tf. -- Jonathan Fosburgh AIX/SAN Administrator Communications and Computer Services UT MD Anderson Cancer Center Houston, TX IBM Certified Specialist - AIX v4.3 System Administration -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygipc ENOSYS patch (was Re: cygipc-1.13pre1)
Chuck,
On Tue, Nov 12, 2002 at 02:44:45PM -0500, Charles Wilson wrote:
The attached src tarball contains cygipc-1.13pre1. It has been
reverted to the 32bit key_t treatment (e.g. pre-1.12), but other
improvements in 1.12 remain. Please generate your ENOSYS patches --
if there are more beyond has been posted on the list -- against this.
That'll make my job easier.
My patch (against cygipc-1.13pre1) changes the following cygipc
functions to return ENOSYS instead of EACCES if ipc-daemon is not
running:
msgctl()
msgget()
msgrcv()
msgsnd()
semctl()
semget()
semop()
shmat()
shmctl()
shmget()
shmdt()
Since I could only (easily) test semget() and shmget() under PostgreSQL,
I decided to write a simply test program, cygtest.cc, to exercise all of
my cygipc changes.
Attached are the following files:
o cygipc-1.13pre1.patch: ENOSYS patch
o cygipc-1.13pre1.ChangeLog: corresponding ChangeLog entry
o cygtest.cc: test program
o cygtest.out: test program output before patch
o cygtest2.out: test program output after patch
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
diff -rup cygipc-1.13pre1.orig/msg.c cygipc-1.13pre1/msg.c
--- cygipc-1.13pre1.orig/msg.c 2001-02-10 18:50:01.0 -0500
+++ cygipc-1.13pre1/msg.c 2002-11-13 07:44:19.0 -0500
@@ -168,8 +168,8 @@ static int findkey (key_t key)
if (msg_connect() == 0)
{
-debug_printf(findkey : return -EACCES\n);
-CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(findkey : return -ENOSYS\n);
+CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
for (id = 0; id = max_msqid; id++) {
if (msgque[id] == IPC_UNUSED)
@@ -212,8 +212,8 @@ debug_printf(msgsnd : return -EFAULT\n
LBloc = 0 ;
if (msg_connect() == 0)
{
-debug_printf(msgsnd : return -EACCES\n);
-CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(msgsnd : return -ENOSYS\n);
+CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
id = (unsigned int) msqid % MSGMNI;
@@ -251,8 +251,8 @@ slept:
{
if (msg_connect() == 0)
{
-debug_printf(msgsnd : return -EACCES\n);
- CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(msgsnd : return -ENOSYS\n);
+ CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
}
@@ -339,8 +339,8 @@ debug_printf(msgrcv : return -EFAULT\n
LBloc = 0 ;
if (msg_connect() == 0)
{
-debug_printf(msgrcv : return -EACCES\n);
-CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(msgrcv : return -ENOSYS\n);
+CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
id = (unsigned int) msqid % MSGMNI;
@@ -373,8 +373,8 @@ debug_printf(msgrcv : return -EIDRM\n)
{
if (msg_connect() == 0)
{
-debug_printf(msgrcv : return -EACCES\n);
- CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(msgrcv : return -ENOSYS\n);
+ CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
}
@@ -522,8 +522,8 @@ static int newque (key_t key, int msgflg
debug_printf(newque : key=%X msgflg=%X\n,key,msgflg);
if (msg_connect() == 0)
{
-debug_printf(newque : return -EACCES\n);
-CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(newque : return -ENOSYS\n);
+CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
for (id = 0; id MSGMNI; id++)
@@ -590,8 +590,8 @@ debug_printf(msgget : return -EEXIST\n
}
if (msg_connect() == 0)
{
-debug_printf(newque : return -EACCES\n);
-CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(newque : return -ENOSYS\n);
+CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
msq = (struct msqid_ds *)
@@ -655,8 +655,8 @@ debug_printf(msgctl : return -EINVAL\n
if (msg_connect() == 0)
{
-debug_printf(msgctl : return -EACCES\n);
-CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(msgctl : return -ENOSYS\n);
+CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
id = (unsigned int) msqid % MSGMNI;
diff -rup cygipc-1.13pre1.orig/sem.c cygipc-1.13pre1/sem.c
--- cygipc-1.13pre1.orig/sem.c 2001-11-26 18:41:32.0 -0500
+++ cygipc-1.13pre1/sem.c 2002-11-13 07:44:41.0 -0500
@@ -326,8 +326,8 @@ debug_printf(semget : return -EINVAL\n
if (sem_connect() == 0)
{
-debug_printf(semget : return -EACCES\n);
- CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(semget : return -ENOSYS\n);
+ CYGWIN_IPCNT_RETURN (-ENOSYS) ;
}
if (key == IPC_PRIVATE)
@@ -385,8 +385,8 @@ debug_printf(do_semop : sma=%p, sops=%p
{
if (sem_connect() == 0)
{
-debug_printf(do_semop : return -EACCES\n);
- CYGWIN_IPCNT_RETURN (-EACCES) ;
+debug_printf(do_semop : return -ENOSYS\n);
+ CYGWIN_IPCNT_RETURN
Re: pico and nano: number of lines displayed
[EMAIL PROTECTED] wrote: Actually there is something going on here. I reverted to an earlier version of Cygwin and even in a non-fullscreen rxvt environment, any of nano, pico and vim use the entire available depth of the window to display the text file being edited (so that for instance in pico and nano the Help menu appears at the bottom of the page and 50+ lines of the file are visible). The latest current version of Cygwin now displays only 20 lines of the file being edited to screen, exactly as in a basic bash window. Sorry not to be more specific about when the change occurred, but I think it is absolutely recent. I use this size of window for these editors the whole time, and the altered presentation caught my eye immediately. Unfortunately all of cygwin, login and Goodness knows what have been updated recently and I am not competent to isolate cause, only consequence! (Surely somebody out there uses viim in a rxvt windows and has also noticed this difference, yesterday or the day before??) I have a fully updated installation and I have never had a problem with using vi and rxvt at 67 lines x 80 columns - see below. $ stty -a speed 38400 baud; rows 67; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = undef; eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -tostop echoctl echoke $ uname -a CYGWIN_NT-4.0 DON 1.3.15(0.63/3/2) 2002-11-07 13:57 i686 unknown Seems you might have a flaky installation. Cheers Don Sharp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: pico and nano: number of lines displayed
[EMAIL PROTECTED] wrote: Actually there is something going on here. I reverted to an earlier version of Cygwin and even in a non-fullscreen rxvt environment, any of nano, pico and vim use the entire available depth of the window to display the text file being edited (so that for instance in pico and nano the Help menu appears at the bottom of the page and 50+ lines of the file are visible). The latest current version of Cygwin now displays only 20 lines of the file being edited to screen, exactly as in a basic bash window. Sorry not to be more specific about when the change occurred, but I think it is absolutely recent. I use this size of window for these editors the whole time, and the altered presentation caught my eye immediately. Unfortunately all of cygwin, login and Goodness knows what have been updated recently and I am not competent to isolate cause, only consequence! (Surely somebody out there uses viim in a rxvt windows and has also noticed this difference, yesterday or the day before??) I have a fully updated installation and I have never had a problem with using vi and rxvt at 67 lines x 80 columns - see below. $ stty -a speed 38400 baud; rows 67; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = undef; eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -tostop echoctl echoke $ uname -a CYGWIN_NT-4.0 DON 1.3.15(0.63/3/2) 2002-11-07 13:57 i686 unknown Seems you might have a flaky installation. Cheers Don Sharp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Trouble compiling e100 driver
This version of cygwin did come with BlueCat so that is the reason I have such an old version. I had considered updating it before but I had worried that a newer version might cause problems with my version of BlueCat. Now, I think I had better give it a try. Thanks for the help. I'll see if this could be part of the problem. In a message dated 11/12/2002 7:07:03 PM Eastern Standard Time, [EMAIL PROTECTED] writes: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Max, Attached is the output of the of the cygcheck. Thanks! HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C (default) = `C:' 2000/09/22 c:\cygwin32\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=1999/10/28 13:15 Ouch! You are using a truly ancient version of Cygwin. I assume it somehow came with BlueCat. If you can, you should update it. I don't know how tightly it is bound to the BlueCat system. If you can't, then your only remaining port of call is BlueCat support/mailing lists. There is very likely no one here who remembers the version of Cygwin you are using. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Not just X (Was: Cygwin Emacs-X uses 99% of cpu)
I also observe emacs spinning. I see it with both emacs and emacs-nox. I also see it on an old cygwin non-X build of xemacs-21.5. So it's not strictly related to X. (Except that it is very easily triggered by emacs + X.) I observe it in cygwin-1.3.15-1 and 1.3.15-2. It all goes away if I revert to cygwin-1.14-1. This is WinNT 4.0. With emacs-nox, I can trigger it by quickly and repeatedly calling a child process (stunnel, from VM, to get mail via SSL). It's the only way I can trip up emacs-nox. In normal usage (get mail occasionally, not quickly repeatedly), it's quite difficult to reproduce. (Happens only very rarely.) With emacs-nox, on WinNT 4.0, cygwin-1.3.15-2, here is the bit that repeats indefinitely: 222 553656862 [sig] emacs-nox 380 wait_sig: looping 222 553657084 [sig] emacs-nox 380 wait_sig: awake 220 553657304 [sig] emacs-nox 380 wait_sig: processing signal 20 219 553657523 [sig] emacs-nox 380 wait_sig: Got signal 20 223 553657746 [sig] emacs-nox 380 sig_handle: signal 20 219 553657965 [sig] emacs-nox 380 sig_handle: signal 20, about to call 0x200DFBFC 222 553658187 [sig] emacs-nox 380 setup_handler: suspending mainthread 285 553658472 [sig] emacs-nox 380 interruptible: pc 0x610BD706, h 0x6100, interruptible 1, testvalid 1 227 553658699 [sig] emacs-nox 380 interruptible: pc 0x610BD706, h 0x6100, interruptible 0, testvalid 0 238 553658937 [sig] emacs-nox 380 setup_handler: couldn't send signal 20 223 553659160 [sig] emacs-nox 380 setup_handler: ResumeThread returned 1 221 553659381 [sig] emacs-nox 380 setup_handler: returning 0 216 553659597 [sig] emacs-nox 380 sig_handle: returning 0 243 553659840 [sig] emacs-nox 380 proc_subproc: args: 3, 0 220 553660060 [sig] emacs-nox 380 proc_subproc: looking for processes to reap 218 553660278 [sig] emacs-nox 380 proc_subproc: finished processing terminated/stopped child 235 553660513 [sig] emacs-nox 380 proc_subproc: returning 1 Notice in this case it's signal 20 (SIGCHLD). When I repeat the exercise using emacs and X, it's signal 14 (SIGALRM), like others have reported. It spins before a window is even drawn. 228 107117477 [sig] emacs 402 wait_sig: looping 230 107117707 [sig] emacs 402 wait_sig: awake 220 107117927 [sig] emacs 402 wait_sig: processing signal 14 218 107118145 [sig] emacs 402 wait_sig: Got signal 14 215 107118360 [sig] emacs 402 sig_handle: signal 14 217 107118577 [sig] emacs 402 sig_handle: signal 14, about to call 0x201240A4 233 107118810 [sig] emacs 402 setup_handler: suspending mainthread 311 107119121 [sig] emacs 402 interruptible: pc 0x77F1D642, h 0x77F0, interruptible 1, testvalid 1 329 107119450 [sig] emacs 402 interruptible: pc 0x77F1D642, h 0x77F0, interruptible 0, testvalid 0 264 107119714 [sig] emacs 402 setup_handler: couldn't send signal 14 221 107119935 [sig] emacs 402 setup_handler: ResumeThread returned 1 219 107120154 [sig] emacs 402 setup_handler: returning 0 222 107120376 [sig] emacs 402 sig_handle: returning 0 Here's what it looks like with an old cygwin (non-X11) build of xemacs-21.5. It spins when a child terminates, such as exiting bash in a M-x shell buffer. The simple combination M-x shell + exit has no problem, but if I do M-x shell, then a few basic bash commands like cd's and ls's, then exit, it spins. Here is the repeating part: 228 92598188 [sig] xemacs 370 wait_sig: looping 230 92598418 [sig] xemacs 370 wait_sig: awake 225 92598643 [sig] xemacs 370 wait_sig: processing signal 20 231 92598874 [sig] xemacs 370 wait_sig: Got signal 20 221 92599095 [sig] xemacs 370 sig_handle: signal 20 224 92599319 [sig] xemacs 370 sig_handle: signal 20, about to call 0x4D7EE0 227 92599546 [sig] xemacs 370 setup_handler: suspending mainthread 325 92599871 [sig] xemacs 370 interruptible: pc 0x77F1D642, h 0x77F0, interruptible 1, testvalid 1 279 92600150 [sig] xemacs 370 interruptible: pc 0x77F1D642, h 0x77F0, interruptible 0, testvalid 0 257 92600407 [sig] xemacs 370 setup_handler: couldn't send signal 20 229 92600636 [sig] xemacs 370 setup_handler: ResumeThread returned 1 234 92600870 [sig] xemacs 370 setup_handler: returning 0 231 92601101 [sig] xemacs 370 sig_handle: returning 0 226 92601327 [sig] xemacs 370 proc_subproc: args: 3, 0 224 92601551 [sig] xemacs 370 proc_subproc: looking for processes to reap 233 92601784 [sig] xemacs 370 proc_subproc: finished processing terminated/stopped child 228 92602012 [sig] xemacs 370 proc_subproc: returning 1 Would it help if I tried snapshots between 1.3.14 and 1.3.15 to narrow it down? Thanks, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Linking with OpenGL, glut
Braden McDaniel wrote:
I'm having some trouble with the directions in README.txt in the OpenGL
docs. They indicate one should use -lopengl32; however, that's not working
for me. Here is the excerpt from my config.log:
---
configure:16198: gcc -o conftest.exe -g -O2 -I/usr/X11R6/include
conftest.c -lopengl32 -L/usr/X11R6/lib -lm 5
There seems to be some misunderstanding here. The OpenGL package is for
producing native Windows programs, not X11-dependant programs. Do not use
-I/usr/X11R6/include , -L/usr/X11R6/lib , and -lm if you want to use that
package.
/cygdrive/c/DOCUME~1/Braden/LOCALS~1/Temp/ccef6CMT.o(.text+0x1d): In
function `main':
/home/Braden/src/openvrml/openvrml/BUILD/configure:16190: undefined
reference to `_glBegin'
This shows that you are not including the right GL headers. If you were
pulling the right headers but linking incorrectly, the message would have
been: undefined reference to `_glBegin@4' .
collect2: ld returned 1 exit status
configure:16201: $? = 1
configure: failed program was:
#line 16170 configure
#include confdefs.h
# ifdef _WIN32
# include windows.h
# endif
# ifdef HAVE_OPENGL_GL_H
# include OpenGL/gl.h
# else
# include GL/gl.h
# endif
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern C
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
glBegin(0)
;
return 0;
}
---
The following conftest.c programs compiles and link correctly:
#include GL/gl.h
int
main ()
{
glBegin(0)
;
return 0;
}
gcc -o conftest -g -O2 conftest.c -lopengl32
There's a similar problem with using -lglu32. However, -lGL works and -lGLU
works. So I wouldn't be complaining at all if I could figure out how to link
with glut. Neither -lglut32 -lGLU -lGL nor -lglut -lGLU -lGL works. Any
ideas?
Braden
Again -lglut32 is for linking native Windows programs. Use the right
include statements and the right headers:
#include GL/gl.h
#include GL/glut.h
Link with -lglut32 -lglu32 -lopengl32 .
-lGL and -lGLU are for X11 dependant programs. There is no Glut library in
Cygwin's X11R6 distribution.
André Bleau, Cygwin's OpenGL package maintainer.
email: bleau at igb dot umontreal dot ca
(Fight SPAM: encode your email-address)
Please address all questions and problem reports about Cygwin's OpenGL
package to [EMAIL PROTECTED] .
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Cygwin Emacs-X uses 99% of cpu
On Wed, 13 Nov 2002, Huang. wrote: Igor Pechtchanski wrote: On Wed, 13 Nov 2002, Huang. wrote: J. Scott Edwards [EMAIL PROTECTED] wrote: [snip] Oh! I have this problem too. For the archives: This is an example of a completely useless message. It doesn't add anything at all to the discussion, and takes up list bandwidth. OK, you are right. Sorry, didn't mean to sound that harsh, but I'm glad I could shock some useful data out of people... :-) Attaching the output of cygcheck would have made it marginally useful (i.e., reporting that the problem can be reproduced on a particular configuration). A good contribution would have been to run emacs under strace, for example, and provide the output (hopefully bzipped, preferably with repeated patterns removed, ideally with some analysis attached). Another would be to run emacs under gdb, break execution when in 100% cpu mode, and post the stack trace. Igor I tried your way. here is my cygcheck -s : Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Nov 13 12:46:13 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 [snip] Thanks, but next time, please provide the output of cygcheck -s -v -r as an *attachment*, as indicated in http://cygwin.com/bugs.html run emacs under gdb, can't break execution when in 100% cpu mode, didn't know why. If emacs is looping on signal delivery, it's unlikely you can squeeze another signal in... run emacs under strace, when in 100% cpu, just repeats the following : (repeat) 106 202207420 [sig] emacs 1692 wait_sig: looping 128 202207548 [sig] emacs 1692 wait_sig: awake 108 202207656 [sig] emacs 1692 wait_sig: processing signal 14 129 202207785 [sig] emacs 1692 wait_sig: Got signal 14 105 202207890 [sig] emacs 1692 sig_handle: signal 14 123 202208013 [sig] emacs 1692 sig_handle: signal 14, about to call 0x201240A4 108 202208121 [sig] emacs 1692 setup_handler: suspending mainthread 193 202208314 [sig] emacs 1692 interruptible: pc 0x77E7E8BB, h 0x77E6, interruptible 1, testvalid 1 149 202208463 [sig] emacs 1692 interruptible: pc 0x77E7E8BB, h 0x77E6, interruptible 0, testvalid 0 131 202208594 [sig] emacs 1692 setup_handler: couldn't send signal 14 117 202208711 [sig] emacs 1692 setup_handler: ResumeThread returned 1 125 202208836 [sig] emacs 1692 setup_handler: returning 0 106 202208942 [sig] emacs 1692 sig_handle: returning 0 (repeat) i can't attach the file, it is larger than 12M in running 3 minutes. You did even better than that, you've identified and attached the useful part of the trace. That's what I meant by analysis. I think this will be very helpful in debugging this problem to someone who knows about cygwin's signal delivery mechanism. Thanks. Thanks to all who contributed! Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Water molecules expand as they grow warmer (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Linking with OpenGL, glut
On Wed, 2002-11-13 at 09:57, Andre Bleau wrote: [snip] Again -lglut32 is for linking native Windows programs. Use the right include statements and the right headers: #include GL/gl.h #include GL/glut.h Link with -lglut32 -lglu32 -lopengl32 . -lGL and -lGLU are for X11 dependant programs. There is no Glut library in Cygwin's X11R6 distribution. Aha... Thank you. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Not just X (Was: Cygwin Emacs-X uses 99% of cpu)
On Wednesday 13 Nov 02, David Starks-Browning writes: I also observe emacs spinning. I see it with both emacs and emacs-nox. I also see it on an old cygwin non-X build of xemacs-21.5. So it's not strictly related to X. (Except that it is very easily triggered by emacs + X.) I observe it in cygwin-1.3.15-1 and 1.3.15-2. It all goes away if I revert to cygwin-1.14-1. This is WinNT 4.0. ... Would it help if I tried snapshots between 1.3.14 and 1.3.15 to narrow it down? I find that this is the last snapshot without the problem: CYGWIN_NT-4.0 BRYCE 1.3.15s(0.62/3/2) 20021103 23:52:20 i686 unknown This snapshot exhibits the problem: CYGWIN_NT-4.0 BRYCE 1.3.16s(0.63/3/2) 20021106 21:24:12 i686 unknown (Although I'm quite ignorant about Cygwin internals, my money is on the sigproc.cc changes...) Hope this helps. Regards, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Searching on Mailing list and Update on fvwm2 for Cygwin
markem wrote: Search Function on web site: Actually, trying this on several people's names turned up that even though I could see the person's name next to their entry - search refused to locate their messages. Umany ideas? It's a giant global conspiracy to suppress the voices of skeptics. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin Emacs-X uses 99% of cpu
I have never been able to get attachments to work in this e-mail program, but instead I have put my cygcheck -s -v -r output at: http://www.xmission.com/~sedwards/cygcheck.txt I have also discovered that I can start up two emacs (as foreground processes) and they are ok, but if I start up a third (in the foreground) it will start sucking up 99% of the cpu. If it would be helpful to have my strace as well let me know. Thanks -Scott -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
rxvt, stty and login
I am really sorry to drone on about this, but I've tried to reduce the problem to its basics. I feel more or less certain there's something a bit glitchy with recent versions of login and how it interacts with rxvt. (BTW, I have not yet updated to login-1.6-1 as recently announced.) Start Cygwin with the sparse switchless command c:\Cygwin\bin\rxvt.exe Then just do this: $ stty -a speed 38400 baud; rows 25; columns 80; line = 0; .. and lots of other stuff .. $ login login: yourusername fergus LEPER ~ $ stty -a speed 38400 baud; rows 0; columns 0; line = 0; .. and lots of other stuff .. In this second case of stty -a, rows and columns have altered from 25 and 80 to 0 and 0. Is this not the root of the problem earlier described under pico and nano: number of lines displayed? To do this test I deleted .bash_profile, .bashrc and .inputrc. It seems to me that this is as sparse an example as I could have provided of this strange behaviour, and would like to know whether others can duplicate it? I am using Windows 98 S/E. Thank you. Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
how to resume cygwin download?
Hi, I tried a few times to download all cygwin packages, but the download got interrupted every time at 99%, sometimes also earlier, and i had to to start it all over again. after that, i downloaded everything directly from a ftp, and everything was ok. is there any way to resume download??? if not, that could be a nice feature of new version of setup.exe. thanx Mirza -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
mouse support of cygwin console
Hello, When the escape sequence \033[?1000h is sent to cygwin console and the support of xterm-style mouse event are enabled, the escape sequences of middle button (btn2) and right button (btn3) are opposite with xterm. Escape sequences when button down: * xterm left button down: \033 [ M SPC x y middle button down: \033 [ M ! x y right button down: \033 [ M x y * cygwin console left button down: \033 [ M SPC x y middle button down: \033 [ M x y right button down: \033 [ M ! x y Is it a bug ? Regards, --- Hironori SAKAMOTO [EMAIL PROTECTED] http://www2u.biglobe.ne.jp/~hsaka/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rxvt, stty and login
[EMAIL PROTECTED] wrote: I am really sorry to drone on about this, but I've tried to reduce the problem to its basics. I feel more or less certain there's something a bit glitchy with recent versions of login and how it interacts with rxvt. (BTW, I have not yet updated to login-1.6-1 as recently announced.) Start Cygwin with the sparse switchless command c:\Cygwin\bin\rxvt.exe Then just do this: $ stty -a speed 38400 baud; rows 25; columns 80; line = 0; .. and lots of other stuff .. $ login login: yourusername fergus @ LEPER ~ $ stty -a speed 38400 baud; rows 0; columns 0; line = 0; .. and lots of other stuff .. In this second case of stty -a, rows and columns have altered from 25 and 80 to 0 and 0. Is this not the root of the problem earlier described under pico and nano: number of lines displayed? To do this test I deleted .bash_profile, .bashrc and .inputrc. It seems to me that this is as sparse an example as I could have provided of this strange behaviour, and would like to know whether others can duplicate it? I am using Windows 98 S/E. Having tried typing login username in an rxvt window I can confirm that the problem exists on NT4 also. login is definitely the culprit and Sergei Okhapkin, in an earlier reply, showed the section of login code that's responsible. It's not clear why you are using login when you already have an rxvt window. I believe it isn't intended as a way of doing an su username but for use by telnetd etc. If I don't type login in an rxvt window I don't run into the problem. Cheers Don Sharp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mouse support of cygwin console
On Thu, Nov 14, 2002 at 02:46:26AM +0900, Hironori SAKAMOTO wrote: Hello, When the escape sequence \033[?1000h is sent to cygwin console and the support of xterm-style mouse event are enabled, the escape sequences of middle button (btn2) and right button (btn3) are opposite with xterm. Escape sequences when button down: * xterm left button down: \033 [ M SPC x y middle button down: \033 [ M ! x y right button down: \033 [ M x y * cygwin console left button down: \033 [ M SPC x y middle button down: \033 [ M x y right button down: \033 [ M ! x y Is it a bug ? It looks like it is. I'll check in a fix. Thanks for the heads up. cgf -- Please do not send me personal email with cygwin questions or observations. Use the resources at http://cygwin.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygipc ENOSYS patch (was Re: cygipc-1.13pre1)
Jason Tishler wrote: My patch (against cygipc-1.13pre1) changes the following cygipc functions to return ENOSYS instead of EACCES if ipc-daemon is not running: msgctl() msgget() msgrcv() msgsnd() semctl() semget() semop() shmat() shmctl() shmget() shmdt() Since I could only (easily) test semget() and shmget() under PostgreSQL, I decided to write a simply test program, cygtest.cc, to exercise all of my cygipc changes. Attached are the following files: o cygipc-1.13pre1.patch: ENOSYS patch o cygipc-1.13pre1.ChangeLog: corresponding ChangeLog entry o cygtest.cc: test program o cygtest.out: test program output before patch o cygtest2.out: test program output after patch Thanks. Applied, and cygipc-1.13 is now available at http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/ I'll post a separate announcement-style message... --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANN] cygipc-1.13 now available
cygipc is an implementation of IPC services for cygwin. Although it will eventually be replaced by the developing cygwin daemon, cygipc is currently the more complete implementation and is used by postgresql as well as by the kde-cygwin project. cygipc-1.13 fixes some long-standing problems experienced by postgresql, and now returns correct error values when ipc-daemon is not running (Jason Tishler). Also, there have been some changes in the options (although the old option switches are still supported). This change is so that we can support more finely graded levels of error reporting in the future. Previously, error logging was controlled by these two switches: -d, --debug extra verbose error reporting/logging -q, --quiet minimal error reporting/logging Now, these functions are controlled by a single option: -D, --debug-level=int Set verboseness of output. 0=quiet mode 1=normal (default) 2=verbose mode -d/--debug and -q/--quiet are still supported, but their effect is now simply: -d, --debug sets --debug-level=2 -q, --quiet sets --debug-level=0 Now, while you don't NEED to take any action, you might want to edit your ipc-daemon startup scripts or registry entries and change '-q' to '-D 0', etc. Enjoy, Chuck (just visiting, and not really back) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Welcome back su? (was Re: New sysvinit package ...)
On Mon, Nov 11, 2002 at 05:39:28PM -0500, Sergey Okhapkin wrote:
New cygwin sysvinit package available for download. Init is the parent
of all unix processes. Its primary role is to create processes from a
script stored in the file /etc/inittab (see inittab(5)). This file
usually has entries which cause init to spawn gettys on each line that
users can log in. It also controls autonomous processes required by any
particular system.
Since Sergey has contributed sysvinit, should su be welcomed back to
the sh-utils package? I'm suggesting this because some rc scripts
(e.g., PostgreSQL's) need su to function properly.
I understand that su requires special Windows privileges in order to
successfully setuid(). Maybe patching su to abort with the following
error message:
su: Currently only supported when run under the LocalSystem account.
when not run under the LocalSystem account is sufficient to help
minimize the mailing list support burden?
Anyway with the attached (quick) patch to su, I was able to start up
PostgreSQL using the standard PostgreSQL rc script via init with it
ultimately running under a postgres account.
Jason
P.S. Note that the patch is a starting point -- not a finished product.
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--- su.c.orig 2002-11-13 13:05:32.0 -0500
+++ su.c2002-11-13 13:07:53.0 -0500
-226,7 +226,7 log_su (const struct passwd *pw, int suc
const char *new_user, *old_user, *tty;
# ifndef SYSLOG_NON_ROOT
- if (pw-pw_uid)
+ if (pw-pw_uid != 18)
return;
# endif
new_user = pw-pw_name;
-284,7 +284,7 correct_password (const struct passwd *p
#endif
correct = pw-pw_passwd;
- if (getuid () == 0 || correct == 0 || correct[0] == '\0')
+ if (getuid () == 18 || correct == 0 || correct[0] == '\0')
return 1;
unencrypted = getpass (_(Password:));
-331,7 +331,7 modify_environment (const struct passwd
{
xputenv (concat (HOME, =, pw-pw_dir));
xputenv (concat (SHELL, =, shell));
- if (pw-pw_uid)
+ if (pw-pw_uid != 18)
{
xputenv (concat (USER, =, pw-pw_name));
xputenv (concat (LOGNAME, =, pw-pw_name));
-553,7 +553,7 main (int argc, char **argv)
if (shell == 0 change_environment == 0)
shell = getenv (SHELL);
- if (shell != 0 getuid () restricted_shell (pw-pw_shell))
+ if (shell != 0 getuid () != 18 restricted_shell (pw-pw_shell))
{
/* The user being su'd to has a nonstandard shell, and so is
probably a uucp account or has restricted access. Don't
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[possible solution] Re: Cygwin Emacs-X uses 99% of cpu
Huang. wrote:
run emacs under strace, when in 100% cpu, just repeats the following :
(repeat)
106 202207420 [sig] emacs 1692 wait_sig: looping
128 202207548 [sig] emacs 1692 wait_sig: awake
108 202207656 [sig] emacs 1692 wait_sig: processing signal 14
129 202207785 [sig] emacs 1692 wait_sig: Got signal 14
105 202207890 [sig] emacs 1692 sig_handle: signal 14
123 202208013 [sig] emacs 1692 sig_handle: signal 14, about to call
0x201240A4
108 202208121 [sig] emacs 1692 setup_handler: suspending mainthread
193 202208314 [sig] emacs 1692 interruptible: pc 0x77E7E8BB, h
0x77E6, interruptible 1, testvalid 1
149 202208463 [sig] emacs 1692 interruptible: pc 0x77E7E8BB, h
0x77E6, interruptible 0, testvalid 0
131 202208594 [sig] emacs 1692 setup_handler: couldn't send signal 14
117 202208711 [sig] emacs 1692 setup_handler: ResumeThread returned 1
125 202208836 [sig] emacs 1692 setup_handler: returning 0
106 202208942 [sig] emacs 1692 sig_handle: returning 0
(repeat)
This may be something I ran into on a UNIX machine. If someone wants to rebuild
emacs with the following patch, it might fix the problem. My recollection regarding
this patch is that a periodic timer is being set up in emacs but there is a
timing problem with how it is initialized.
I will try and rebuild the Cygwin emacs package with this patch sometime tonight.
Joe Buehler
--- src/xterm.c Sat Mar 16 05:34:56 2002
+++ src/xterm.c Mon Oct 14 08:36:55 2002
-14228,6 +14228,17
#endif
}
+ /* Install an asynchronous timer that processes Xt timeout events
+ every 0.1s. This is necessary because some widget sets use
+ timeouts internally, for example the LessTif menu bar, or the
+ Xaw3d scroll bar. When Xt timouts aren't processed, these
+ widgets don't behave normally. */
+ {
+EMACS_TIME interval;
+EMACS_SET_SECS_USECS (interval, 0, 10);
+start_atimer (ATIMER_CONTINUOUS, interval, x_process_timeouts, 0);
+ }
+
#else /* not USE_X_TOOLKIT */
#ifdef HAVE_X11R5
XSetLocaleModifiers ();
-14678,17 +14689,6
XtCacheByDisplay, cvt_pixel_dtor);
XtAppSetFallbackResources (Xt_app_con, Xt_default_resources);
-
- /* Install an asynchronous timer that processes Xt timeout events
- every 0.1s. This is necessary because some widget sets use
- timeouts internally, for example the LessTif menu bar, or the
- Xaw3d scroll bar. When Xt timouts aren't processed, these
- widgets don't behave normally. */
- {
-EMACS_TIME interval;
-EMACS_SET_SECS_USECS (interval, 0, 10);
-start_atimer (ATIMER_CONTINUOUS, interval, x_process_timeouts, 0);
- }
#endif
#ifdef USE_TOOLKIT_SCROLL_BARS
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: FAT32, lock count exceeded, mutt etc.
My mistake, I wasn't using the patched version (/usr/bin versus /usr/local/bin). The patch seems to work. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
nice subject
[This is a bug report, I'm following cygwin reporting instructions by posting here. The subject line has been changed so as to not be refused. Original subject line: xterm consumes 100% cpu when first XWin action is to close xterm.] What happens: boot winxp, start cygwin, run startxwin.bat, and XWin starts normally. If the first action is anything other than to close the xterm, for example, open the desktop menu, then everything will run fine. However, if the first action is to close the xterm, either by typing 'exit' or by clicking on the button in the window bar, the xterm process will consume 100% of my cpu (according to winxp task manager, assuming that was opened previously, because it will take forever to open after.) Interestingly, after killing the zombie xterm and window manager processes in winxp task manager and restart xwin, I can close xterm either by typing exit or clicking on the button in the window bar first and everything will run fine. So, it is only the first time after rebooting that this happens. I've tried this with wmaker, twm and fvwm2 window managers, and the problem persists except for the window manager that forces me to click to place the xterm, because that forces a first action other than to close the xterm. As this is a very strange and unlikely to be stumbled upon, I thought you'd want to know about it. Config follows. = Hardware: Celeron 500, 256M RAM, ASUS CUBX, IBM DPTA-373420, S3 Savage4 32 M, Adaptec 2940 UW, IBM DCAS-34330, (all running reliably) ... Software: Recent, stable, clean, licensed install of winXP Pro with .NET framework and latest service packs, running very reliably on 8G partition of the 34G IDE drive, Debian and DOS are on the 4G SCSI hard drive. Cygwin: fresh install on Nov 10, 2002. Modified the environment variables slightly to get a prompt I like and the startxwin.bat file to start the window manager I like, with only one open xterm, and my xterm preferences. $ cygcheck -s Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Nov 13 10:18:28 2002 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\Program Files\Microsoft SQL Server\80\Tools\Binn\ c:\Program Files\SSH Communications Security\SSH Secure Shell C:\cygwin\usr\X11R6\bin SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\Jake' MAKE_MODE = `unix' PWD = `/home/Jake' USER = `Jake' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS8158Mb 74% CP CS UN PA FC XP d: hd NTFS 24466Mb 48% CP CS UN PA FC STORAGE e: hd FAT 133Mb 32% CPUN DOS f: hd FAT32 2090Mb 17% CPUN SHARE g: hd NTFS 7Mb 99% CP CS UN PA FC End h: cd N/AN/A C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive user binmode,cygdrive Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Not Found: gdb Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\sh.exe 58k 2002/05/07 C:\cygwin\bin\cygbz2-1.dll 643k 2002/11/09 C:\cygwin\bin\cygcrypto.dll 475k 2002/10/11 C:\cygwin\bin\cygcurl-2.dll 45k 2001/04/25 C:\cygwin\bin\cygform5.dll 35k 2002/01/09 C:\cygwin\bin\cygform6.dll 19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll 20k 2002/10/10 C:\cygwin\bin\cyghistory5.dll 929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll 22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll 28k 2002/09/20 C:\cygwin\bin\cygintl-2.dll 21k 2001/06/20 C:\cygwin\bin\cygintl.dll 119k 2002/02/09 C:\cygwin\bin\cygjpeg6b.dll 59k 2002/09/20 C:\cygwin\bin\cygkpathsea-3-3-7.dll 26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll 156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll 175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll 226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll 202k 2002/01/09 C:\cygwin\bin\cygncurses6.dll 15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll 12k 2002/01/09 C:\cygwin\bin\cygpanel6.dll 40k 2001/11/21 C:\cygwin\bin\cygpcre.dll 39k 2001/11/21 C:\cygwin\bin\cygpcreposix.dll 175k 2002/07/22 C:\cygwin\bin\cygpng10.dll 179k 2002/07/22 C:\cygwin\bin\cygpng12.dll 22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll 108k 2001/06/28 C:\cygwin\bin\cygreadline4.dll 127k 2002/10/10 C:\cygwin\bin\cygreadline5.dll 66k
Re: cygipc ENOSYS patch (was Re: cygipc-1.13pre1)
Jason Tishler wrote: I'll post a separate announcement-style message... You are very welcome. Thanks for accepting my patch and for generating a release so quickly. Erg. Spoke too quickly. I forgot about another pending patch that needs to go in, and just found one (longstanding) bug in the install_reg_entries routine. Sigh. cygipc-1.13-2 coming soon. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [patch] postgresql 'rc' like start script
Ralf, On Mon, Oct 07, 2002 at 11:49:24PM +0200, Ralf Habacker wrote: May be this could be the startpoint for a more unix like standardisation of cygwin services like postgresql, apache, cron, inetd apache: (at leased) I would prefer to leverage off of Sergey's sysvinit package: http://cygwin.com/ml/cygwin/2002-11/msg00669.html The following is the only required diff (besides the expected ones) to PostgreSQL's contrib/start-scripts/linux: -76,7 +76,7 case $1 in ;; restart) echo -n Restarting PostgreSQL: - su - $PGUSER -c $DAEMON restart -D '$PGDATA' -s -m fast + su - $PGUSER -c $DAEMON restart -D '$PGDATA' -s -m fast -l $PGLOG echo ok ;; status) Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: nice subject
On Wed, Nov 13, 2002 at 12:38:56PM -0800, Jake D. Stern wrote: [This is a bug report, I'm following cygwin reporting instructions by posting here. The subject line has been changed so as to not be refused. Original subject line: xterm consumes 100% cpu when first XWin action is to close xterm.] The fact that your subject was blocked didn't give you enough of a clue that you were doing something wrong, eh? The mind boggles. We HAVE A MAILING LIST for Cygwin/XFree86 discussions. Use it. FYI, I've blocked this subject too. I can keep this up all day if you want. cgf What happens: boot winxp, start cygwin, run startxwin.bat, and XWin starts normally. If the first action is anything other than to close the xterm, for example, open the desktop menu, then everything will run fine. However, if the first action is to close the xterm, either by typing 'exit' or by clicking on the button in the window bar, the xterm process will consume 100% of my cpu (according to winxp task manager, assuming that was opened previously, because it will take forever to open after.) Interestingly, after killing the zombie xterm and window manager processes in winxp task manager and restart xwin, I can close xterm either by typing exit or clicking on the button in the window bar first and everything will run fine. So, it is only the first time after rebooting that this happens. I've tried this with wmaker, twm and fvwm2 window managers, and the problem persists except for the window manager that forces me to click to place the xterm, because that forces a first action other than to close the xterm. As this is a very strange and unlikely to be stumbled upon, I thought you'd want to know about it. Config follows. = Hardware: Celeron 500, 256M RAM, ASUS CUBX, IBM DPTA-373420, S3 Savage4 32 M, Adaptec 2940 UW, IBM DCAS-34330, (all running reliably) ... Software: Recent, stable, clean, licensed install of winXP Pro with .NET framework and latest service packs, running very reliably on 8G partition of the 34G IDE drive, Debian and DOS are on the 4G SCSI hard drive. Cygwin: fresh install on Nov 10, 2002. Modified the environment variables slightly to get a prompt I like and the startxwin.bat file to start the window manager I like, with only one open xterm, and my xterm preferences. $ cygcheck -s Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Nov 13 10:18:28 2002 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\Program Files\Microsoft SQL Server\80\Tools\Binn\ c:\Program Files\SSH Communications Security\SSH Secure Shell C:\cygwin\usr\X11R6\bin SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\Jake' MAKE_MODE = `unix' PWD = `/home/Jake' USER = `Jake' Use `-r' to scan registry a: fd N/AN/A c: hd NTFS8158Mb 74% CP CS UN PA FC XP d: hd NTFS 24466Mb 48% CP CS UN PA FC STORAGE e: hd FAT 133Mb 32% CPUN DOS f: hd FAT32 2090Mb 17% CPUN SHARE g: hd NTFS 7Mb 99% CP CS UN PA FC End h: cd N/AN/A C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive user binmode,cygdrive Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Not Found: gdb Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\sh.exe 58k 2002/05/07 C:\cygwin\bin\cygbz2-1.dll 643k 2002/11/09 C:\cygwin\bin\cygcrypto.dll 475k 2002/10/11 C:\cygwin\bin\cygcurl-2.dll 45k 2001/04/25 C:\cygwin\bin\cygform5.dll 35k 2002/01/09 C:\cygwin\bin\cygform6.dll 19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll 17k 2001/06/28 C:\cygwin\bin\cyghistory4.dll 20k 2002/10/10 C:\cygwin\bin\cyghistory5.dll 929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll 22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll 28k 2002/09/20 C:\cygwin\bin\cygintl-2.dll 21k 2001/06/20 C:\cygwin\bin\cygintl.dll 119k 2002/02/09 C:\cygwin\bin\cygjpeg6b.dll 59k 2002/09/20 C:\cygwin\bin\cygkpathsea-3-3-7.dll 26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll 20k 2002/01/09 C:\cygwin\bin\cygmenu6.dll 156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll 175k 2002/01/09 C:\cygwin\bin\cygncurses++6.dll 226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll 202k 2002/01/09 C:\cygwin\bin\cygncurses6.dll 15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll 12k 2002/01/09
Serial port problems with cygwin1.dll 1.3.15 on Win98SE
When using a cross debugger (m68k-palmos-gdb) talking to a Palm device
via the serial port on W98SE my system completely hangs.
What I have been able to deduce is that it happens as soon as the Palm
sends a debug packet to the PC.
M68k-palmos-gdb opens the serial port, sets the baudrate to 57600 and puts
the port in raw mode.
You can still interrupt the program and do other things after this, provided
the Palm has not sent any data yet.
As soon as it sends data (e.g. when you start the program you want to debug)
the whole system hangs. Ctrl-Alt-Delete gives a blue screen etc.
I went back to older versions of cygwin1.dll and everything works fine up to
version 1.3.14. So something happened between 1.3.14 and 1.3.15.
I suspect some of the recent changes to fhandler-serial.cc.
Any hints on how to debug this? snapshots to try?
Output from cygcheck -s -r -v attached.
Ton van Overbeek
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Nov 13 22:05:56 2002
Windows 98 SE Ver 4.10 Build
Path: D:\cygwin\usr\X11R6\bin
D:\cygwin\usr\local\bin
D:\cygwin\bin
D:\cygwin\bin
D:\cygwin\bin
d:\MATLABR11\BIN
c:\WINDOWS
c:\WINDOWS\COMMAND
d:\MATLAB6P1\BIN\WIN32
SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS
HOME = `D:\cygwin\home\Ton'
MAKE_MODE = `unix'
PWD = `/home/Ton'
USER = `Ton'
BLASTER = `A240 I2 D1 H7 P330 T6'
CLASSPATH = `C:\WINDOWS\SYSTEM\QTJava.zip;'
CMDLINE = `run rxvt -bg light goldenrod yellow -geometry 80x50 -fn
lucidatypewriter-12 -e /usr/bin/bash --login -i'
COLORFGBG = `0;default'
COLORTERM = `rxvt-xpm'
COMSPEC = `C:\COMMAND.COM'
CVSROOT = `:pserver:[EMAIL PROTECTED]:/cvsroot/easycalc'
DISPLAY = `:0'
HOMEDRIVE = `D:'
HOMEPATH = `\cygwin\home\Ton'
MANPATH = `:/usr/ssl/man'
OLDPWD = `/usr/bin'
PROMPT = `$p$g'
PS1 = `\[\033]0;\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ '
QTJAVA = `C:\WINDOWS\SYSTEM\QTJava.zip'
SHLVL = `1'
TEMP = `e:\TEMP'
TERM = `xterm'
TEXMF = `{/usr/share/lilypond/1.6.5,/usr/share/texmf}'
WINBOOTDIR = `C:\WINDOWS'
WINDIR = `C:\WINDOWS'
WINDOWID = `10035856'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu\Programs\Cygnus Solutions
(default) = (unsupported type)
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/palmdev
(default) = `D:\Program Files\Falch.net\PalmDev'
flags = 0x
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
(default) = `D:\cygwin\usr\X11R6\lib\X11\fonts'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `D:\cygwin'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `D:\cygwin/bin'
flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `D:\cygwin/lib'
flags = 0x0002
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x002a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options
a: fd N/AN/A
c: hd FAT32 3037Mb 71% CPUN DRIVE-C
d: hd FAT32 12072Mb 59% CPUN DRIVE-D
e: hd FAT32 28149Mb 3% CPUN DRIVE-E
v: cd N/AN/A
w: cd N/AN/A
D:\Program Files\Falch.net\PalmDev /palmdev usertextmode
D:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts userbinmode
D:\cygwin / userbinmode
D:\cygwin/bin /usr/bin userbinmode
D:\cygwin/lib /usr/lib userbinmode
. /cygdrive userbinmode,cygdrive
. /cygdrive userbinmode,cygdrive
Found: D:\cygwin\bin\bash.exe
Found: D:\cygwin\bin\cat.exe
Found: D:\cygwin\bin\cpp.exe
Found: D:\cygwin\bin\find.exe
Found: c:\WINDOWS\COMMAND\find.exe
Warning: D:\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
Found: D:\cygwin\bin\gcc.exe
Found: D:\cygwin\bin\gdb.exe
Found: D:\cygwin\bin\ld.exe
Found: D:\cygwin\bin\ls.exe
Found: D:\cygwin\bin\make.exe
Found: D:\cygwin\bin\sh.exe
41k 2002/05/14 D:\cygwin\usr\X11R6\bin\cygPropList-0.dll - os=4.0 img=1.0 sys=4.0
cygPropList-0.dll v0.0 ts=2002/5/14 5:13
475k 2002/10/11 D:\cygwin\bin\cygcurl-2.dll - os=4.0 img=1.0 sys=4.0
help: cygwin on WinNT - allocates 3x memory asked for
Hi,
I hoped that someone would be willing to help me with resolving a simple
cygwin-related malloc problem under Win NT 4.0. I have searched the web for
an answer and haven't seen any related post. I apologize if the answer is
obvious to posters on this list - I'm not very experienced with cygwin.
PROBLEM: a C program written to allocate x amount of memory actually uses
about 3 times that much memory, when compiled with gcc (3.2-2) under cygwin
(1.3.15-2). This does not occur when compiling with a native windows
compiler (I used lcc) where allocating 50MB increases the system memory
used by roughly the 50MB.
The program below tries to allocate memory starting with 16MB and doubling
the allocation until it fails. The getchar statements are there to
interrupt the program and wait for a keypress so that I can monitor the
amount of memory used by the system in the Windows NT Task Manager before
and after each allocation.
The result is that a 512MB allocation actually increases the system memory
usage by about 1500MB. This ratio of 3 is the same regardless of the size
of allocation. When compiled with a native compiler (non-cygwin), a 512MB
allocation increases the used ram by about 512MB. I also tried using
realloc instead of malloc/free for successive allocations - no difference.
C++ version with new/delete on g++ - also no difference. The factor of 3
is also the same whether you're allocating a vector of chars, doubles, etc.
Any hints? Listing is below. (I'd appreciate it if you'd cc me any reply).
Thanks a lot!
Milos
/*
Finds largest power of 2 chunk of memory that can be allocated.
Milos Popovic, Nov 13, 2000
*/
#define EVER ;;
#define N1024*1024*16/sizeof(mytype) // Start with 16MB vector
#include stdio.h
#include stdlib.h
typedef char mytype;
int main(void)
{
size_t n = N;
mytype *x; // = (char *) malloc(n * sizeof(mytype));
for(EVER) {
x = (mytype *) malloc(n * sizeof(mytype));
if (x == NULL) {
printf(Can't assign more memory!\n);
exit(1);
}
printf(Allocated %d bytes.\n, n * sizeof(mytype));
n *= 2; // Double amount of memory to allocate next time
printf(Hit enter.); getchar();
free(x);
// x = (char *) realloc(x, n * sizeof(mytype));
printf(Hit enter.); getchar();
}
printf(Done.\n);
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[ANN] cygipc-1.13-2 released
[this announcement includes additional information; it's not identical to the one posted a hour ago] cygipc is an implementation of IPC services for cygwin. Although it will eventually be replaced by the developing cygwin daemon, cygipc is currently the more complete implementation and is used by postgresql as well as by the kde-cygwin project. Get it here: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/ cygipc-1.13-2 is a drop-in, backwards-compatible replacement for the venerable 1.11 release. (Forget the nightmare that was cygipc-1.12 -- for now. Like Freddy Krueger, it will return in the sequel as cygipc-2.x, but not yet.) cygipc-1.13-2 fixes some long-standing problems experienced by postgresql, and now returns correct error values when ipc-daemon is not running (Jason Tishler). In addition, it now allows ipc-daemon.exe to live in the Program Files directory and still run as a service, thanks to a path-quoting patch from Przemys?aw Sztoch. Further, 1.13-2 fixes a problem in which ipc-daemon --install-as-service did not properly record the desired log-verboseness level in the registry. Finally, there have been some changes in the options (although the old option switches are still supported). This change is so that we can support more finely graded levels of error reporting in the future. Previously, error logging was controlled by these two switches: -d, --debug extra verbose error reporting/logging -q, --quiet minimal error reporting/logging Now, these functions are controlled by a single option: -D, --debug-level=int Set verboseness of output. 0=quiet mode 1=normal (default) 2=verbose mode -d/--debug and -q/--quiet are still supported, but their effect is now simply: -d, --debug sets --debug-level=2 -q, --quiet sets --debug-level=0 Now, while you don't NEED to take any action, you might want to edit your ipc-daemon startup scripts or registry entries (see the README) and change '-q' to '-D 0', etc. Enjoy, Chuck (just visiting, and not really back) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Serial port problems with cygwin1.dll 1.3.15 on Win98SE
If you can zero in on the snapshot where you notice this behavior first occuring, that would be useful information. Larry Original Message: - From: Ton van Overbeek [EMAIL PROTECTED] Date: Wed, 13 Nov 2002 22:20:53 +0100 To: [EMAIL PROTECTED] Subject: Serial port problems with cygwin1.dll 1.3.15 on Win98SE When using a cross debugger (m68k-palmos-gdb) talking to a Palm device via the serial port on W98SE my system completely hangs. What I have been able to deduce is that it happens as soon as the Palm sends a debug packet to the PC. M68k-palmos-gdb opens the serial port, sets the baudrate to 57600 and puts the port in raw mode. You can still interrupt the program and do other things after this, provided the Palm has not sent any data yet. As soon as it sends data (e.g. when you start the program you want to debug) the whole system hangs. Ctrl-Alt-Delete gives a blue screen etc. I went back to older versions of cygwin1.dll and everything works fine up to version 1.3.14. So something happened between 1.3.14 and 1.3.15. I suspect some of the recent changes to fhandler-serial.cc. Any hints on how to debug this? snapshots to try? Output from cygcheck -s -r -v attached. Ton van Overbeek mail2web - Check your email from the web at http://mail2web.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Serial port problems with cygwin1.dll 1.3.15 on Win98SE
Could you run strace -o tracefile m68k-palmos-gdb , do everything you need to hang the system and send the tracefile (compressed!) to me? The tracefile will be huge -Original Message- From: Ton van Overbeek [mailto:v-overbeek;cistron.nl] Sent: Wednesday, November 13, 2002 4:21 PM To: [EMAIL PROTECTED] Subject: Serial port problems with cygwin1.dll 1.3.15 on Win98SE When using a cross debugger (m68k-palmos-gdb) talking to a Palm device via the serial port on W98SE my system completely hangs. What I have been able to deduce is that it happens as soon as the Palm sends a debug packet to the PC. M68k-palmos-gdb opens the serial port, sets the baudrate to 57600 and puts the port in raw mode. You can still interrupt the program and do other things after this, provided the Palm has not sent any data yet. As soon as it sends data (e.g. when you start the program you want to debug) the whole system hangs. Ctrl-Alt-Delete gives a blue screen etc. I went back to older versions of cygwin1.dll and everything works fine up to version 1.3.14. So something happened between 1.3.14 and 1.3.15. I suspect some of the recent changes to fhandler-serial.cc. Any hints on how to debug this? snapshots to try? Output from cygcheck -s -r -v attached. Ton van Overbeek -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Get E-mail Database TODAY
´ÞÑàÞÕ ÒàÕÜï áãâÞÚ, ÓÞáßÞÔÐ! ½ãÖÝÞ àÐáÚàãâØâì ÑØ×ÝÕá? ·ÐÚÐÖØâÕ ÑÐ×ã ÔÛï àÐááëÛÚØ ßàïÜÞ áÕÙçÐá! Á ãÒÐÖÕÝØÕÜ °ÔÜØÝØáâàÐæØï www.emailbases.ru ´ÐÝÝÐï àÐááëÛÚÐ ßàÞØ×ÒÕÔÕÝÐ Ò áÞÞâÒÕâáâÒØØ á ç.4 áâ.29 ºÞÝáâØâãæØØ ÀÄ. ²Ðè íÛÕÚâàÞÝÝëÙ ÐÔàÕá ßÞÛãçÕÝ Ø× ÞâÚàëâëå ØáâÞçÝØÚÞÒ. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: No subjects are nice
Christopher Faylor wrote: On Wed, Nov 13, 2002 at 12:38:56PM -0800, Jake D. Stern wrote: [This is a bug report, I'm following cygwin reporting instructions by posting here. The subject line has been changed so as to not be refused. Original subject line: xterm consumes 100% cpu when first XWin action is to close xterm.] The fact that your subject was blocked didn't give you enough of a clue that you were doing something wrong, eh? The mind boggles. We HAVE A MAILING LIST for Cygwin/XFree86 discussions. Use it. FYI, I've blocked this subject too. I can keep this up all day if you want. rant From my standpoint this habit of blocking arbitrary subjects defeats the purpose of a mailing list in the first place. It essentially puts one person in place as arbiter. The user has no idea whether or not his subject is on the list. It would be much easier if the various lists were echoed to usenet in the first place. They could even be moderated groups. Adding a mailing list to someones setup requires both subscribing (after hearing about it in the first place) and setting up suitable e-mail filters. Having done so the e-mail volume increases substantially, with much greater likelihood of filling an ISPs assigned storage. Generally a pain. In addition I found very early that the searching provisions either don't function or are non-intuitive. It is much easier to search newsgroups on google. I gave up long ago on finding out why 'reply-to considered bad on cygwin list'. Also consider that e-mail and newsgroups can be generally operated off-line. Reading something that simply suggests a search is counter-productive, especially when a one or two line response would largely cover it. c.l.c sticks pretty closely to the topic, with exceptions, and raises hackles. However the hackles raised are generally of the clueless - here the irritation seems to be unrestricted, and only old hands appear to be welcome. Again, with notable exceptions. I concede that my viewpoint is not yours, and neither are my priorities. /rant -- Chuck F ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: ld crash
On Wed, Nov 13, 2002 at 09:53:47PM -0500, Braden McDaniel wrote: On Wed, 2002-11-13 at 20:05, Billinghurst, David (CRTS) wrote: This is a libtool problem. If you do not find a more sophisticated fix you might try renaming or deleting /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libstdc++.la. Could you elaborate on the nature of the problem? Or is this documented somewhere? I can't elaborate because I don't know why it's broken but I can confirm that David is correct. I meant to remove this from the last gcc release but I forgot. I would suggest that everybody who has gcc installed do a rm -f /usr/lib/*.la. I'll be doing the equivalent in the next release. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
/bin/shutdown on ME
Hi, all:
When I try to shutdown -r now, Windows (ME 4.90.3000) complains that I must quit
[shutdown] before I quit Windows. If I click Cancel, shutdown complains shutdown:
Couldn't reboot: Incorrect function., and if I click OK, windows reports after a
while that shutdown isn't responding, and gives the Wait/End Task/Cancel dialog. :-(
Is this a known limitation of cygwin on ME, or should I delve further?
Attached is my cygcheck -s -v -r (which BTW the FAQ#SEC29 still directs to be pasted
into the message.)
Thanks,
Chris
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Nov 13 21:18:04 2002
Windows ME Ver 4.90 Build 3000
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\bin
c:\WINDOWS
c:\WINDOWS\COMMAND
C:\cygwin\USR\X11R6\BIN
c:\WINDOWS\TWAIN_32\SCANWIZ
c:\PROGRA~1\MOVIES~1\BIN
C:\cygwin\usr\X11R6\bin
SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS
CYGWIN = `ntea'
HOME = `C:\cygwin\home\default'
MAKE_MODE = `unix'
PWD = `/home/default'
USER = `default'
CLASSPATH = `C:\Program Files\JavaSoft\JRE\1.3.1\lib\ext\QTJava.zip'
COLORFGBG = `default;default'
COLORTERM = `rxvt-xpm'
COMSPEC = `C:\WINDOWS\COMMAND.COM'
DISPLAY = `:0'
EDITOR = `nano'
HOMEDRIVE = `C:'
HOMEPATH = `\cygwin\home\default'
MAIL = `/home/default/Mail/inbox'
MANPATH = `:/usr/ssl/man'
OLDPWD = `/usr/bin'
PROMPT = `$p$g'
PS1 = `\[\033]0;\w\007
\033[32m\]\u\h \[\033[33m\w\033[0m\]
$ '
QTJAVA = `C:\Program Files\JavaSoft\JRE\1.3.1\lib\ext\QTJava.zip'
SHLVL = `1'
TEMP = `c:\WINDOWS\TEMP'
TERM = `rxvt'
TEXMF = `{/usr/share/lilypond/1.6.5,/usr/share/texmf}'
TMP = `c:\WINDOWS\TEMP'
WINBOOTDIR = `C:\WINDOWS'
WINDIR = `C:\WINDOWS'
WINDOWID = `10035896'
_ = `/usr/bin/cygcheck'
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
Menu\Programs\Cygnus Solutions
(default) = (unsupported type)
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/PalmDev
(default) = `C:\PalmDev'
flags = 0x
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts
v2\/usr/lib/gcc-lib/m68k-palmos
(default) = `C:\cygwin\lib\gcc-lib\m68k-palmos'
flags = 0x
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts
(default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:/cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:/cygwin/bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:/cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
a: fd N/AN/A
c: hd FAT32 33709Mb 75% CPUN
d: hd FAT32 4443Mb 43% CPUN SYSTEM_SAV
e: fd N/AN/A
f: cd CDFS 434Mb 100%JSPRE_K
g: cd N/AN/A
C:\PalmDev /PalmDev usertextmode
C:\cygwin\lib\gcc-lib\m68k-palmos /usr/lib/gcc-lib/m68k-palmos usertextmode
. /cygdrive user
binmode,cygdrive
C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode
C:/cygwin / system binmode
C:/cygwin/bin /usr/bin system binmode
C:/cygwin/lib /usr/lib system binmode
. /cygdrive user
binmode,cygdrive
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: c:\WINDOWS\COMMAND\find.exe
Warning: C:\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\sh.exe
475k 2002/10/11 C:\cygwin\bin\cygcurl-2.dll - os=4.0 img=1.0 sys=4.0
cygcurl-2.dll v0.0 ts=2002/10/11 16:53
19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
cyggdbm.dll v0.0 ts=2002/2/19 21:05
45k 2002/02/08 C:\cygwin\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
Re: ld crash
Christopher Faylor wrote: On Wed, Nov 13, 2002 at 09:53:47PM -0500, Braden McDaniel wrote: On Wed, 2002-11-13 at 20:05, Billinghurst, David (CRTS) wrote: This is a libtool problem. If you do not find a more sophisticated fix you might try renaming or deleting /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libstdc++.la. Could you elaborate on the nature of the problem? Or is this documented somewhere? I can't elaborate because I don't know why it's broken but I can confirm that David is correct. I meant to remove this from the last gcc release but I forgot. I would suggest that everybody who has gcc installed do a rm -f /usr/lib/*.la. I'll be doing the equivalent in the next release. NOOO DO NOT rm -f /usr/lib/*.la!!! There are more .la files in there than simply the ones from gcc; it's the gcc-supplied .la files that are causing the problem, not the other ones. The reason the gcc-supplied .la files are causing a problem is because they specify only a static lib, and not a DLL. (Of course, since gcc doesn't supply the runtime libs in DLL form, the .la files can't very well specify DLLs.) Upcoming libtool works around this problem with gcc's .la files. Upgrade to the experimental libtool-devel package here: http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/ I'm trying to get these patches accepted into libtool CVS http://mail.gnu.org/pipermail/libtool-patches/2002-November/002236.html Since cgf has brought this issue out, I'll be putting the experimental libtool-devel on sources as a 'test' release soon. (Were you trying to prod me, Chris?) --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: No subjects are nice
On Wed, Nov 13, 2002 at 06:35:49PM -0500, CBFalconer wrote: Christopher Faylor wrote: On Wed, Nov 13, 2002 at 12:38:56PM -0800, Jake D. Stern wrote: [This is a bug report, I'm following cygwin reporting instructions by posting here. The subject line has been changed so as to not be refused. Original subject line: xterm consumes 100% cpu when first XWin action is to close xterm.] The fact that your subject was blocked didn't give you enough of a clue that you were doing something wrong, eh? The mind boggles. We HAVE A MAILING LIST for Cygwin/XFree86 discussions. Use it. FYI, I've blocked this subject too. I can keep this up all day if you want. rant From my standpoint this habit of blocking arbitrary subjects defeats the purpose of a mailing list in the first place. It essentially puts one person in place as arbiter. The user has no idea whether or not his subject is on the list. The user can easily figure out if his subject is on the list when they get a bounce saying they are off-topic. That is a signal that there is something suspect about their message. Apparently, the message saying You're off-topic, if you have questions send email to [EMAIL PROTECTED] is viewed as a challenge since more than one person has tried to circumvent the block and, instead of either doing the research to figure out why their email could be off-topic or even asking [EMAIL PROTECTED] for clarification, they, instead, decide to try alternatives until they succeed in getting their off-topic post on the cygwin mailing list. The logical thought processes involved in so doing escape me. Often it is probably it's just a lack of familiarity with sending messages to a public forum. It would be much easier if the various lists were echoed to usenet in the first place. This list is available as a private newsgroup. If you mean that it should be in some alt or comp usenet hierarchy then we've already had that newsgroups am better discussion here fairly recently. They could even be moderated groups. Mailing lists can be moderated. It takes *a lot* of effort to moderate mailing lists or newsgroups that are filled with newbies and the incalcitrant clueless. I sincerely doubt that anyone would want to moderate a forum that has as much traffic as this one. Adding a mailing list to someones setup requires both subscribing (after hearing about it in the first place) and setting up suitable e-mail filters. Having done so the e-mail volume increases substantially, with much greater likelihood of filling an ISPs assigned storage. Generally a pain. You think that I should spend a few weeks trying to get the cygwin mailing list into an alt usenet group because it makes your life easier? Not interested. You have the power. Again, if this is a big deal for you, then start your newsgroup and convince everyone to move over. Personally, I have no intention of adding YA official forum for sending cygwin observations, however. I'm not going to force people to subscribe to a newsgroup if they want to ask a cygwin question. Amusingly enough, moderating a forum generates pretty much the same result as what is happening now, even down to the one person is the arbiter part. Either you get an automated bounce or you get email from someone telling you why your message wasn't accepted. The majority of the off-topic posts in the cygwin mailing list are explicitly sent to the cygwin-xfree mailing list by an email. Some get an automated bounce. Not much different from a moderated list except that it's actually a lot more open. Additionally, there are a number of people who aren't even aware of usenet. Why would we want to educate them in what usenet is and how to set up their nntp server so that they can communicate about a problem? That's just adding more work for the old hands. Or, actually, it would focus the problem very nicely on one old hand -- me. It would increase the email to sourcemaster from people who can't figure out how to read news. No thanks. In addition I found very early that the searching provisions either don't function or are non-intuitive. It is much easier to search newsgroups on google. I gave up long ago on finding out why 'reply-to considered bad on cygwin list'. I will concede that searching for a message with the string reply-to in it is not going to be useful however I just tried it on google.com google.com is a good way to search the sources.redhat.com mailing lists. Look for reply-to bad site:cygwin.com and you'll find it within the first few links. Also consider that e-mail and newsgroups can be generally operated off-line. Reading something that simply suggests a search is counter-productive, especially when a one or two line response would largely cover it. Yeah. Except when 27 people send in the answer. Then we have even more traffic. Again, no thanks. This is a fish teaching mailing list. Or, are you referring to when you asked me why reply-to was considered
Re: ld crash
On Wed, Nov 13, 2002 at 10:48:38PM -0500, Charles Wilson wrote: NOOO DO NOT rm -f /usr/lib/*.la!!! You're right. I'm very wrong. Sorry for the misinformation. These are the specific files that should be removed: -rwxrwxrwx cgf/group 674 2002-11-08 23:01:47 usr/lib/libg2c.la -rwxrwxrwx cgf/group 771 2002-11-08 23:01:47 usr/lib/libgcj.la -rwxrwxrwx cgf/group 776 2002-11-08 23:01:47 usr/lib/libstdc++.la -rwxrwxrwx cgf/group 776 2002-11-08 23:01:47 usr/lib/libsupc++.la Since cgf has brought this issue out, I'll be putting the experimental libtool-devel on sources as a 'test' release soon. (Were you trying to prod me, Chris?) As someone who has publicly expressed my distate for libtool and my lack of warm fuzzy feeling for autotools in general, I think you can safely assume that I wasn't trying to prod you to do anything libtool related. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
How to run SDL native with Cygwin
From http://www.libsdl.org/extras/win32/cygwin/ : Steps to build SDL natively with the Cygwin environment available at: http://www.cygwin.com/ These steps assume that you are comfortable with the UNIX environment. Step 1. Run the Cygwin setup program, install the default packages and the development packages (adding any extras you want, like vim). Step 2. Run the Cygwin shell. Further instructions assume you're in this shell. Step 3. Extract the SDL source into a directory and run: ./configure make make install Step 4. When you're ready to build SDL applications, copy SDL.dll from /usr/local/lib to whereever your SDL application source resides. Troubleshooting: === Q: I get an error when building and I unpacked the source in a path with spaces. A: Unpack the source in a path without spaces, like /tmp, and build there. === Q: I get the following error while building SDL: GL/gl.h: No such file or directory A: You need to get the OpenGL development headers from: http://www.libsdl.org/extras/win32/cygwin/opengl-devel.tar.gz You need to unpack these in the /usr directory. === Q: My version of SDL doesn't have DirectX support! A: You need to get the DirectX development headers and libraries from: http://www.libsdl.org/extras/win32/cygwin/directx-devel.tar.gz You need to unpack these in the /usr directory. === Q: My version of SDL doesn't have assembly support, NASM is not available. A: You need to get nasm assembler from: http://www.libsdl.org/extras/win32/cygwin/nasm.exe Put this file in the /usr/bin directory. === ___ Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: recvfrom bug
On Wed, Nov 13, 2002 at 11:11:50PM -0500, Dr. M. C. Nelson wrote:
Dear mailing list:
The following code works well on a Linux platform,
int sockfd;
char buf[1024];
struct sockaddr fromaddr;
int fromlen;
I assume that this is just a code snippet and sockfd is actually
set to something sane.
if ( (retv = recvfrom( sockfd, buf, sizeof(buf), 0, fromaddr,fromlen )) 0 )
{
perror( udpclient: recvfrom );
}
However, in cygwin the following error message is produced:
udpclient: recvfrom: Bad address
Can anyone tell me how to get pas this problem?
Pleas reply, to mailto:mcnelson;mindspring.com I am not a subscriber.
Are you sure you're running the latest version of cygwin? A problem
related to this was fixed several releases ago.
http://cygwin.com/bugs.html might prove interesting reading. You've
provided all of the details needed except the cygcheck output mentioned
on that page.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: help: cygwin on WinNT - allocates 3x memory asked for
*** Posted and mailed *** Milos Popovic wrote: ... snip ... PROBLEM: a C program written to allocate x amount of memory actually uses about 3 times that much memory, when compiled with gcc (3.2-2) under cygwin (1.3.15-2). This does not occur when compiling with a native windows compiler (I used lcc) where allocating 50MB increases the system memory used by roughly the 50MB. The program below tries to allocate memory starting with 16MB and doubling the allocation until it fails. The getchar statements are there to interrupt the program and wait for a keypress so that I can monitor the amount of memory used by the system in the Windows NT Task Manager before and after each allocation. The result is that a 512MB allocation actually increases the system memory usage by about 1500MB. This ratio of 3 is the same regardless of the size of allocation. When compiled with a native compiler (non-cygwin), a 512MB allocation increases the used ram by about 512MB. I also tried using realloc instead of malloc/free for successive allocations - no difference. C++ version with new/delete on g++ - also no difference. The factor of 3 is also the same whether you're allocating a vector of chars, doubles, etc. ... snip code ... You are probably looking at the underlying system allocation of virtual memory. When memory can be allocated with an allocate on write policy, it makes sense to reserve a ratio of virtual allocation to real allocation (which is not actual memory) of that sort. I don't know just how Cygwin allocates, but it probably involves a sbrk (unix like) call, which in turn calls some windows mechanism. One of those mechanisms is anticipating future requirements on the basis of actual allocation so far. With appropriate policies this can be done at no cost, although the system has been known to bite when the memory is actually written, and thus gobbles disk space for the virtual image. Strictly speaking the policy is not ISO C conforming. BTW note that your policy of doubling the size prevents ever reusing previously allocated and freed memory. This in itself forces the system memory assigned to always have a useless fragment slightly smaller than the last allocation. 1/2 + 1/4 + 1/8 + ... is always smaller than 1. You would probably have widely different results if you wrote all over each allocated block when assigned. I hope this makes some sense to you. At any rate, I wouldn't worry about it. -- Chuck F ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest Bison causes SaveMyModem build to to choke
--- Andrew Lynch wrote: Hi, I have been using bison 1.35 as part of the build process for SaveMyModem debugging/improvements I am doing. Yesterday, I updated to bison 1.75 and it broke the build reporting a parse error. I deinstalled 1.75 and retreated to 1.35 and everything works again. I am only barely aware of what bison is, much less know how to debug it, but if anyone is interested I will get more detailed bug reports and sample parser.yy files, etc to help run this bug to ground. In the meantime, check out SaveMyModem and send lots of great patches http://sourceforge.net/projects/savemymodem Andrew Lynch __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Notice of intention to release Perl module specific to Cygwin
On Tue, 12 Nov 2002 21:08:08 GMT, Gerrit P. Haase [EMAIL PROTECTED] wrote in news:8-1996164353.20021112220808;familiehaase.de: Soren: on Cygwin, there is always going to be more than one canonical-ly-correct way to refer to a file by path name (!!): [...] So my present analysis is that my module belongs in a base namespace of Filesys:: and maybe could be named CygwinPaths? I think it would keep the maintainer of Cygwin Perl happy -- or should -- if named like this. What do YOU think? If you like, why not introduce a namespace CYGWIN:: or Cygwin::, e.g. there are several modules you didn't mention which are supposed to run *for* or *with* a specific application like Apache:: or XMail:: or PLP:: or YAML::, so why not introduce the namespace Cygwin:: (if you look at Cygwin like just another application). I would be perfectly happy with a Cygwin:: namespace! Gerrit, as you've seen now if you've been keeping up with replies on the module-authors List (which I think you have), there's some feeling expressed so far against that. On the balance, unless and until someone else checks in with a cogent and authoritative proposal to the contrary (and the comment about File::Spec:: wasn't completely off the mark but it doesn't fit, IMO), I think a second-level namespace is going to win the project more friends and support in the Perl community. In no way does that mean that someone (me, or not me) could not add (or argue for adding) a Cygwin:: module down the road. I just don't see my module as needing that kind of big umbrella to sit under. BTW, glitches permitting, I am going to be uploading v0.03 to my CPAN space (SOMIAN in the Authors index) tonight. I think this is the good one, the first real serious grown-up release that's actually ready to be used a little for some actual work (please don't try to design guided-missile controls around it though, I beg of one and all). Filesys-CygwinPaths-0.03.tar.gz. Cygwin-perl users, meet your new friend. Best, Soren A -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
recvfrom bug
Dear mailing list:
The following code works well on a Linux platform,
int sockfd;
char buf[1024];
struct sockaddr fromaddr;
int fromlen;
if ( (retv = recvfrom( sockfd, buf, sizeof(buf), 0, fromaddr,fromlen ))
0 )
{
perror( udpclient: recvfrom );
}
However, in cygwin the following error message is produced:
udpclient: recvfrom: Bad address
Can anyone tell me how to get pas this problem?
Pleas reply, to mailto:mcnelson;mindspring.com
I am not a subscriber.
Thank you,
Mitch Nelson
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
console title
Hello,
When a window title of cygwin console is displayed with escape
sequence (\033]0;title\007), it can't be displayed if it includes
non-ASCII characters (\200..\0377).
Is the following patch acceptable ?
--- fhandler_console.cc.origThu Nov 14 14:51:30 2002
+++ fhandler_console.cc Thu Nov 14 15:01:54 2002
@@ -1530,7 +1530,7 @@
case gettitle:
{
int n = strlen (dev_state-my_title_buf);
- if (*src ' ' || *src = '\177')
+ if (*src ' ' || *src = '\377')
{
if (*src == '\007' dev_state-state_ == gettitle)
{
PS.
Thanks for the fix of mouse support.
---
Hironori SAKAMOTO [EMAIL PROTECTED]
http://www2u.biglobe.ne.jp/~hsaka/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
