RE: lesstif
Original Message From: Brian Ford Sent: 15 September 2005 23:20 I am confused, though. The crash you presented to me was one of not being able to start nedit at all: Date: Fri, 01 Jul 2005 17:09:32 -0700 From: Harold L Hunt To: Brian.Ford Subject: Re: lesstif update request Brian, Nope, 0.94.4 doesn't work with nedit: --- nedit.exe - Application Error --- The application failed to initialize properly (0xc005). Click on OK to terminate the application. --- OK --- That was the binutils relocs-in-non-writable-.rodata sections problem, wasn't it? (I'm afraid that vague description of the problem is probably also at least a bit inaccurate, but I do remember there being some kind of problem with stuff that needed relocating being put into a section that was mapped read-only in the loaded image file). cheers, DaveK -- Can't think of a witty .sigline today
Re: Adding a Maintainer: field to setup.hint
On Sep 15 21:03, Eric Blake wrote: I'm thinking about adding a maintainer field to setup.hint which would have meaning only in setup.hint but would allow us to more easily track who maintains what. It would look like this: Maintainer: Chris Faylor i.e., no email address, just a person's name (for obvious reasons). I could then add this information to the cygwin packages web page. I'm all for it. Orphaned packages would be changed to either Orphaned or Up for Grabs or MIA. I'd go for Orphaned. Does anyone have a problem with this? If not, I'll use the info that Corinna is gathering to modify the setup.hints on sourceware.org. cgf Also, the package maintainence instructions should be updated to state that once you are a maintainer, you are considered to be the maintainer until you provide a new setup.hint changing the Maintainer: field, or when a request to reach you on the cygwin-apps list goes unanswered for a period of time (6 weeks, like the current maintainer poll?). That might be a good idea. We should also add that setup.hint is required to contain a maintainer line from now on. Should we also have some sort of timeout policy on obsolete packages, where once a package has been in the _obsolete category for at least 2 years (or some other time length) it is automatically a candidate for removal from the distro? That's tricky. I'm all for it but people will have dependencies on obsoleted packages. On the other hand, even Linux distros don't keep all compatibility packages around and sometimes an entire tool is obsoleted and removed because there's a shiny replacement. 2 or 3 years sounds good to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: [HEADSUP] ALL Maintainers, please reply.
Guys, On Sep 15 19:50, Yaakov S wrote: Harold L Hunt II wrote: Yaakov S wrote: I've already built 2.1.9 in order to run the current GIMP, so if you're not interested in updating this one, please let us know. It's yours. Accepted. I'll have an update out in the next few days. are you aware what you're doing here? How should anyone follow which package belongs to whom if you discuss moving packages around all the time? It's nice that you care but it would be nice for the sake of bookkeeping, if all maintainers who have given away and who have taken over a package at this point, could please send their updated lists of packages again. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: libungif [Was: Re: [HEADSUP] ALL Maintainers, please reply.]
Harold L Hunt II wrote: The README for both versions still lists you as the maintainer. The evidence is on your side. Moreover I am quite braindead at the moment (I've got a nice -n -20 openoffice thesis.odt process taking up most of it), and that makes even easier for you to be right and me to remember wrong ;-) At this time I'd have to say that it doesn't make a lot of sense for me to become the maintainer, but I'd pick it up if the alternative was that it would be removed from the distro. Actually, the same goes for me: ok that I'm not very interested in it, but letting a package die seems too much of a shame to me. BTW: but in September 2005 is there still a reason to have libUNgif? http://en.wikipedia.org/wiki/GIF#Unisys_and_LZW_patent_enforcement On June 20 http://en.wikipedia.org/wiki/June_20, 2003 http://en.wikipedia.org/wiki/2003, the United States patent on the LZW algorithm expired [2] http://www.unisys.com/about__unisys/lzw, which means that Unisys and Compuserve can no longer collect royalties for use of the GIF format in that country. Those bothered with the patent enforcement dubbed this day GIF Liberation Day. The equivalent patents in Europe and Japan expired on June 18 http://en.wikipedia.org/wiki/June_18 and June 20 http://en.wikipedia.org/wiki/June_20, 2004 http://en.wikipedia.org/wiki/2004 respectively, with the Canada patent following on July 7 http://en.wikipedia.org/wiki/July_7. Is it *still* active somewhere? Oven the official homepage doesn't seem to mention any place where it is: http://www.unisys.com/about__unisys/lzw I guess it MAY really be time to let libungif die, afterall, to be followed by libgif, of course. (another argument, of course, may state that it is better to use a crippled library, as this eases the process of migrating to newer and better formats, but I guess that by today if one is still using GIF he probably got a legacy software problem and, well, knows what he really needs) -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (ICQ UIN: 529796)
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, Sep 15, 2005 at 06:45:37PM +0200, Corinna Vinschen wrote: Mails in the last couple of weeks indicate that we have lost one or the other maintainer without getting any notice from them. Since we have a couple of packages which haven't been updated for a good amount of time, there's apparently a need to find out, which packages are still maintained and which have lost their maintainer on the way. So, ALL maintainers of Cygwin packages, please reply to this mail within the next six weeks, including a list of ALL packages you maintain. This survey will run until 2005-10-31. I will ping every week, so you have a bit of time. However, if you don't reply until 2005-10-31, your packages will be up for grabs. Which means, they will disappear from the Cygwin net distribution if nobody wants to take over maintainership. I maintain: fortune I hope there will be an interval (a month?) between declaring packages up for grabs and actually removing them.
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, Sep 15, 2005 at 08:34:15PM +0200, Gerrit P. Haase wrote: Corinna Vinschen wrote: including a list of ALL packages you maintain. GConf2 OpenSP antiword atk* check db* libdb* enscript exif libexif* expat freeglut gcc* glib2* gnome-vfs2 gnutls* libgnutls11 gtk2-x11* indent intltool jasper lcms libart_lgpl libcroco libcroco06 libfpx libgnome2 libgnomeui2 libmng libtasn1 libwmf libxml2* libxslt opencdk openjade pango* perl perl_manpages Have I missed one? If anyone is interested to take over one or more packages feel free to do so, just drop me a note in my inbox. There are also packages in my private repository which could be taken, i.e. Gnome desktop related packages are done by Yaakov and me and there are at least 100 packages needed to run Gnome, not counted the bindings (Perl/C++/Python/Java/...) and applications. What do the *'s mean?
Re: [HEADSUP] ALL Maintainers, please reply.
On Sep 16 01:18, Yitzchak Scott-Thoennes wrote: I maintain: fortune I hope there will be an interval (a month?) between declaring packages up for grabs and actually removing them. Of course. Everybody has the right to be on vacation for some time ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: [HEADSUP] ALL Maintainers, please reply.
On Sep 16 01:18, Yitzchak Scott-Thoennes wrote: On Thu, Sep 15, 2005 at 08:34:15PM +0200, Gerrit P. Haase wrote: GConf2 OpenSP antiword atk* check db* libdb* [...] What do the *'s mean? Take it as a wildcard character as in filename pattern matching. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
Re: [HEADSUP] ALL Maintainers, please reply.
Missed two: libbonobo2 libbonoboui2 Gerrit P. Haase wrote: Corinna Vinschen wrote: including a list of ALL packages you maintain. GConf2 OpenSP antiword atk* check db* libdb* enscript exif libexif* expat freeglut gcc* glib2* gnome-vfs2 gnutls* libgnutls11 gtk2-x11* indent intltool jasper lcms libart_lgpl libcroco libcroco06 libfpx libgnome2 libgnomeui2 libmng libtasn1 libwmf libxml2* libxslt opencdk openjade pango* perl perl_manpages Have I missed one? If anyone is interested to take over one or more packages feel free to do so, just drop me a note in my inbox. There are also packages in my private repository which could be taken, i.e. Gnome desktop related packages are done by Yaakov and me and there are at least 100 packages needed to run Gnome, not counted the bindings (Perl/C++/Python/Java/...) and applications. Gerrit -- =^..^=
Re: How about script? [was: Re: Command 'more': missing dll cygpcre.dll [Attn more maintainer]]
James R. Phillips wrote: --- Christopher Faylor wrote: Checking various linux systems: % rpm -q -f /bin/more util-linux-2.12p-9.3 % dpkg -S /bin/more util-linux: /bin/more % epm -q -f /bin/more util-linux-2.12q-r1 So, no, I will not be including a 'more' symlink in the 'less' package. I'll take on 'more' maintenance responsibilities. cgf Hm, another program in util-linux that would be nice to have is 'script'. All linux systems have it. Is anyone interested in taking that on ? script does not build out of the box. I ported another similar tool, I believe Reini has done something similar. Unfortunately I cannot find the announcement / bookmark / package name / patch. Gerrit -- =^..^=
Re: [HEADSUP] ALL Maintainers, please reply.
Yaakov S wrote: Gerrit P. Haase wrote: Have I missed one? gtk-doc? Yes, you're right. If anyone is interested to take over one or more packages feel free to do so, just drop me a note in my inbox. There are also packages in my private repository which could be taken, i.e. Gnome desktop related packages are done by Yaakov and me and there are at least 100 packages needed to run Gnome, not counted the bindings (Perl/C++/Python/Java/...) and applications. Does that mean you don't intend to update your GNOME packages? I will do updates and also include more/missing Gnome packages, however I would not mind to have some more maintainers to help us two. In any case, I would like first claims to anything GNOME related, as I've already put so much work into it. Gerrit -- =^..^=
Re: [HEADSUP] ALL Maintainers, please reply.
Corinna Vinschen wrote: So, ALL maintainers of Cygwin packages, please reply to this mail within the next six weeks, including a list of ALL packages you maintain. tcm psutils Daniel
Re: libungif [Was: Re: [HEADSUP] ALL Maintainers, please reply.]
Lapo Luchini wrote: Is it *still* active somewhere? libungif is (at least) in use by: WindowMaker emacs-X11 imlib I need it for some other packages not yet released. Gerrit -- =^..^=
Re: [HEADSUP] ALL Maintainers, please reply.
On Thu, 2005-09-15 at 20:36 +0200, Gerrit P. Haase wrote: Christopher Faylor wrote: On Thu, Sep 15, 2005 at 07:41:24PM +0200, Corinna Vinschen wrote: On Sep 16 03:36, Robert Collins wrote: I'm still here, but not actively maintaining packages, offhand that means dpkg, squid probably need excising or new maintainers. Er... what does that mean, dpkg and squid have a maintainer or dpkg and squid have no maintainer? He's saying that they have no maintainer currently so they may need to be removed from the distribution. I use SquidNT quite happily, the native port has improved very much in the last one-two years, they even have included SSL support recently. Yes, Guido is doing a great job there, and I don't think any of us (upstream) are caring about bugs in the cygwin build at this point. Rob signature.asc Description: This is a digitally signed message part
Re: [HEADSUP] ALL Maintainers, please reply.
Corinna Vinschen writes: please reply to this mail within the next six weeks, including a list of ALL packages you maintain. texi2html openldap libopenldap2 libopenldap2_2_7 openldap-devel t1lib t1lib-x1 aspell-de aspell-pl gd libgd-devel libgd2 gnuplot gv man tzcode WordNet xemacs xemacs-emacs-common xemacs-mule-sumo xemacs-sumo xemacs-tags XmHTML xpdf Ciao Volker
Re: [HEADSUP] ALL Maintainers, please reply.
cabextract bzr bogofilter(Still ITP; no review) tinyirc (Still ITP; no review) Jari
Re: Adding a Maintainer: field to setup.hint
[EMAIL PROTECTED] (Eric Blake) writes: |Maintainer: Chris Faylor | Orphaned packages would be changed to either Orphaned or Up for Grabs | or MIA. | | I'd go for Orphaned. Yes, make it read Orphaned | Also, the package maintainence instructions should be updated | to state that once you are a maintainer, you are considered to | be the maintainer until you provide a new setup.hint changing | the Maintainer: field, or when a request to reach you on the | cygwin-apps list goes unanswered for a period of time (6 weeks, | like the current maintainer poll?). It would be nice if the package listing page http://cygwin.com/packages/ would read: package uploaded maintainer description --- -- -- Especially the uoloaded would hold -MM-DD which could be checked easily for packages that havenät touched for long time. Perhaps a script could even send periodic messages after 6 months of no activity or update to ping the situation. | Should we also have some sort of timeout policy on obsolete | packages, where once a package has been in the _obsolete | category for at least 2 years (or some other time length) it is | automatically a candidate for removal from the distro? Again a script to could watch the upload time and send t this list: Subject: NOTICE: foo-1.2.4 has been expired 2 year limit, up for grabs Jari
Re: [ITP] id3lib and easytag
On Tue, 13 Sep 2005, Corinna Vinschen wrote: Ok, I got a decision. We can include easytag and id3lib into the distribution if you take out the MP3 related code, which is libmpg, IIUC. The package would still be able to work with Ogg/Vorbis, Flac, etc, right? Disabling mp3 is not supported in easytag. you can disable ogg, flac and mp4 but mp3 seems to be core functionality. Therefore I withdraw the ITP. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: ATTN: antiword Maintainer
Gerrit P. Haase [EMAIL PROTECTED] writes: | Buchbinder, Barry (NIH/NIAID) wrote: | | Current Cygwin: | Version: 0.34 (25 Aug 2003) | on http://www.winfield.demon.nl/ | version 0.36.1 (09 Dec 2004) | | You want to take over the maintainer position of this package? | Fine with me. Just make a new release, I'll review your package. Here is one. Barry do you want to have antiword? Jari sdesc: MS-Word to text converter. ldesc: MS-Word reader which can convert documents from Word 2, 6, 7, 97, 2000, and 2002 to text and Postscript. The layout of the document is kept intact if possible. category: Doc requires: cygwin A) Use this: wget --non-verbose\ http://cygwin.cante.net/antiword/setup.hint \ http://cygwin.cante.net/antiword/antiword-0.36.1-1.tar.bz2.sig \ http://cygwin.cante.net/antiword/antiword-0.36.1-1.tar.bz2 \ http://cygwin.cante.net/antiword/antiword-0.36.1-1-src.tar.bz2.sig \ http://cygwin.cante.net/antiword/antiword-0.36.1-1-src.tar.bz2 B) OR use this (automated; get.sh will print further details) gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir antiword ; cd antiword rm -f get.sh get.sh.sig wget -q http://cygwin.cante.net/antiword/get.sh \ http://cygwin.cante.net/antiword/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh
Re: [HEADSUP] ALL Maintainers, please reply.
I'm the maintainer of: autossh lablgtk2 orpie stow unison unison2.9.1 unison2.9.20 unison2.10.2 unison2.12.0 unison2.13 unison2.17 Andrew.
[not GTG] Re: ITP: bogofilter -- Statistical Bayesian spam filter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jari Aalto on 9/12/2005 7:43 AM: | sdesc: bogofilter - Statistical Bayesian spam filter. | ldesc: Bogofilter is a Bayesian spam filter that classifies mail as | spam or ham (non-spam) by a statistical analysis of the message's | header and content (body). The program is able to learn from the | user's classifications and corrections. It takes an email message or | other text on standard input, does a statistical check against lists | of good and bad words, and returns a status code indicating | whether or not the message is spam. It is designed with fast | algorithms (including Berkeley DB system), and tuned for speed, so it | can be used for production by sites that process a lot of mail | category: Mail | requires: cygwin libgsl0 libgslcblas0 I'm finally getting time to do a review. Once you fix these problems, it will make a good addition since debian already carries the package. Binary package: etc/postinstall/bogofilter.sh: - -typo s/CYGIN/CYGWIN/ - -Install() only creates /etc/bogofilter.cf once, but if the user does not touch this file, then when they upgrade bogofilter, they should get the latest and greated bogofilter.cf instead of being stuck with the one from their first download. - -Install() used a wildcard to find the file, which is not safe - spell out the full directory name. usr/share/doc/Cygwin/bogofilter-0.96.1.README: - -readme mentions bogofilter-0.92.4-1 internally - make this consistent - -file listing in the readme omits the scripts in /usr/bin - -typo s/licence/license/. However, I like the idea of adding License: and Language: sections to the generic package template. - -the generic template mentions that the upstream docs are available in /usr/share/doc/package-ver/ binaries appear to work with my limited testing. Small change. It appears that: $ cygcheck /usr/bin/bogofilter ... D:\cygwin\bin\cyggsl-0.dll D:\cygwin\lib\lapack\cygblas.dll And the library comes from: gsl-1.4-2.tar.bz2:/usr/bin/cyggsl-0.dll so 'requires:' header should probably read: requires: cygwin gsl Correct. However, setup.hint's sdesc: is redundant (don't list your package name as the first word, or setup.exe will show bogofilter: bogofilter - Statistical Bayesian spam filter.) Also, I think the common practice is for sdesc to not end in '.' Question for the list - is it traditional for setup.hint to list the transitive closure of dependencies, or just the direct dependencies? In other words, bogofilter depends indirectly on lapack (provider of cygblas.dll), but it is possible to use gsl without lapack by recompiling an optimized alternative cygblas.dll. I'm leaning towards listing only direct dependencies in setup.hint, and letting setup.exe do the transitive closure, but then I've realized that even my own bash setup.hint does a transitive closure. Source package: - -why is the binary package included inside the source package? - -'bogofilter*.sh all' failed with: libbogofilter.a(lexer.o): In function `text_decode': /tmp/bogofilter/bogofilter-0.96.1/.build/build/src/lexer.c:480: undefined reference to `_iconv_close' libbogofilter.a(iconvert.o): In function `convert': /tmp/bogofilter/bogofilter-0.96.1/.build/build/src/iconvert.c:88: undefined reference to `_iconv' libbogofilter.a(convert_unicode.o): In function `bf_iconv_open': /tmp/bogofilter/bogofilter-0.96.1/.build/build/src/convert_unicode.c:109: undefined reference to `_iconv_open' /tmp/bogofilter/bogofilter-0.96.1/.build/build/src/convert_unicode.c:117: undefined reference to `_iconv_open' libbogofilter.a(convert_unicode.o): In function `init_charset_table_iconv': /tmp/bogofilter/bogofilter-0.96.1/.build/build/src/convert_unicode.c:129: undefined reference to `_iconv_close' Info: resolving _opterr by linking to __imp__opterr (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) Info: resolving _optarg by linking to __imp__optarg (auto-import) collect2: ld returned 1 exit status make[3]: *** [bogofilter.exe] Error 1 make[3]: Leaving directory `/tmp/bogofilter/bogofilter-0.96.1/.build/build/src' Did something go wrong in detecting -liconv? Which also means your setup.hint should probably depend on libiconv2. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKsKi84KuGfSFAYARAsdmAKCFkiOFmTZkY8cw64IaIg6KuMYdfACfdDNE M8u9Gg+AB0c0vY/2oywE0TI= =kR6P -END PGP SIGNATURE-
Re: [HEADSUP] ALL Maintainers, please reply.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Vlad on 9/15/2005 6:20 PM: I will be maintaining graphviz once it's uploaded It's not forgotten. If no one else gets there first, it is flagged in my inbox for a review. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKsMH84KuGfSFAYARAn1LAJ9dTe24YU0NghaiNjlZcgjeA8wl5QCgoHla 7VCuzE6uRv0rEfSOzqLw5js= =vJ8i -END PGP SIGNATURE-
setup: how to handle circular dependencies?
Hi Setup maintainers, I need some circular dependencies, i.e. gcc-core requires gcc-core-mingw because -mno-cygwin will not work without the mingw version of the gcc runtime. However, the gcc-core-mingw package only includes the runtime which needs gcc-core to be useful. Now I see that uninstalling these two packages seems to be impossible in one turn because the chooser circles from the installed version through 'reinstall', 'source', 'previous version' to 'uninstall' where the reinstall or previous versions always pulls the dependenciy which was toggled to 'uninstall' and the other way round. I must call setup twice to completely uninstall gcc or to downgrade gcc. Is this handled in the latest setup.exe release? Maybe I should include the mingw gcc runtimes in the main gcc packages? Gerrit -- =^..^=
Re: FW: setup: how to handle circular dependencies?
On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Dave Korn Sent: 16 September 2005 14:23 Oops, sent this to the wrong list. [EMAIL PROTECTED] outlook-auto-address completion! Ditto, though in my case it's reading the message on cygwin@ before the one on [EMAIL PROTECTED] On Fri, 16 Sep 2005, Igor Pechtchanski wrote: On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Gerrit P. Haase Sent: 16 September 2005 14:14 Hi Setup maintainers, I need some circular dependencies, i.e. gcc-core requires gcc-core-mingw because -mno-cygwin will not work without the mingw version of the gcc runtime. However, the gcc-core-mingw package only includes the runtime which needs gcc-core to be useful. Maybe I should include the mingw gcc runtimes in the main gcc packages? I can't see the use in having them separate if gcc-core-mingw is really no use whatsoever on its own. Perhaps someone else can think of a reason? The only use I can see is later on, if setup allows optional dependencies, someone may be able to save disk space by omitting gcc-core-mingw (and other gcc-mingw packages) if they never plan to use -mno-cygwin. At the moment, having a circular dependency is the same as having the two in the same package -- both will be installed (unless the user goes to great pains to unselect one). What I would suggest, however, is placing a stub in the main gcc package that would produce a meaningful error on -mno-cygwin if *-mingw packages aren't present, thus making gcc-core independent of gcc-core-mingw. If gcc-core-mingw is that exact stub, then by all means fold it into gcc-core. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA
RE: lesstif
On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Brian Ford Sent: 15 September 2005 23:20 I am confused, though. The crash you presented to me was one of not being able to start nedit at all: Date: Fri, 01 Jul 2005 17:09:32 -0700 From: Harold L Hunt To: Brian.Ford Subject: Re: lesstif update request Nope, 0.94.4 doesn't work with nedit: --- nedit.exe - Application Error --- The application failed to initialize properly (0xc005). Click on OK to terminate the application. That was the binutils relocs-in-non-writable-.rodata sections problem, wasn't it? Exactly, and I explained that to Harold in this not-yet-quoted private message from the thread in July (heavily snipped to be concise): Date: Tue, 05 Jul 2005 13:11:30 -0700 From: Harold L Hunt To: Brian Ford Subject: Re: lesstif update request On Fri, 1 Jul 2005, Harold L Hunt wrote: The application failed to initialize properly (0xc005). Click on OK to terminate the application. Looks like this could be caused by gcc = 3.3.3 putting const variables containing addresses of imported DLL symbols into .rdata (which then can't be magically relocated at run time since they end up in a read only section) as discussed here: http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html That was a libtool specific example, but I believe the problem is a general one. Yup, that sounds like it describes the problem... and I remember reading that thread a while back, but I guess I didn't catch the connection. [end quoted message] This is exactly why I suspected it was a problem with his binutils or gcc packages being out-of-date. It is also why I am so confused about him saying I need to play around with nedit to make it crash? -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: [HEADSUP] ALL Maintainers, please reply.
Corinna Vinschen wrote: Guys, On Sep 15 19:50, Yaakov S wrote: Harold L Hunt II wrote: Yaakov S wrote: I've already built 2.1.9 in order to run the current GIMP, so if you're not interested in updating this one, please let us know. It's yours. Accepted. I'll have an update out in the next few days. are you aware what you're doing here? How should anyone follow which package belongs to whom if you discuss moving packages around all the time? It's nice that you care but it would be nice for the sake of bookkeeping, if all maintainers who have given away and who have taken over a package at this point, could please send their updated lists of packages again. Hey, chill out, I have six weeks to send in my official list, now don't I? :) I'm going to send a final updated list for myself when my list has settled down a bit. It seems that lesstif, nedit, fontconfig, freetype, and libXft might all be going away, but I need to let all of those get worked out before I update my list. But, thanks for the headsup, because I wasn't thinking about updating the list until you mentioned it :) Harold
Re: lesstif
Hold up... am I not reading something correctly? Was the binutils change that caused the problem ever reverted? If not, the problem will still exist. I never heard that the change was reverted, so I'm wondering why binutils being up to date matters at all. IIRC, with the binutils change in place, the only way to address the issue would be to change nedit to no longer do a relocs in now-non-writable data, which would probably take a week. I seem to recall that I did everything you asked and it had some new problem (which I think was a crash on opening a file, or some such) so I decided to set it aside for a few days and promptly forgot about it. Look, the history doesn't matter. The point here is that I won't let someone release a version of lesstif that breaks nedit... now, if you're sure that nedit works just fine with your new lesstif build, then that's the end of the story, and we can stop trying to resurrect a conversation history. But, I mentioned that I would *like* you to do one more thing, which is to install nedit and lesstif on a machine that has no other modifications from you and just make sure that nedit still works and that you can actually open files; this might take 15 minutes, which is less time then we've spent talking about it. If it works, fine, proceed... if it doesn't work, fine, but proceed with caution and don't post a new 'curr' release of lesstif until you've fixed the problem with nedit. Deal? Harold Brian Ford wrote: On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Brian Ford Sent: 15 September 2005 23:20 I am confused, though. The crash you presented to me was one of not being able to start nedit at all: Date: Fri, 01 Jul 2005 17:09:32 -0700 From: Harold L Hunt To: Brian.Ford Subject: Re: lesstif update request Nope, 0.94.4 doesn't work with nedit: --- nedit.exe - Application Error --- The application failed to initialize properly (0xc005). Click on OK to terminate the application. That was the binutils relocs-in-non-writable-.rodata sections problem, wasn't it? Exactly, and I explained that to Harold in this not-yet-quoted private message from the thread in July (heavily snipped to be concise): Date: Tue, 05 Jul 2005 13:11:30 -0700 From: Harold L Hunt To: Brian Ford Subject: Re: lesstif update request On Fri, 1 Jul 2005, Harold L Hunt wrote: The application failed to initialize properly (0xc005). Click on OK to terminate the application. Looks like this could be caused by gcc = 3.3.3 putting const variables containing addresses of imported DLL symbols into .rdata (which then can't be magically relocated at run time since they end up in a read only section) as discussed here: http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html That was a libtool specific example, but I believe the problem is a general one. Yup, that sounds like it describes the problem... and I remember reading that thread a while back, but I guess I didn't catch the connection. [end quoted message] This is exactly why I suspected it was a problem with his binutils or gcc packages being out-of-date. It is also why I am so confused about him saying I need to play around with nedit to make it crash?
Re: setup: how to handle circular dependencies?
Gerrit P. Haase wrote: I must call setup twice to completely uninstall gcc or to downgrade gcc. Gcc is not the only case. My boss wanted me to clean cygwin off of his computer, so as a lark I tried to use setup to do it. I had to run setup about 50 times, because of all the circular dependencies. Next time, I'll just blow away the tree, clean up the Start Menu, clean out the registry entries, and uninstall the services manually. (*) However, I'm not sure there's a nice way to fix this without breaking some other aspect of the dependency logic. (*) Hmm. This is a pretty complex operation. Maybe we should have an uninstall cygwin completely application? Or at least a FAQ listing these steps? My guess: from a bash window: cygrunsrv -L foreach entry: cygrunsrv -E X; cygrunsrv -R X close window. using setup, uninstall X-start-menu-icons, if installed. ? how to programmatically remove the non-X cygwin start menu stuff ? using Windows Explorer, delete entire cygwin root folder Still have to manually remove cygwin keys in registry -- both HKLM and in HKCU. Icky. -- Chuck
Re: setup: how to handle circular dependencies?
(*) Hmm. This is a pretty complex operation. Maybe we should have an uninstall cygwin completely application? Or at least a FAQ listing these steps? My guess: Isn't there already one? http://cygwin.com/faq/faq.setup.html#faq.setup.uninstall-all from a bash window: cygrunsrv -L foreach entry: cygrunsrv -E X; cygrunsrv -R X or in more readable, executable syntax: for serv in `cygrunsrv --list` inetd ; do cygrunsrv --stop $serv cygrunsrv --remove $serv done By the way, I've always been a bit annoyed that inetd is not like all other cygwin services, so that it doesn't show in cygrunsrv's list. [Nasty - cygrunsrv --help prints to stderr and fails with exit status 1 - that should be fixed.] close window. using setup, uninstall X-start-menu-icons, if installed. ? how to programmatically remove the non-X cygwin start menu stuff ? singular also installs start menu icons, these days. using Windows Explorer, delete entire cygwin root folder Still have to manually remove cygwin keys in registry -- both HKLM and in HKCU. Icky. -- Chuck -- Eric Blake
Re: lesstif
On Fri, 16 Sep 2005, Harold L Hunt II wrote: Hold up... am I not reading something correctly? Was the binutils change that caused the problem ever reverted? IIRC, it was a gcc change that caused the problem. Although, there may have been a binutils work around. If not, the problem will still exist. It may, but... I never heard that the change was reverted, I don't think it was, but... so I'm wondering why binutils being up to date matters at all. See speculation about binutils work around above. Did you try updating? But... IIRC, with the binutils change in place, gcc change the only way to address the issue would be to change nedit to no longer do relocs in now-non-writable data, which would probably take a week. Here may be where the misunderstanding lies. That statement may be true, but it doesn't matter because it would only come into play if/when nedit was updated (ie. recompiled with gcc = 3.3.1). This is not necessary because of, or to use the new lesstif. This is what I tested, but may not be what you tested. Hence our differing results. I seem to recall that I did everything you asked and it had some new problem (which I think was a crash on opening a file, or some such) Unfortunately, as I stated before, you never reported this to me, so I am unable to reproduce or debug it. Look, the history doesn't matter. I'm not really trying to reproduce history, just to clarify enough to move forward since our recollections seem to differ greatly. The point here is that I won't let someone release a version of lesstif that breaks nedit... Fine, please define how to break nedit and I'll make sure it doesn't happen. Until we have a confirmed bug that is reproducible, you can't expect me to go beyond a simple does nedit work to open, edit, and save files type of test can you? now, if you're sure that nedit works just fine with your new lesstif build, No one really can be, but it basically does... then that's the end of the story, and we can stop trying to resurrect a conversation history. But, I mentioned that I would *like* you to do one more thing, which is to install nedit and lesstif on a machine that has no other modifications from you I don't understand what this means. Could you clarify what no other modifications from me means? I have made no modifications to the released nedit or to your lesstif-0.94.4 source package. They just work (TM). and just make sure that nedit still works and that you can actually open files; this might take 15 minutes, which is less time then we've spent talking about it. Until I know what you mean by the above, I can't say I have done it. But, IWJFFM. If it works, fine, proceed... I had planned to. I have maybe just found web space to post packages, but there is a fairly small 5M-10M limit. We'll see if lesstif fits... If anyone knows of a free site suitable for such, please let me know (via private email if you so desire). I don't remember anyone posting one that didn't have significant issues with package names, space, etc. if it doesn't work, fine, but proceed with caution and don't post a new 'curr' release of lesstif until you've fixed the problem with nedit. As soon as someone can identify a problem with nedit... Deal? Agreed. I'll be glad to leave my new version in test for a month or so to see if anything turns up. But, given the standard Cygwin philosophy for testing, I expect nothing will until it goes curr ;-). -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot...
Re: setup: how to handle circular dependencies?
Eric Blake wrote: (*) Hmm. This is a pretty complex operation. Maybe we should have an uninstall cygwin completely application? Or at least a FAQ listing these steps? My guess: Isn't there already one? http://cygwin.com/faq/faq.setup.html#faq.setup.uninstall-all Doh! I actually searched the faq for one before I posted, but I searched the first page (which has only the first 7 entries), not the One Big HTML File version. Again: Doh! -- Chuck
Re: [HEADSUP] ALL Maintainers, please reply.
Corinna Vinschen wrote: please reply to this mail within the next six weeks, including a list of ALL packages you maintain. gsl gnugo cgoban fltk Teun
Re: [HEADSUP] ALL Maintainers, please reply.
Corinna Vinschen writes: packages will be up for grabs. Which means, they will disappear from the Cygwin net distribution if nobody wants to take over maintainership. I'm maintaining guile tetex And will [have to] take over lilypond again if no-one else takes it. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [not GTG] Re: ITP: bogofilter -- Statistical Bayesian spam filter
Eric Blake ebb9-PGZyUNKar/[EMAIL PROTECTED] writes: Thanks for having the time to review, | | sdesc: bogofilter - Statistical Bayesian spam filter. | | ldesc: Bogofilter is a Bayesian spam filter that classifies mail as | | setup.hint's sdesc: is redundant (don't list your | package name as the first word, or setup.exe will show bogofilter: | bogofilter - Statistical Bayesian spam filter.) Also, I think the common | practice is for sdesc to not end in '.' Fixed. | Binary package: | | etc/postinstall/bogofilter.sh: | -typo s/CYGIN/CYGWIN/ | -Install() used a wildcard to find the file, which is not safe - spell out | the full directory name. Fixed | -Install() only creates /etc/bogofilter.cf once, but if the user does not | touch this file, then when they upgrade bogofilter, they should get the | latest and greated bogofilter.cf instead of being stuck with the one from | their first download. This is a problem that I have no solution. Can you share your thoughts how this could be done intelligently? The problem I see is: If /etc/xxx.conf is already there, there is no way knowing if this has remained the same or if user has made changes to it. The new Cygwin does not have conflict resolution of /etc/ file like seen in Debian, so it is more safer to just let user to check under /usr/share/doc/package for new features. | usr/share/doc/Cygwin/bogofilter-0.96.1.README: | -readme mentions bogofilter-0.92.4-1 internally - make this consistent | -file listing in the readme omits the scripts in /usr/bin | -typo s/licence/license/. However, I like the idea of adding License: and | Language: sections to the generic package template. Fixed. | -the generic template mentions that the upstream docs are available in | /usr/share/doc/package-ver/ This can be seen from the Files included in the binary distro:' listing. | Source package: | -why is the binary package included inside the source package? Fixed. | -'bogofilter*.sh all' failed with: | libbogofilter.a(lexer.o): In function `text_decode': | /tmp/bogofilter/bogofilter-0.96.1/.build/build/src/lexer.c:480: undefined | reference to `_iconv_close' | ... | Did something go wrong in detecting -liconv? Which also means your | setup.hint should probably depend on libiconv2. Added, thanks. I've rolled up new archive. Jari A) Use this: wget --non-verbose\ http://cygwin.cante.net/bogofilter/setup.hint \ http://cygwin.cante.net/bogofilter/bogofilter-0.96.1-1.tar.bz2.sig \ http://cygwin.cante.net/bogofilter/bogofilter-0.96.1-1.tar.bz2 \ http://cygwin.cante.net/bogofilter/bogofilter-0.96.1-1-src.tar.bz2.sig \ http://cygwin.cante.net/bogofilter/bogofilter-0.96.1-1-src.tar.bz2 B) or use this gpg --keyserver wwwkeys.pgp.net --recv-keys 955A92D8 mkdir bogofilter ; cd bogofilter rm -f get.sh get.sh.sig wget -q http://cygwin.cante.net/bogofilter/get.sh \ http://cygwin.cante.net/bogofilter/get.sh.sig gpg --verify get.sh.sig get.sh sh get.sh
Re: [HEADSUP] ALL Maintainers, please reply.
On 9/15/05, Corinna Vinschen wrote: including a list of ALL packages you maintain. cygwin-doc pinfo (apparently dead upstream)
Re: [HEADSUP] ALL Maintainers, please reply.
I maintain packages boost-devel-1.33.0-1 and boost-1.33.0-1. VH
Re: libungif [Was: Re: [HEADSUP] ALL Maintainers, please reply.]
Gerrit P. Haase wrote: libungif is (at least) in use by: WindowMaker emacs-X11 imlib Most packages can build against either giflib or libungif, and IIRC imlib is one of them (requires a rebuild on my part). Since both packages install the same utilities and gif_lib.h header, the maintainer(s) should release a new libungif package without the utilities and header (so that, at a minimum, the dll will still be available to prevent breakage of existing packages) together with the new giflib package. Yaakov
Re: How about script? [was: Re: Command 'more': missing dll cygpcre.dll [Attn more maintainer]]
Gerrit P. Haase wrote: script does not build out of the box. I ported another similar tool, I believe Reini has done something similar. Unfortunately I cannot find the announcement / bookmark / package name / patch. As have I: ftp://sunsite.dk/projects/cygwinports/release/script/ Yaakov
Please upload: freetype2
Harold has given me maintainership of freetype2. Please upload: ftp://sunsite.dk/projects/cygwinports/release/freetype2/freetype2-2.1.9-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/freetype2-2.1.9-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/setup.hint ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype2-devel/libfreetype2-devel-2.1.9-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype2-devel/setup.hint ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype26/libfreetype26-2.1.9-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype26/setup.hint Thanks! Yaakov
Re: Please upload: freetype2
On Sep 16 16:37, Yaakov S wrote: Harold has given me maintainership of freetype2. Please upload: ftp://sunsite.dk/projects/cygwinports/release/freetype2/freetype2-2.1.9-1-src.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/freetype2-2.1.9-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/setup.hint ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype2-devel/libfreetype2-devel-2.1.9-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype2-devel/setup.hint ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype26/libfreetype26-2.1.9-1.tar.bz2 ftp://sunsite.dk/projects/cygwinports/release/freetype2/libfreetype26/setup.hint Uploaded. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc.
base-files: Does not permit the use of symlinks in /etc/profile.d/
The current /etc/profile does not permit the use of symlinks in /etc/profile.d/ - it ignores them. Unfortunately, even if this was fixed in the package, existing installs wouldn't get fixed, because /etc/profile is handled via /etc/defaults :-( /me gives up on finding a way for /sbin/alternatives to influence $MANPATH. Max.
Re: [not GTG] Re: ITP: bogofilter -- Statistical Bayesian spam filter
| -Install() only creates /etc/bogofilter.cf once, but if the user does not | touch this file, then when they upgrade bogofilter, they should get the | latest and greated bogofilter.cf instead of being stuck with the one from | their first download. This is a problem that I have no solution. Can you share your thoughts how this could be done intelligently? The problem I see is: If /etc/xxx.conf is already there, there is no way knowing if this has remained the same or if user has made changes to it. The new Cygwin does not have conflict resolution of /etc/ file like seen in Debian, so it is more safer to just let user to check under /usr/share/doc/package for new features. This really ought to be documented better on the packaging instructions page. The trick is to use a preremove script (see how base-files does it, for example). A file named /etc/preremove/bogofilter.sh will be called just before the package is uninstalled (setup.exe uninstalls the old version before installing the upgraded version), so in that script, if /etc/xxx.conf exists and is identical to /usr/share/doc/xxx.template, just delete it. But if it differs at all, leave it alone. Also, it is a good idea to have a file /etc/preremove/bogofilter-manifest.lst, which lists every file that was created by the postinstall script, and which will be removed on preremove if untouched by the user. Someday, 'cygcheck -c' might parse the manifest lists to help diagnose if postinstalls have not completed. I've rolled up new archive. I'll let you get the preremove script in first, before checking out the new package. Thanks for putting up with my nit-picking :) -- Eric Blake
Re: Emacs problem after rebaseall: some progresses?
Angelo Graziosi [EMAIL PROTECTED] writes: As you can see in the mailing lists, I have posted this question a few times. Now I have discovered somethings at which you can give a more adeguate answer. The problem is that after rebaseall Emacs does not works, it takes all the CPU and its window does not appear so that one can only kill its process. After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Rebasing all and then reinstalling a package that has just rebased : is it a valid procedure? Or should one expect that some other application does not work any more? Actually, I don't have an idea if this is a valid procedure. And to be honest, at this moment I don't even care. But today I ran into the same problem - and your trick just works for me, too. Many many thanks for posting this workaround. I guess it took you some hours to detect libncurses7 as a key component, but you certainly saved me the pain to try to re-install all cygwin. -- Cheers, haj -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Angelo Graziosi wrote: After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Rebasing all and then reinstalling a package that has just rebased : is it a valid procedure? Sure, this is fine. But what you're really saying is that one of the dlls in libncurses7 used by xemacs /usr/bin/cygform7.dll /usr/bin/cygmenu7.dll /usr/bin/cygncurses7.dll /usr/bin/cygpanel7.dll is not rebase-able. I'm not clear on the history; there was a time when a number of DLLs were considered not rebase-able but I don't remember why, or whether the issue was ever fixed (in rebase.exe, or in the DLLs themselves). *I* wonder, if xemacs were rebuilt against the CURRENT ncurses libraries (libncurses8), would it still have similar problems -- e.g. would you need to rebaseall and then reinstall libncursesEIGHT? If so, it's a problem I need to track down, as the ncurses maintainer. If not, then the XEmacs maintainer should simply release a new version, recompiled against the new ncurses. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
On Fri, 16 Sep 2005, Harald Joerg wrote: Angelo Graziosi [EMAIL PROTECTED] writes: The problem is that after rebaseall Emacs does not works, it takes all the CPU and its window does not appear so that one can only kill its process. After the new release of rebase-2.4-1, the problem remains BUT this time reinstalling, with setup, ONLY the package libncurses7 (whose current release is 5.3-4), EMACS works again! Actually, I don't have an idea if this is a valid procedure. And to be honest, at this moment I don't even care. But today I ran into the same problem - and your trick just works for me, too. Many many thanks for posting this workaround. I guess it took you some hours to detect libncurses7 as a key component, but you certainly saved me the pain to try to re-install all cygwin. Even using the snapshots, the problem remains and every time one needs to rebase all one must reinstall libncurses7-5.3-4 if one wants Emacs to work. In any case I am on the alert to see what cause that. Best regards, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
On Fri, Sep 16, 2005 at 07:26:26PM +0200, Angelo Graziosi wrote: Even using the snapshots, the problem remains and every time one needs to rebase all one must reinstall libncurses7-5.3-4 if one wants Emacs to work. Since this has nothing to do with Cygwin, AFAICT, there is no reason to think that a snapshot would fix the problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Page Up and Page Down
Hi. I have what appears to be a plain US 104-key keyboard manufactured by/for Compaq. Using xterm, when I press the Pg Up key on the number keypad, I get the character sequence ^[[5~ and I get ^[[6~ for Pg Dn (^[ is actually a single character, escape). However, the Page Up and Page Down keys in that middle section between the number pad and main keyboard area produce different sequences, ^[Or and ^[Ou respectively. On my Linux box at home, I believe xterm always produces ^[[5~ and ^[[6~ I also use PuTTYcyg [http://gecko.gc.maricopa.edu/~medgar/puttycyg/] to use the Cygwin command line (since the Windows Command Prompt window royally sucks). It produces ^[[5~ and ^[[6~ for everything. (By the way, if you're at a command prompt, you can see what the shell is seeing by typing ^V prior to pressig the key.) Anyway, I've looked through the app-defaults for xterm, and haven't found anything obvious, so this must be hidden somewhere else. I'm not aware of anything I might have changed to cause this to happen. It is problematic, since vim expects the sequence produced by the keypad buttons, rather than the ones produced by the middle keys. TERM is set to 'xterm' in both xterm and PuTTYcyg. -- [ Michael Hicks | [EMAIL PROTECTED] ] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
My attempt to use Cygwin seems doomed to failure in spite of...
... all the willing help I've received - esp from Reid. I do appreciate you all taking the time to give me info and clues etc. My conclusion is there is something on my system that prevents Xwin.exe and / or xterm.exe from completely initialising. I've removed most of the original text of this apend, as while I was closing down my stuff, I spotted something! From FAQ 7.6. Why does Cygwin/X freeze right after startup? Zone Alarm 5 is known to break Cygwin/X. As a result you'll see this line (or a similar) as last output in /tmp/XWin.log Rules = xorg Model = pc101 Layout = us Variant = (null) Options = (null) Disabling Zone Alarm will not solve this problem. You can only uninstall Zone Alarm 5 and switch to an earlier version (4.5 is known to work) or use a different personal firewall. I found this, but it is NOT in the xwin.log. By chance this time, I had started xwin.exe in a cmd prompt and I could see the stdout messages. These are pretty much what's in the log, except for the last line! == Rules = xorg Model = pc105 Layout = gb Variant = (null) Options = (null) So, I guess that's it - it's ZA, bless it. I can't not use it, so I guess I can't use Cygwin. Shame, I was getting quite fond of it. As a long shot, I'll see if I can find the ZA forum and ask / search. BTW, I discovered what is making cygwin run slowly - it is vsmon.exe that runs when ZoneAlarm anti-virus checking is on (it usually is) - as soon as any X-component starts the cpu consumption for vsmon rockets. Thanks again everyone --- John Ormerod erebor limited -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Page Up and Page Down
On Fri, 16 Sep 2005, Mike Hicks wrote: Hi. I have what appears to be a plain US 104-key keyboard manufactured by/for Compaq. Using xterm, when I press the Pg Up key on the number keypad, I get the character sequence ^[[5~ and I get ^[[6~ for Pg Dn (^[ is actually a single character, escape). However, the Page Up and Page Down keys in that middle section between the number pad and main keyboard area produce different sequences, ^[Or and ^[Ou respectively. On my Linux box at home, I believe xterm always produces ^[[5~ and ^[[6~ It sounds like your Linux system is running Redhat. I get lots of complaints about that (for instance earlier today ;-). For quite a while (I'm told it was corrected in Fedora) their package for xterm alters most of the key translations, lobotomizing it to look like someone's improvement to old xterm. A quick check on my system shows it producing \EOH and \EOF (though the correct answer depends on the resource settings of course). I also use PuTTYcyg [http://gecko.gc.maricopa.edu/~medgar/puttycyg/] to use the Cygwin command line (since the Windows Command Prompt window royally sucks). It produces ^[[5~ and ^[[6~ for everything. ;-) (By the way, if you're at a command prompt, you can see what the shell is seeing by typing ^V prior to pressig the key.) Anyway, I've looked through the app-defaults for xterm, and haven't found anything obvious, so this must be hidden somewhere else. I'm not aware of anything I might have changed to cause this to happen. It is problematic, since vim expects the sequence produced by the keypad buttons, rather than the ones produced by the middle keys. TERM is set to 'xterm' in both xterm and PuTTYcyg. Actually vim can use the termcap/terminfo settings (though I understand it has a built-in copy of one of the flavors for xterm). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: Page Up and Page Down
On Fri, 16 Sep 2005, Reid Thompson wrote: if nothing else, remap the sequences in your .[g]vimrc file(s). that's a backwards solution (but as a last resort ;-) Also, use setup to download rxvt and see if that provides you a better 'terminal' no - just to refresh my memory I ran it just now and see it does something comparable (different strings for the editing keypad, still not what he's expecting). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Charles Wilson wrote: *I* wonder, if xemacs were rebuilt against the CURRENT ncurses libraries (libncurses8), would it still have similar problems -- e.g. would you need to rebaseall and then reinstall libncursesEIGHT? If so, it's a problem I need to track down, as the ncurses maintainer. If not, then the XEmacs maintainer should simply release a new version, recompiled against the new ncurses. Charles, as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after rebasing all the system. The problem. There are applications that need rebasing (... unable to remap...). But after rebasing all, Emacs does not show its window and take almost 100% of CPU (one can only kill it). If one reinstall libncurses7-5.3-4, Emacs works again as it should. For what I know, Emacs is the only X application that has this problem. Cheers, angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Angelo Graziosi wrote: as the title of this mail says, it is Emacs (21.2-13, 21.3.50-2, started from X), NOT XEmacs (21.4.17-1, 21.5.16-1), that has problems after rebasing all the system. Fine, Emacs, XEmacs, whatever. That's not the point The problem. There are applications that need rebasing (... unable to remap...). But after rebasing all, Emacs does not show its window and take almost 100% of CPU (one can only kill it). If one reinstall libncurses7-5.3-4, Emacs works again as it should. For what I know, Emacs is the only X application that has this problem. And, is it the only X application that links against an obsolete version of the ncurses library? e.g. is it simply that cygncurses-7.dll cannot be rebased without causing troubles for client apps -- and cygncurses-8.dll, used by all other X apps, is fine? The *E*macs maintainer should relink/rebuild *E*macs against cygncurses-8.dll, rebase, and see if the problem (e.g. the necessity of undoing the rebase of cygncurses-8.dll by reinstalling that package) remains. If the new *E*macs works with a rebased cygncurses-8.dll, then the problem is solved: cygncurses-7.dll is broken, and if it weren't obsolete it should be fixed. But, since it IS obsolete... Now, if the *E*macs maintainer does all this and the problem remains -- after rebasing, *E*macs is broken unless cygncurses-8.dll is reinstalled -- THEN we'll have something to talk about. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Emacs problem after rebaseall: some progresses?
Christopher Faylor wrote: Angelo Graziosi wrote: Even using the snapshots, the problem remains and every time one needs to rebase all one must reinstall libncurses7-5.3-4 if one wants Emacs to work. Since this has nothing to do with Cygwin, AFAICT, there is no reason to think that a snapshot would fix the problem. I do not doubt that it is so. The first time I observed these problems with Emacs was when Cygwin-1.5-17-1 was released: reinstalling 1.5.16-1 all worked fine and I thinked that some snaps solved the problem. Successively I found that reinstalling libncurses7, effectively, solve the problem. But the habit to test snapshots remains! Charles Wilson wrote: And, is it the only X application that links against an obsolete version of the ncurses library? e.g. is it simply that cygncurses-7.dll cannot be rebased without causing troubles for client apps -- and cygncurses-8.dll, used by all other X apps, is fine? I cannot answer to these questions. I can only confirm that for what I know only Emacs has these problems. Best regards, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog environ.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-09-16 14:52:33 Modified files: cygwin : ChangeLog environ.cc Log message: * environ.cc (environ_init): Issue an error if GetEnvironmentStrings fails and return. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3090r2=1.3091 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?cvsroot=uberbaumr1=1.124r2=1.125
winsup/cygwin ChangeLog environ.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-09-16 15:56:07 Modified files: cygwin : ChangeLog environ.cc Log message: * environ.cc (environ_init): Protect with a 'myfault' in case GetEnvironmentStrings misbehaves. * environ.cc (environ_init): Add debugging output with value returned from GetEnvironmentStrings. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3091r2=1.3092 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?cvsroot=uberbaumr1=1.125r2=1.126
winsup/cygwin ChangeLog environ.cc spawn.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-09-16 19:58:13 Modified files: cygwin : ChangeLog environ.cc spawn.cc Log message: * environ.cc (build_env): Clear envblock and return NULL on attempt to use env var 32K. * spawn.cc (spawn_guts): Set E2BIG if build_env detects an error. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3092r2=1.3093 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?cvsroot=uberbaumr1=1.126r2=1.127 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/spawn.cc.diff?cvsroot=uberbaumr1=1.190r2=1.191
winsup/cygwin ChangeLog environ.cc spawn.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-09-16 20:12:14 Modified files: cygwin : ChangeLog environ.cc spawn.cc Log message: * environ.cc (build_env): Use kilobytes not megabytes. Return immediately on error. * spawn.cc (spawn_guts): Set return value to -1 on error from build_env. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.3093r2=1.3094 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/environ.cc.diff?cvsroot=uberbaumr1=1.127r2=1.128 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/spawn.cc.diff?cvsroot=uberbaumr1=1.191r2=1.192
Re: cygwin forgets CTRL key press
Luke Kendall wrote: Has anyone else noted that in vi (either in a plain Cygwin window or in an rxvt window, in an X session or not, also in xterm), that if you hold down the CTRL key and press keys at intervals (like F to page down through a file), and wait four seconds before another key press it's as if you don't have CTRL pressed at all? You have to release it and press afresh. The same applies to more: hold CTRL down and press f, and it beeps at you to indicate that's invalid; still hold CTRL down, wait 4 seconds, then press f again, and it pages forward. FWIW, I just checked on my system (Windows 2003 Server, sticky-keys off), and can't reproduce it, even using times far longer than 4 seconds. (I also can't reproduce Igor's claim that Windows will offer to turn on sticky-keys if I hold down a modifier key too long.) Have you confirmed that this is only happening with Cygwin, and not with things like Notepad? - Brooks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin forgets CTRL key press
Original Message From: Brooks Moses Sent: 16 September 2005 08:05 seconds. (I also can't reproduce Igor's claim that Windows will offer to turn on sticky-keys if I hold down a modifier key too long.) Check control panel/accessibility options; you may have turned it off at some point in the past. (I always do; I often pause to think with my finger on a shift key, and I just hate having stuff pop up like that). cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE : eval function not working anymore !?
Thank you for your answers.
The following sentences do not work:
MODULES=\$${domain}_MODULES
The following sentences work fine:
eval MODULES=\$${domain}_MODULES
eval MODULES=\$${domain}_MODULES
eval MODULES='$'${domain}_MODULES
Regards,
Yann DUBOST
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: A couple Issues with cygwin1-20050915.dll
On Sep 15 16:02, James R. Phillips wrote: Testing the latest 20050915 snapshot, saw a couple issues: 1) Max length of command line inside a makefile seems to have shortened, to around 250 characters max. This is based on a clean command that has a make macro that expands to a relatively long list of files. When the resulting command line exceeds something around 250 characters, make returns error 3. Does not happen with 1.5.18. 2) cygcheck itself prints an error message like this: $ cygcheck 6 [main] ? 2756 fork_copy: cygheap pass 0 failed, 0x6115A920..0x6115E624, done 0, windows pid 3892, Win32 error 5 Usage: cygcheck [OPTIONS] [PROGRAM...] I can't reproduce these observations with current Cygwin from CVS so I assume cgf has fixed that already. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash login breaks if too many environment variables are set
Thanks for the replies so far. Unfortunately is the best option (set variables in bash) not feasable. The .bat file is a complex set of bat files with logic inside so that would take a lot of effort to convert But I have done some experiments with bash without --login option and the advised export -p. The number of variables itself does not seem to be the problem. The length of the values is also important. So to get an idea what is going on I have incremented the number of variables up to the point where export -p still gives the right output. Now I add 1 character at a time to a value and tested export - p. Only the built-in commands work now. All others end with Resource temporarily unavailable There comes a point where adding 1 more character ends up with: 138 [main] bash 2556 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 887 [main] bash 2556 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump The stackdump contains Exception: STATUS_ACCESS_VIOLATION at eip=61014DEE eax=00246000 ebx=10012910 ecx=0003 edx=00245FFF esi= edi=6110A1C4 ebp=0022EEE8 esp=0022EE90 program=c:\cygwin\bin\bash.exe, pid 2556, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022EEE8 61014DEE (, , 0022EF18, 61087B02) 0022EF18 61068028 (, , 7C90EE18, 7C919AF0) 0022EFD8 61004B16 (0022EFF0, 77D70467, 77D49A18, ) 0022FF88 6100594F (, , , ) End of stack trace Adding another character gives no errors but export -p shows now only: declare -x HOME=/cygdrive/c/cygwin/home/fhommexx declare -x OLDPWD declare -x PWD=/cygdrive/c/Data/locations/tc50_custy00 declare -x SHLVL=1 declare -x TERM=cygwin Adding still more characters reveals more variables. The last export -p that gave correct results was piped to a file. I tried to find if the limit was the 32k limit as suggested by Eric. The rough size of the file is 45,098 bytes. Stripping 'declare -x cuts it down to 37,816 bytes Stripping leading and trailing cuts it down to 36,494 bytes Modifying \\ into \ cuts it down to 33.065 bytes The file contains 662 lines and if we also cut the linefeed (no idea how the administration works) There are only 32403 bytes left. And 32 k = 32.768. Pretty near but no exact match. Now I am stuck. Did I reach a limit of windoze, a limit in cygwin or a supporting library or a bug? -Original Message- Hommersom, Fred wrote: The file bigsetup.bat contains a huge amount environment variables. For a medium number (~ 600) everything works fine For a larger number the output is: bash: /usr/bin/id: Resource temporarily unavailable ... i would think that you should declare your env variables in either your .bashrc or your .bash_profile rather than in a .bat file. It may solve your problem. I haven't had a chance to look at this further, but it is on my list. I tried looking in the Windows documentation to see if there is a limit on environment size for CreateProcess that you might be exceeding - all I can find is that an individual variable can be no more than 32k, but nothing about the overall environment size. Does anyone else know what limits windows imposes on the environment? POSIX only specifies ARG_MAX, which is the combination of command line and environment together. You might also want to experiment with 'export -p' in a bash where you are experiencing failures, to see if bash's list of environment variables is shorter than what you thought should have been inherited into bash. Being a builtin, it won't have then invocation problems like you are having with id, find, or sort. I also agree with Reid's suggestion - try sticking things into the environment AFTER bash is started, not beforehand. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Sep 16 11:08, Hommersom, Fred wrote: Thanks for the replies so far. Unfortunately is the best option (set variables in bash) not feasable. The .bat file is a complex set of bat files with logic inside so that would take a lot of effort to convert But I have done some experiments with bash without --login option and the advised export -p. The number of variables itself does not seem to be the problem. The length of the values is also important. So to get an idea what is going on I have incremented the number of variables up to the point where export -p still gives the right output. Now I add 1 character at a time to a value and tested export - p. Only the built-in commands work now. All others end with Resource temporarily unavailable There comes a point where adding 1 more character ends up with: 138 [main] bash 2556 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 887 [main] bash 2556 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump The stackdump contains Exception: STATUS_ACCESS_VIOLATION at eip=61014DEE eax=00246000 ebx=10012910 ecx=0003 edx=00245FFF esi= edi=6110A1C4 ebp=0022EEE8 esp=0022EE90 program=c:\cygwin\bin\bash.exe, pid 2556, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022EEE8 61014DEE (, , 0022EF18, 61087B02) 0022EF18 61068028 (, , 7C90EE18, 7C919AF0) 0022EFD8 61004B16 (0022EFF0, 77D70467, 77D49A18, ) 0022FF88 6100594F (, , , ) End of stack trace The stackdump isn't very useful unless there's debug information available, which isn't for 1.5.18. Would you mind to try the same with the latest snapshot DLL, http://cygwin.com/snapshots/cygwin1-20050916.dll.bz2 and report back if either the problem is solved or if not, send the resulting strace? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bug in gcc and/or binutils?
* Charles Wilson wrote on Friday, September 16, 2005 05:28 CEST: FWIW, this is not a recent regression --- nothing changed in binutils or gcc. I just installed binutils-20040725-2 from the Cygwin Time Machine and got identical output. Oh, I can see how you think I thought it was a regression. But I didn't, I was having the same trouble before upgrading the install and only upgraded to check if the behaviour had changed. Sorry for the confusion... This was a surprise to me: *I* thought that we no longer needed the DATA flag in .def files because binutils was smart enough to figure that out on its own -- obviously, it does so when auto-EXporting, so why can't it do so when using a .def file? Using .def files turns off the auto-EXport logic (which it should, because if you specify a specific set of exports you don't want binutils adding a few more on its own). However, this turn off the auto-EXport logic seems to include turning off the is this symbol a DATA item or a function logic. I never knew that. So, given my mistaken understanding, I wanted to know if this was a recent regression in binutils. But, it's always been like that -- it is not a regression at all. The question is, should binutils be fixed to keep the is this symbol a DATA item or a function logic active even when using .def files? I'm not sure the answer is yes. Wouldn't this imply giving binutils override power, if I marked a *function* symbol with 'DATA' in the .def file -- the converse of the case described by Gerritt? Basically, we'd be making binutils IGNORE any 'DATA' (or lack thereof) decoration in the .def file, and just do what it thinks is best. This doesn't seem to be the path of wisdom, to me. If I'm using a .def file, it's likely because in the specific situation I don't trust binutils to do what it thinks is best; if I did, I'd let the auto-EXport logic do its thing. So, to me it looks more and more that libtool ought to be more careful when creating its .def file... Which is the long-winded way of saying that I agree with Gerrit. Yes, I also agree. I too can see the value of not overriding the explicit input given by the user. Thanks everyone for clarifying things. So, libtool needs a fix... Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash login breaks if too many environment variables are set
The problem can be reproduced with cygwin1-20050916.dll The output of strace in the case of a stackdump is below. ** Program name: c:\cygwin\bin\bash.exe (pid 2692, ppid 1) App version: 1005.18, api: 0.132 DLL version: 1005.19, api: 0.138 DLL build:20050916 00:00:39SNP OS version: Windows NT-5.1 Heap size:1073741824 Date/Time:2005-09-16 12:38:36 ** 26 275 [main] bash 2692 set_myself: myself-dwProcessId 2692 24 299 [main] bash 2692 time: 1126867116 = time (0) 440 739 [main] bash 2692 environ_init: 0x10010238: X$ 37 776 [main] bash 2692 environ_init: 0x10010248: ðH$ 102 878 [main] bash 2692 handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610D6971 sp 0x22EE64 25 903 [main] bash 2692 handle_exceptions: In cygwin_except_handler sig 11 at 0x610D6971 21 924 [main] bash 2692 handle_exceptions: In cygwin_except_handler calling 0x0 20 944 [main] bash 2692 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 3021246 [main] bash 2692 try_to_debug: debugger_command '' 6821928 [main] bash 2692 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 1760359 1762287 [main] bash 2692 signal_exit: about to call do_exit (8B) 66 1762353 [main] bash 2692 do_exit: do_exit (139), exit_state 0 57 1762410 [main] bash 2692 void: 0x0 = signal (20, 0x1) 48 1762458 [main] bash 2692 void: 0x0 = signal (1, 0x1) 45 1762503 [main] bash 2692 void: 0x0 = signal (2, 0x1) 45 1762548 [main] bash 2692 void: 0x0 = signal (3, 0x1) 66 1762614 [main] bash 2692 sigproc_terminate: entering 49 1762663 [main] bash 2692 sig_send: my_sendsig 0x0, myself-sendsig 0x0, exit_state 9 47 1762710 [main] bash 2692 __set_errno: int sig_send(_pinfo*, siginfo_t, _cygtls*):548 val 11 48 1762758 [main] bash 2692 sig_send: returning 0x1 from sending signal -42 46 1762804 [main] bash 2692 proc_terminate: nprocs 0 44 1762848 [main] bash 2692 proc_terminate: leaving 84 1762932 [main] bash 2692 sigproc_terminate: already performed 49 1762981 [main] bash 2692 __to_clock_t: dwHighDateTime 0, dwLowDateTime 100144 47 1763028 [main] bash 2692 __to_clock_t: total 000A 46 1763074 [main] bash 2692 __to_clock_t: dwHighDateTime 0, dwLowDateTime 200288 47 1763121 [main] bash 2692 __to_clock_t: total 0014 933 1764054 [main] bash 2692 pinfo::maybe_set_exit_code_from_windows: pid 2692, exit value - old 0x88B, windows 0xDEADBEEF, cygwin 0x88B 145 1764199 [main] bash 2692 pinfo::exit: Calling ExitThread hProcess 0x0, n 0x8B, exitcode 0x0 -Original Message- On Sep 16 11:08, Hommersom, Fred wrote: Thanks for the replies so far. Unfortunately is the best option (set variables in bash) not feasable. The .bat file is a complex set of bat files with logic inside so that would take a lot of effort to convert But I have done some experiments with bash without --login option and the advised export -p. The number of variables itself does not seem to be the problem. The length of the values is also important. So to get an idea what is going on I have incremented the number of variables up to the point where export -p still gives the right output. Now I add 1 character at a time to a value and tested export - p. Only the built-in commands work now. All others end with Resource temporarily unavailable There comes a point where adding 1 more character ends up with: 138 [main] bash 2556 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 887 [main] bash 2556 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump The stackdump contains Exception: STATUS_ACCESS_VIOLATION at eip=61014DEE eax=00246000 ebx=10012910 ecx=0003 edx=00245FFF esi= edi=6110A1C4 ebp=0022EEE8 esp=0022EE90 program=c:\cygwin\bin\bash.exe, pid 2556, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022EEE8 61014DEE (, , 0022EF18, 61087B02) 0022EF18 61068028 (, , 7C90EE18, 7C919AF0) 0022EFD8 61004B16 (0022EFF0, 77D70467, 77D49A18, ) 0022FF88 6100594F (, , , ) End of stack trace The stackdump isn't very useful unless there's debug information available, which isn't for 1.5.18. Would you mind to try the same with the latest snapshot DLL, http://cygwin.com/snapshots/cygwin1-20050916.dll.bz2 and report back if either the problem is solved or if not, send the resulting strace? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Sep 16 12:51, Hommersom, Fred wrote: The problem can be reproduced with cygwin1-20050916.dll The output of strace in the case of a stackdump is below. ** Program name: c:\cygwin\bin\bash.exe (pid 2692, ppid 1) App version: 1005.18, api: 0.132 DLL version: 1005.19, api: 0.138 DLL build:20050916 00:00:39SNP OS version: Windows NT-5.1 Heap size:1073741824 Date/Time:2005-09-16 12:38:36 ** 26 275 [main] bash 2692 set_myself: myself-dwProcessId 2692 24 299 [main] bash 2692 time: 1126867116 = time (0) 440 739 [main] bash 2692 environ_init: 0x10010238: X$ 37 776 [main] bash 2692 environ_init: 0x10010248: ðH$ 102 878 [main] bash 2692 handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610D6971 sp 0x22EE64 25 903 [main] bash 2692 handle_exceptions: In cygwin_except_handler sig 11 at 0x610D6971 21 924 [main] bash 2692 handle_exceptions: In cygwin_except_handler calling 0x0 20 944 [main] bash 2692 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 3021246 [main] bash 2692 try_to_debug: debugger_command '' 6821928 [main] bash 2692 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 1760359 1762287 [main] bash 2692 signal_exit: about to call do_exit (8B) 66 1762353 [main] bash 2692 do_exit: do_exit (139), exit_state 0 57 1762410 [main] bash 2692 void: 0x0 = signal (20, 0x1) 48 1762458 [main] bash 2692 void: 0x0 = signal (1, 0x1) 45 1762503 [main] bash 2692 void: 0x0 = signal (2, 0x1) 45 1762548 [main] bash 2692 void: 0x0 = signal (3, 0x1) 66 1762614 [main] bash 2692 sigproc_terminate: entering 49 1762663 [main] bash 2692 sig_send: my_sendsig 0x0, myself-sendsig 0x0, exit_state 9 47 1762710 [main] bash 2692 __set_errno: int sig_send(_pinfo*, siginfo_t, _cygtls*):548 val 11 48 1762758 [main] bash 2692 sig_send: returning 0x1 from sending signal -42 46 1762804 [main] bash 2692 proc_terminate: nprocs 0 44 1762848 [main] bash 2692 proc_terminate: leaving 84 1762932 [main] bash 2692 sigproc_terminate: already performed 49 1762981 [main] bash 2692 __to_clock_t: dwHighDateTime 0, dwLowDateTime 100144 47 1763028 [main] bash 2692 __to_clock_t: total 000A 46 1763074 [main] bash 2692 __to_clock_t: dwHighDateTime 0, dwLowDateTime 200288 47 1763121 [main] bash 2692 __to_clock_t: total 0014 933 1764054 [main] bash 2692 pinfo::maybe_set_exit_code_from_windows: pid 2692, exit value - old 0x88B, windows 0xDEADBEEF, cygwin 0x88B 145 1764199 [main] bash 2692 pinfo::exit: Calling ExitThread hProcess 0x0, n 0x8B, exitcode 0x0 Sorry, I forgot to mention, can you please add the stackdump, too? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash login breaks if too many environment variables are set
No problem. here is a new trace (similar to the original) and the related stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610D6971 eax= ebx=10010248 ecx=F2FF edx=00245300 esi=0001 edi=00246000 ebp=0022EE68 esp=0022EE64 program=c:\cygwin\bin\bash.exe, pid 3572, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022EE68 610D6971 (00245300, 0040, 6110E714, 6110E77B) 0022EEE8 6105390B (, , 0022EF18, 61090062) 0022EF18 6106EFC8 (, , 7C90E64E, 77DDDB0D) 0022EFC8 61004D1D (0022EFE0, , 0022EFC0, 77D4A303) 0022FF88 61005B6F (, , , ) End of stack trace ** Program name: c:\cygwin\bin\bash.exe (pid 3504, ppid 1) App version: 1005.18, api: 0.132 DLL version: 1005.19, api: 0.138 DLL build:20050916 00:00:39SNP OS version: Windows NT-5.1 Heap size:1073741824 Date/Time:2005-09-16 13:29:23 ** 27 319 [main] bash 3504 set_myself: myself-dwProcessId 3504 24 343 [main] bash 3504 time: 1126870163 = time (0) 442 785 [main] bash 3504 environ_init: 0x10010238: X$ 37 822 [main] bash 3504 environ_init: 0x10010248: ðH$ 97 919 [main] bash 3504 handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610D6971 sp 0x22EE64 24 943 [main] bash 3504 handle_exceptions: In cygwin_except_handler sig 11 at 0x610D6971 771020 [main] bash 3504 handle_exceptions: In cygwin_except_handler calling 0x0 231043 [main] bash 3504 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 3531396 [main] bash 3504 try_to_debug: debugger_command '' 5191915 [main] bash 3504 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump 861081 862996 [main] bash 3504 signal_exit: about to call do_exit (8B) 81 863077 [main] bash 3504 do_exit: do_exit (139), exit_state 0 67 863144 [main] bash 3504 void: 0x0 = signal (20, 0x1) 59 863203 [main] bash 3504 void: 0x0 = signal (1, 0x1) 55 863258 [main] bash 3504 void: 0x0 = signal (2, 0x1) 55 863313 [main] bash 3504 void: 0x0 = signal (3, 0x1) 79 863392 [main] bash 3504 sigproc_terminate: entering 59 863451 [main] bash 3504 sig_send: my_sendsig 0x0, myself-sendsig 0x0, exit_state 9 58 863509 [main] bash 3504 __set_errno: int sig_send(_pinfo*, siginfo_t, _cygtls*):548 val 11 59 863568 [main] bash 3504 sig_send: returning 0x1 from sending signal -42 57 863625 [main] bash 3504 proc_terminate: nprocs 0 56 863681 [main] bash 3504 proc_terminate: leaving 95 863776 [main] bash 3504 sigproc_terminate: already performed 59 863835 [main] bash 3504 __to_clock_t: dwHighDateTime 0, dwLowDateTime 0 57 863892 [main] bash 3504 __to_clock_t: total 58 863950 [main] bash 3504 __to_clock_t: dwHighDateTime 0, dwLowDateTime 200288 57 864007 [main] bash 3504 __to_clock_t: total 0014 912 864919 [main] bash 3504 pinfo::maybe_set_exit_code_from_windows: pid 3504, exit value - old 0x88B, windows 0xDEADBEEF, cygwin 0x88B 156 865075 [main] bash 3504 pinfo::exit: Calling ExitThread hProcess 0x0, n 0x8B, exitcode 0x0 -Original Message- The problem can be reproduced with cygwin1-20050916.dll Sorry, I forgot to mention, can you please add the stackdump, too? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Python extension package problem root-cause
John, On Thu, Sep 15, 2005 at 10:54:32PM -0700, John Whitley wrote: The test string.find(...) != -1 attempts to test whether /usr appears in the full executable name. This incorrectly fails in the case that /bin is in the user's path before /usr/bin (i.e. string.find(/bin/python,/usr) == -1). Note that a vagary of Cygwin is that /usr/bin is a Cygwin mount to /bin. Thank you very much for the detailed analysis! Workaround: The workaround is to ensure that /usr/bin appears in your path before /bin. It looks like a new and improved Cygwin special case test is needed to fix this problem; I'm not sure offhand what the best case would be. Perhaps an outright test as follows would work: sys.executable.startswith(sys.exec_prefix) or sys.executable.startswith(os.sep+bin) Unfortunately, I'm not sure what is the best way to solve this problem. I will try to get a discussion going on SF... 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin forgets CTRL key press
A quick test with xev under both Linux and Cygwin/X on two systems I have here shows a key release event for CTRL about 4 seconds after I release whatever other key I pressed - I was still holding the CTRL key down! I also see this in a standard Windows Command Prompt window (i.e. Cygwin not involved) but it is harder to judge the delay there. I suspect it may be the keyboard or perhaps the KVM switch, but at least for me it is not Cygwin specific. It also happens for SHIFT, and probably other modifiers too, but I have not tested that. -- Owen Rees Hewlett Packard Laboratories, Bristol, UK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin forgets CTRL key press
Original Message From: Owen Rees Sent: 16 September 2005 13:03 A quick test with xev under both Linux and Cygwin/X on two systems I have here shows a key release event for CTRL about 4 seconds after I release whatever other key I pressed - I was still holding the CTRL key down! I suspect it may be the keyboard or perhaps the KVM switch Bingo. That'll be it. It cancels keypresses to prevent state getting stuck when you switch from one machine to another. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount -X and FAQ [Attn: FAQ Maintainer, tcl maintainer]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Williams, Gerald S (Jerry) on 9/15/2005 10:48 AM: Finally got around to trying that one, but it broke the tkinfo (Tcl/Tk) script I use regularly. Some experimenting revealed that I had to add the following to make it work: mount -f -b -x c:/cygwin/bin/wish84.exe /bin/wish84.exe mount -f -b -x c:/cygwin/bin/wish84.exe /usr/bin/wish84.exe and presumably I'd also want: mount -f -b -x c:/cygwin/bin/tclsh84.exe /bin/tclsh84.exe mount -f -b -x c:/cygwin/bin/tclsh84.exe /usr/bin/tclsh84.exe The FAQ (http://www.cygwin.com/faq/faq_3.html) mentions using this idiom for strace and cygcheck, but not for Tcl/Tk. Perhaps these should be noted as well? Now that strace and cygcheck work in without having to explicitly mount them non-cygexec, the FAQ needs updating anyways. On the other hand, is there any possibility that the tcl maintainer can tweak tcl to work when mounted cygexec by borrowing from what cygcheck did? I know there is a history behind tcl being a native app instead of a tcl app, but it is rather annoying when it doesn't play nicely. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDKrlK84KuGfSFAYARAg8nAJ9sjvLbmdpH5LvEpa8hjmCR4L572ACfTpfH c4vocycLJz+is50LZKOHNLg= =yTOH -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Sep 16 13:31, Hommersom, Fred wrote: No problem. here is a new trace (similar to the original) and the related stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610D6971 eax= ebx=10010248 ecx=F2FF edx=00245300 esi=0001 edi=00246000 ebp=0022EE68 esp=0022EE64 program=c:\cygwin\bin\bash.exe, pid 3572, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022EE68 610D6971 (00245300, 0040, 6110E714, 6110E77B) 0022EEE8 6105390B (, , 0022EF18, 61090062) 0022EF18 6106EFC8 (, , 7C90E64E, 77DDDB0D) 0022EFC8 61004D1D (0022EFE0, , 0022EFC0, 77D4A303) 0022FF88 61005B6F (, , , ) End of stack trace Sure you've used the latest snapshot DLL? I tried to reproduce this with the latest snapshot, as well as a self-build DLL from CVS and I can't reproduce this behaviour. My test environment consisted of 1400 variables with a size of 98K, one of the variables taking roughly 31K alone. However, what's strange in your strace output is this: 442 785 [main] bash 3504 environ_init: 0x10010238: X$ 37 822 [main] bash 3504 environ_init: 0x10010248: ðH$ 97 919 [main] bash 3504 handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610D6971 sp 0x22EE64 The first two lines should contain some valid environment entries, but both of them look broken. There's no hint why this is, of course. I observerd that tcsh doesn't like variables with a length of 31K, though. ash, bash, zsh and pdksh could handle that long environment varibale just fine, tcsh on the other hand printed this: $ echo $VERY_LONG_ENV_VAR Word too long. Sigh, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Sep 16 14:28, Corinna Vinschen wrote: I observerd that tcsh doesn't like variables with a length of 31K, though. ash, bash, zsh and pdksh could handle that long environment varibale just fine, tcsh on the other hand printed this: $ echo $VERY_LONG_ENV_VAR Word too long. Never mind, that's a normal limitation of tcsh. THe same happens on Linux. The actual limit seems to be somewhat below BUFSIZ. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: setup: how to handle circular dependencies?
Original Message From: Gerrit P. Haase Sent: 16 September 2005 14:14 Hi Setup maintainers, I need some circular dependencies, i.e. gcc-core requires gcc-core-mingw because -mno-cygwin will not work without the mingw version of the gcc runtime. However, the gcc-core-mingw package only includes the runtime which needs gcc-core to be useful. Maybe I should include the mingw gcc runtimes in the main gcc packages? I can't see the use in having them separate if gcc-core-mingw is really no use whatsoever on its own. Perhaps someone else can think of a reason? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in gcc and/or binutils?
Danny Smith wrote: References: http://sources.redhat.com/ml/cygwin/2005-09/msg00471.html http://sources.redhat.com/ml/cygwin/2005-09/msg00519.html Charles Wilson cygwin at cwilson dot fastmail dot fm wrote: Using .def files turns off the auto-EXport logic (which it should, because if you specify a specific set of exports you don't want binutils adding a few more on its own). There seems to be a common misconception that auto-export logic and explicit designation of exports are incompatible. You can still use --export-all (to get the auto-export of all defined symbols) with a .def file or with __declspec(dllexport). eg gcc -shared -ofoo.dll foo.def foo.c -Wl,--export-all But this does not help in the test case. The import libs are identical in regard to the symbol, with or without export-all flag, the executable linked with this import lib is broken. The use of a def file (with --export-all) is useful when you want to export all symbols but want special handling of some, say an alias or marking a symbol as PRIVATE (exclude from import lib) or NONAME (exclude the name of the symbol from the dll's export table), (almost like __attribute__((hidden)) Or you may want to add a symbol that is just forwarded to another dll. Or you have a function foo() but only want the indirect ref __imp__foo visible in the import lib, and not the label: foo: jmp * __imp__foo so you only export the pointer by marking as DATA in the def file So if you want export the pointer and use a .def file you must mark it as DATA, else it will not be exported. Though it is not exactly the problem, directly linking to the DLL succeeds with or without (wrong) .def file. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash login breaks if too many environment variables are set
Yes sure. You can see this in the header of the dump its says: DLL version: 1005.19, api: 0.138 DLL build:20050916 00:00:39SNP In order to be sure that we are talking about the same things: I have all these variables in DOS and start bash from a CMD window with command c:\cygwin\bin\strace -o fhbashtrace.txt c:\cygwin\bin\bash As indicated in previous mails the stackdump occurs only with an exact number of characters for all environment names and values together. My names and values have sizes of 1-1000 characters. No extremes. But this dll behaves differently from the production. Now if I have one character less then the 'dumping' number some commands (e.g. ls) works, others don't. I did not find a pattern in it. I'll keep trying. But if I add 10 characters to an enviroment variable ( so 10 more then the number that gives the dump) then bash exits immediately without dump. Strace gives: 27 324 [main] bash 3024 set_myself: myself-dwProcessId 3024 23 347 [main] bash 3024 time: 1126876171 = time (0) 422 769 [main] bash 3024 environ_init: 0x10010238: !C:=C:\Dat No more output here, no stackdump nothing. just exit It looks to me as if a buffer or stack is reused if some maximum is exceeded with effect that the system sometimes works. Fred -Original Message- Sure you've used the latest snapshot DLL? I tried to reproduce this with the latest snapshot, as well as a self-build DLL from CVS and I can't reproduce this behaviour. My test environment consisted of 1400 variables with a size of 98K, one of the variables taking roughly 31K alone. However, what's strange in your strace output is this: 442 785 [main] bash 3504 environ_init: 0x10010238: X$ 37 822 [main] bash 3504 environ_init: 0x10010248: ðH$ 97 919 [main] bash 3504 handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610D6971 sp 0x22EE64 The first two lines should contain some valid environment entries, but both of them look broken. There's no hint why this is, of course. I observerd that tcsh doesn't like variables with a length of 31K, though. ash, bash, zsh and pdksh could handle that long environment varibale just fine, tcsh on the other hand printed this: $ echo $VERY_LONG_ENV_VAR Word too long. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in tcltk's glob
On Fri, Sep 16, 2005 at 12:25:10PM +0200, Sebastian Schuberth wrote: sorry for mailing to you directly, but so far no one responded to my '1.5.18: tclsh's glob and relative paths containing ..' mail on the Cygwin mailing list. Here's a copy: Please check out the project web page for links to available information and ports: http://cygwin.com/ . If you don't see what you need there, then the cygwin mailing list is the best place to make observations or get questions answered. Information on the mailing list is available at the project web page. For your convenience, I've reset the Reply-To: address to point to the cygwin mailing list. I've also Cc'ed this reply there. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount -X and FAQ [Attn: FAQ Maintainer, tcl maintainer]
On Fri, Sep 16, 2005 at 06:23:38AM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Williams, Gerald S (Jerry) on 9/15/2005 10:48 AM: Finally got around to trying that one, but it broke the tkinfo (Tcl/Tk) script I use regularly. Some experimenting revealed that I had to add the following to make it work: mount -f -b -x c:/cygwin/bin/wish84.exe /bin/wish84.exe mount -f -b -x c:/cygwin/bin/wish84.exe /usr/bin/wish84.exe and presumably I'd also want: mount -f -b -x c:/cygwin/bin/tclsh84.exe /bin/tclsh84.exe mount -f -b -x c:/cygwin/bin/tclsh84.exe /usr/bin/tclsh84.exe The FAQ (http://www.cygwin.com/faq/faq_3.html) mentions using this idiom for strace and cygcheck, but not for Tcl/Tk. Perhaps these should be noted as well? Now that strace and cygcheck work in without having to explicitly mount them non-cygexec, the FAQ needs updating anyways. On the other hand, is there any possibility that the tcl maintainer can tweak tcl to work when mounted cygexec by borrowing from what cygcheck did? No. I'm not going to do this. Sorry. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: setup: how to handle circular dependencies?
On Fri, 16 Sep 2005, Dave Korn wrote: Original Message From: Gerrit P. Haase Sent: 16 September 2005 14:14 Hi Setup maintainers, I need some circular dependencies, i.e. gcc-core requires gcc-core-mingw because -mno-cygwin will not work without the mingw version of the gcc runtime. However, the gcc-core-mingw package only includes the runtime which needs gcc-core to be useful. Maybe I should include the mingw gcc runtimes in the main gcc packages? I can't see the use in having them separate if gcc-core-mingw is really no use whatsoever on its own. Perhaps someone else can think of a reason? The only use I can see is later on, if setup allows optional dependencies, someone may be able to save disk space by omitting gcc-core-mingw (and other gcc-mingw packages) if they never plan to use -mno-cygwin. At the moment, having a circular dependency is the same as having the two in the same package -- both will be installed (unless the user goes to great pains to unselect one). What I would suggest, however, is placing a stub in the main gcc package that would produce a meaningful error on -mno-cygwin if *-mingw packages aren't present, thus making gcc-core independent of gcc-core-mingw. If gcc-core-mingw is that exact stub, then by all means fold it into gcc-core. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in tcltk's glob
Christopher Faylor wrote: On Fri, Sep 16, 2005 at 12:25:10PM +0200, Sebastian Schuberth wrote: sorry for mailing to you directly, but so far no one responded to my '1.5.18: tclsh's glob and relative paths containing ..' mail on the Cygwin mailing list. Here's a copy: Please check out the project web page for links to available information and ports: http://cygwin.com/ . If you don't see what you need there, then the cygwin mailing list is the best place to make observations or get questions answered. Information on the mailing list is available at the project web page. For your convenience, I've reset the Reply-To: address to point to the cygwin mailing list. I've also Cc'ed this reply there. I'm sorry but I do not see how the information available on the Cygwin site is able to help me. There is no more recent version of tcltk available from the ports site than the one that ships with Cygwin, and that version is from 2003. So I tried to find out who maintains the tcltk package for Cygwin, and that turned out to be you (see your post on cygwin.applications). So I'd like to kindly ask to if you can privide a never tcltk package which hopefully solve the bug in glob I currently see. Here's the bug again: --(snip)-- puts stdout [glob ../common/*.cpp] For some reason this returns *absolute* paths to the matching files, e.g. d:/Development/common/test.cpp instead of the expected ../common/test.cpp Using ActiveTcl (under Windows) and under Linux the script works as expected. --(snip)-- -- Sebastian Schuberth (remove NOSP and M from my e-mail address) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in tcltk's glob
On Fri, Sep 16, 2005 at 04:22:49PM +0200, Sebastian Schuberth wrote: Christopher Faylor wrote: On Fri, Sep 16, 2005 at 12:25:10PM +0200, Sebastian Schuberth wrote: sorry for mailing to you directly, but so far no one responded to my '1.5.18: tclsh's glob and relative paths containing ..' mail on the Cygwin mailing list. Here's a copy: Please check out the project web page for links to available information and ports: http://cygwin.com/ . If you don't see what you need there, then the cygwin mailing list is the best place to make observations or get questions answered. Information on the mailing list is available at the project web page. For your convenience, I've reset the Reply-To: address to point to the cygwin mailing list. I've also Cc'ed this reply there. I'm sorry but I do not see how the information available on the Cygwin site is able to help me. There is no more recent version of tcltk available from the ports site than the one that ships with Cygwin, and that version is from 2003. The email that you are referring to had this return address: [EMAIL PROTECTED] and contained the following words: Btw, this doesn't go without saying, but please don't use the responses from this email as an excuse to contact people directly about the packages they maintain. So, I don't think that you should be too surprised to receive a canned response. So I tried to find out who maintains the tcltk package for Cygwin, and that turned out to be you (see your post on cygwin.applications). So I'd like to kindly ask to if you can privide a never tcltk package which hopefully solve the bug in glob I currently see. Here's the bug again: FYI, the tcltk package is provided only to support the insight debugger. I know nothing about tcltk so I really can't help with problems. If you have a patch for tcltk, please send it to the insight mailing list. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Unison 2.9.20 and OpenSSH-4.1p1-2: hangs as server.
Brooks, I do remember seeing a lot of reports about 6 months or so ago, that Unison was hanging. My recollection is dim but I think it had to do with some bad combination of versions of cygwin.dll and Unison. Are you using the latest cygwin.dll on your servers? uname -sr returns CYGWIN_NT-5.2 1.5.18(0.132/4/2), which I believe means I'm running the latest version. I also noticed that there was a new OpenSSH package out; I've upgraded to OpenSSH-4.2p1-1 on the server side, and found that this changed nothing with regards to this bug. OK. Invoking unison with -debug will provide a lot of output, which may or may not be useful. At least you can see what was the last thing Unison was doing before it hung, and that may ring a bell somewhere. Also, exceptions and broken pipes are obvious errors that may lead more easily to a solution if you report the details. True enough. I've attached the text of unison -debug 'all' to this; I'm not sure if it's meaningful or not. No, probably not. At least not to me... it just looks like the typical Unison hang: everything seems to be going along fine, and then it just stops. Uncaught exception File /home/aschulma/usr/cygwin/unison2.9.20/unison2.9.20-2.9.20/.build/remote.ml , line 483, characters 2-8: Assertion failed Broken pipe Incidentally, this points out a definite bug in Unison-2.9.20. This exact output also occurs if I specify -maxthreads 1 on the command line, indicating that it is ignoring that option and opening the default 20 threads anyway. (If I use the -debug 'all' option along with -maxthreads 1, it does report maxthreads = 1 in the list at the beginning, so it's parsing the option, just ignoring it.) I suggest that you report both of these errors to the unison-users list: http://groups.yahoo.com/group/unison-users. The Unison developers are generally pretty good about fixing failed assertions, which shouldn't ever happen. They may ask you for more information and/or testing and then post a patch, in which case I'll immediately incorporate it into the Cygwin package and release a new version. However, they may also decline to keep supporting version 2.9.20-- I don't know. If they do, then that suggests that it may be time to remove 2.9.20 (and also 2.9.1) from Cygwin, too. We'll see. Unfortunately, I don't have root on the remote server, so it may be a little difficult to upgrade, but I see that Cygwin does seem to allow having multiple versions of unison around -- many thanks to whomever was responsible for that! You're welcome :) As for being root on your server, that's not required. You can build and install a private copy of Unison (whatever version you like), then from your client just run unison with -serverCmd /path/to/your/local/unison. Good luck, A. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Fri, Sep 16, 2005 at 03:55:14PM +0200, Hommersom, Fred wrote: Yes sure. You can see this in the header of the dump its says: DLL version: 1005.19, api: 0.138 DLL build:20050916 00:00:39SNP In order to be sure that we are talking about the same things: I have all these variables in DOS and start bash from a CMD window with command c:\cygwin\bin\strace -o fhbashtrace.txt c:\cygwin\bin\bash As indicated in previous mails the stackdump occurs only with an exact number of characters for all environment names and values together. My names and values have sizes of 1-1000 characters. No extremes. But this dll behaves differently from the production. Now if I have one character less then the 'dumping' number some commands (e.g. ls) works, others don't. I did not find a pattern in it. I'll keep trying. But if I add 10 characters to an enviroment variable ( so 10 more then the number that gives the dump) then bash exits immediately without dump. Strace gives: 27 324 [main] bash 3024 set_myself: myself-dwProcessId 3024 23 347 [main] bash 3024 time: 1126876171 = time (0) 422 769 [main] bash 3024 environ_init: 0x10010238: !C:=C:\Dat No more output here, no stackdump nothing. just exit It looks to me as if a buffer or stack is reused if some maximum is exceeded with effect that the system sometimes works. From your strace output, it looks to me like windows itself is returning garbage when we ask it for the list of environment variables. If that is the case, we can guard against that but we can't make the passed in environment useful, unfortunately. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash login breaks if too many environment variables are set
From your strace output, it looks to me like windows itself is returning garbage when we ask it for the list of environment variables. If that is the case, we can guard against that but we can't make the passed in environment useful, unfortunately. Is it possible that 'asking for the environment' makes an error in some mapping activity? Anyway, a clear error is better as a garbled environment. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in tcltk's glob
So I tried to find out who maintains the tcltk package for Cygwin, and that turned out to be you (see your post on cygwin.applications). So I'd like to kindly ask to if you can privide a never tcltk package which hopefully solve the bug in glob I currently see. Here's the bug again: FYI, the tcltk package is provided only to support the insight debugger. I know nothing about tcltk so I really can't help with problems. If you have a patch for tcltk, please send it to the insight mailing list. I don't think there is any need to patch tcltk, as I believe the bug has already been fixed in more recent versions than the one supplied with Cygwin. So a simple recompile for Cygwin should do. Unfortunately, I have neither the time nor expertise to do so. -- Sebastian Schuberth (remove NOSP and M from my e-mail address) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bug in tcltk's glob
Original Message From: Sebastian Schuberth Sent: 16 September 2005 16:54 So I tried to find out who maintains the tcltk package for Cygwin, and that turned out to be you (see your post on cygwin.applications). So I'd like to kindly ask to if you can privide a never tcltk package which hopefully solve the bug in glob I currently see. Here's the bug again: FYI, the tcltk package is provided only to support the insight debugger. I know nothing about tcltk so I really can't help with problems. If you have a patch for tcltk, please send it to the insight mailing list. I don't think there is any need to patch tcltk, as I believe the bug has already been fixed in more recent versions than the one supplied with Cygwin. So a simple recompile for Cygwin should do. Unfortunately, I have neither the time nor expertise to do so. Nor do you have sufficient good manners to persuade anyone else to do so on your behalf. So I guess you're SOL then, aren't you? cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
It looks to me as if a buffer or stack is reused if some maximum is exceeded with effect that the system sometimes works. From your strace output, it looks to me like windows itself is returning garbage when we ask it for the list of environment variables. I don't think all places in Windows have the limitation. Corinna reported (and I have reproduced on Win2k, CYGWIN-NT-5.0) that it is quite easy to create an environment larger than 32k and see it in a child process: $ foo=`perl -e 'print ax31000'` $ export foo $ /bin/env | wc -c 34664 But it certainly does look like at least one version of Windows (the OP was using CYGWIN_NT-5.1), when manipulating the environment during .bat execution, is tracking total environment size in a signed short, then croaking as the variable wraps around. The output of 'export -p' just before the breaking point will not be exactly 32k, since Cygwin and bash both add variables to the environment before export has a chance to print it. Meanwhile, it also exposes a bug in xargs, using the above environment: $ xargs --help xargs: environment is too large for exec Oops - xargs was over-eager in not exceeding ARG_MAX, even though --help implied there was nothing to exec, and even though on cygwin the environ and command line do not share common storage in exec*(). -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in gcc and/or binutils?
Danny Smith wrote: Charles Wilson cygwin at cwilson dot fastmail dot fm wrote: Using .def files turns off the auto-EXport logic (which it should, because if you specify a specific set of exports you don't want binutils adding a few more on its own). There seems to be a common misconception that auto-export logic and explicit designation of exports are incompatible. You can still use --export-all (to get the auto-export of all defined symbols) with a .def file or with __declspec(dllexport). eg gcc -shared -ofoo.dll foo.def foo.c -Wl,--export-all Right. Using a .def file or decorating code with __declspec(dllexport) DOES turn off auto-EXport, unless you explicitly turn it back on with --export-all. So, libtool could solve the problem by adding --export-all; but *I think* libtool only wants to export certain symbols, not all of them. So this solution is not the proper one for this particular issue. The use of a def file (with --export-all) is useful when you want to export all symbols but want special handling of some, say an alias or marking a symbol as PRIVATE (exclude from import lib) or NONAME (exclude the name of the symbol from the dll's export table), (almost like __attribute__((hidden)) Or you may want to add a symbol that is just forwarded to another dll. Or you have a function foo() but only want the indirect ref __imp__foo visible in the import lib, and not the label: foo: jmp * __imp__foo so you only export the pointer by marking as DATA in the def file Right -- you'd mark it DATA because it IS data: EXPORTS __imp__foo @1 DATA exports a pointer. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in tcltk's glob
I don't think there is any need to patch tcltk, as I believe the bug has already been fixed in more recent versions than the one supplied with Cygwin. So a simple recompile for Cygwin should do. Unfortunately, I have neither the time nor expertise to do so. Nor do you have sufficient good manners to persuade anyone else to do so on your behalf. So I guess you're SOL then, aren't you? If you're refering to my mistake to contact Chris directly, I'm sorry for that, I didn't read his mail on cygwin.applications to the bottom. That said, I was not surprised to get a canned response, it was just fair. You seem a little harsh with your judgement, Dave. -- Sebastian Schuberth (remove NOSP and M from my e-mail address) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Fri, Sep 16, 2005 at 04:36:00PM +, Eric Blake wrote: It looks to me as if a buffer or stack is reused if some maximum is exceeded with effect that the system sometimes works. From your strace output, it looks to me like windows itself is returning garbage when we ask it for the list of environment variables. I don't think all places in Windows have the limitation. Look at the code. We're inspecting a buffer returned from GetEnvironmentStrings. That is a windows function. The very first things returned from this are garbage. Corinna reported (and I have reproduced on Win2k, CYGWIN-NT-5.0) that it is quite easy to create an environment larger than 32k and see it in a child process: $ foo=`perl -e 'print ax31000'` $ export foo $ /bin/env | wc -c 34664 $ /bin/env | wc -c 34664 You're not testing the same thing. Cygwin deals with environment variables on its own once you've started a cygwin process. It only relies on windows environment-passing mechanisms to pass environment variables to non-cygwin applications. I have a new version of a cygwin snapshot which has more debugging output and which should (temporarily?) fail with an error if environment processing fails. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
I don't think all places in Windows have the limitation. Look at the code. We're inspecting a buffer returned from GetEnvironmentStrings. That is a windows function. The very first things returned from this are garbage. OK, I stand corrected. $ /bin/env | wc -c 34664 $ cmd bash: /cygdrive/c/WINNT/system32/cmd: Invalid argument $ strace /bin/env bash: /usr/bin/strace: Invalid argument On the other hand, POSIX would claim that this usage should be failing with E2BIG, not EINVAL. So it looks like Windows does have a hard limit at total environment size of 32k (in spite of their documentation never mentioning it), but that cygwin could do better at reporting the error when trying to invoke a native process. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bug in tcltk's glob
Original Message From: Sebastian Schuberth Sent: 16 September 2005 17:33 I don't think there is any need to patch tcltk, as I believe the bug has already been fixed in more recent versions than the one supplied with Cygwin. So a simple recompile for Cygwin should do. Unfortunately, I have neither the time nor expertise to do so. Nor do you have sufficient good manners to persuade anyone else to do so on your behalf. So I guess you're SOL then, aren't you? If you're refering to my mistake to contact Chris directly, I'm sorry for that, I didn't read his mail on cygwin.applications to the bottom. That said, I was not surprised to get a canned response, it was just fair. You seem a little harsh with your judgement, Dave. shrugs It's entirely possible I am. Then again, it's entirely possible you should have dropped the matter after the first reply, rather than continuing to importune. So it goes. Have a nice weekend, anyway! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash login breaks if too many environment variables are set
Perhaps I do not understand it. I was talking about invoking cygin from native. The native environment grows far over 32 k. It just does not show up in bash. If I can help by testing the new snapshot: please supply some hints. Fred On the other hand, POSIX would claim that this usage should be failing with E2BIG, not EINVAL. So it looks like Windows does have a hard limit at total environment size of 32k (in spite of their documentation never mentioning it), but that cygwin could do better at reporting the error when trying to invoke a native process. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bash login breaks if too many environment variables are set
On Fri, Sep 16, 2005 at 08:04:57PM +0200, Hommersom, Fred wrote: Perhaps I do not understand it. I was talking about invoking cygin from native. The native environment grows far over 32 k. It just does not show up in bash. If I can help by testing the new snapshot: please supply some hints. AFAICT, Eric is getting sidetracked into issues that are not related to your problem. You can help by running the new snapshot under strace, like you did before. cgf On the other hand, POSIX would claim that this usage should be failing with E2BIG, not EINVAL. So it looks like Windows does have a hard limit at total environment size of 32k (in spite of their documentation never mentioning it), but that cygwin could do better at reporting the error when trying to invoke a native process. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
socket troubles
Hello,
Sorry, I've not been very accurate in my last post so, this time, I'll
post the test client/server
I try to make a little client/server tcp.
server side
#include stdio.h
#include unistd.h
#include fcntl.h
#include time.h
#include setjmp.h
#ifdef SUN
#include signal.h
#else
#include sys/signal.h
#endif
#include sys/wait.h
#include dlfcn.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include unistd.h
#include errno.h
#include stdio.h
#include stdlib.h
#include strings.h
#define SAstruct sockaddr
#define SA_IN struct sockaddr_in
/*
*/
static int init_nw(char *address, int port, SA_IN *servaddr)
{
struct hostent *inf;
int f_on=1;
int s;
s = socket(AF_INET, SOCK_STREAM, 0);
if (s0)
return 0;
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (void *) f_on, sizeof(int));
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, (void *) f_on, sizeof(int));
memset(servaddr, 0, sizeof(SA_IN));
servaddr-sin_family = AF_INET;
servaddr-sin_port = htons((unsigned short)port);
if (address==NULL || strlen(address)==0)
servaddr-sin_addr.s_addr = htonl(INADDR_ANY);
else
servaddr-sin_addr.s_addr = inet_addr(address);
if (servaddr-sin_addr.s_addr==INADDR_NONE)
{
inf = gethostbyname(address);
if (inf==NULL)
return 0;
memcpy( servaddr-sin_addr.s_addr, inf-h_addr, inf-h_length );
}
return s;
}
/*
*
*/
int main(int argc, char *argv[])
{
int sock, sd, r;
SA_IN servaddr;
int rf, f=0;
char ok[2048];
sd = init_nw(, 5600, servaddr);
if (sd=0)
{
exit(500);
}
// blocking
r = fcntl(sd, F_SETFL, f (~O_NONBLOCK) );
if (r0)
{
exit(500);
}
if ( bind(sd, (SA *) servaddr, sizeof(servaddr))==-1 )
{
exit(501);
}
r = listen( sd, 5);
while(1)
{
errno=0;
sock = accept(sd, NULL,NULL);
if (errno==0)
{
rf = fork();
/* father will still listener forever */
if (!rf)
{
fcntl(sock, F_SETFL, f (~O_NONBLOCK) );
shutdown(sd, SHUT_RDWR);
recv(sock, ok, 2048, 0);
sprintf(ok, 01101996 123 444);
send(sock, ok, strlen(ok)+1, 0);
/* no return from client just to block the child */
recv(sock, ok, 2048, 0);
shutdown(sock, SHUT_RDWR);
break;
}
}
else
{
printf(errno = %d, errno);
}
}
shutdown(sd, SHUT_RDWR);
return 0;
}
Ok now, the test side with a simple VC++ 6 program
--
#include windows.h
#include stdafx.h
#include winsock.h
#include sys/types.h
#include unistd.h
#pragma comment(lib, wsock32.lib)
#define SAstruct sockaddr
#define SA_IN struct sockaddr_in
/**
*/
int net_create(char *address, int port, SA_IN *servaddr)
{
struct hostent *inf;
int f_on=1;
int s, r;
s = socket(AF_INET, SOCK_STREAM, 0);
if(s0)
return 0;
r = setsockopt( s, SOL_SOCKET, SO_REUSEADDR, (const char *) f_on,
sizeof(int) );
r = setsockopt( s, SOL_SOCKET, SO_KEEPALIVE, (const char *) f_on,
sizeof(int) );
memset(servaddr, 0, sizeof(SA_IN));
servaddr-sin_family = AF_INET;
servaddr-sin_port = htons((unsigned short)port);
if (address==NULL || strlen(address)==0)
servaddr-sin_addr.s_addr = htonl(INADDR_ANY);
else
servaddr-sin_addr.s_addr = inet_addr(address);
if (servaddr-sin_addr.s_addr==INADDR_NONE)
{
inf = gethostbyname(address);
/* impossible de trouver la dotted, marre... */
if(inf==NULL)
return 0;
memcpy( servaddr-sin_addr.s_addr, inf-h_addr, inf-h_length );
}
return s;
}
/*
*
*/
void test( )
{
int sck;
SA_IN sa;
char m[2048];
sck = net_create(127.0.0.1, 5600, sa);
if (sck=0)
puts(err);
else
{
//r = setsockopt(sck, SOL_SOCKET, SO_SNDBUF, (char *) si, sizeof(int));
//r = getsockopt(sck, SOL_SOCKET, SO_SNDBUF, (char *) si, ln);
//setsockopt(sck, SOL_SOCKET, SO_RCVBUF, (char *) si, sizeof(int));
if ( connect(sck, (SA *) sa, sizeof(sa))==-1 )
closesocket(sck);
else
{
sprintf(m, 19041967|xx|xx|xx|ok|xx);
send(sck, m, strlen(m)+1, 0);
recv(sck, m, 2048, 0);
}
}
}
//
//
void main()
{
int r;
WORD wVersionRequested;
WSADATA wsadata;
wVersionRequested = MAKEWORD(2,0);
WSAStartup(wVersionRequested,wsadata );
for (r=0; r160; r++)
{
test();
printf(%d\n, r);
}
return;
}
Now, my problem :
When I run my program test for the first time, everything is ok...
But after 2 or 3 times... the server side doesn't respond anymore !!?
Where is/are my error(s) ?
ps : Just a remark
I've not managed the zombies process with sigchild(), but I cannot see
one of them
with `ps -ef'
why ?
Thanks you for your answers
--
Unsubscribe info:
RE: Bash login breaks if too many environment variables are set
You can help by running the new snapshot under strace, like you did before. I have done three tests: below the maximum exactly the maximum over the maximum ** Here are the results of the test below the maximum ** Program name: c:\cygwin\bin\bash.exe (pid 3260, ppid 1) App version: 1005.18, api: 0.132 DLL version: 1005.19, api: 0.138 DLL build:20050916 12:02:10SNP OS version: Windows NT-5.1 Heap size:1073741824 Date/Time:2005-09-16 21:41:35 ** 23 240 [main] bash 3260 set_myself: myself-dwProcessId 3260 20 260 [main] bash 3260 time: 1126899695 = time (0) 496 756 [main] bash 3260 environ_init: GetEnvironmentStrings returned 0x2452F8 - =C:=C:\Data\locations\tc50_custy00 36 792 [main] bash 3260 environ_init: 0x10010238: !C:=C:\Data\locations\tc50_custy00 32 824 [main] bash 3260 environ_init: 0x10010260: ACD=C:\Data\TC\TC50\support\acd many more lines ** Here are the results for the exact number where it went wrong. ** *** internal error reading the windows environment - too many environment variables? ** Program name: c:\cygwin\bin\bash.exe (pid 3140, ppid 1) App version: 1005.18, api: 0.132 DLL version: 1005.19, api: 0.138 DLL build:20050916 12:02:10SNP OS version: Windows NT-5.1 Heap size:1073741824 Date/Time:2005-09-16 21:37:00 ** 26 538 [main] bash 3140 set_myself: myself-dwProcessId 3140 24 562 [main] bash 3140 time: 1126899420 = time (0) 14408 14970 [main] bash 3140 environ_init: GetEnvironmentStrings returned 0x2452F8 - x$ 46 15016 [main] bash 3140 environ_init: 0x10010238: X$ 35 15051 [main] bash 3140 environ_init: 0x10010248: ðH$ 76 15127 [main] bash 3140 handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610D6BD1 sp 0x22ED64 24 15151 [main] bash 3140 handle_exceptions: In cygwin_except_handler sig 11 at 0x610D6BD1 21 15172 [main] bash 3140 handle_exceptions: In cygwin_except_handler calling 0x0 ** Here are the results if the environment size is increased by 10 characters No error message in the window. bash quits immediately. The environmentstring is truncated. ** Program name: c:\cygwin\bin\bash.exe (pid 568, ppid 1) App version: 1005.18, api: 0.132 DLL version: 1005.19, api: 0.138 DLL build:20050916 12:02:10SNP OS version: Windows NT-5.1 Heap size:1073741824 Date/Time:2005-09-16 21:44:55 ** 23 282 [main] bash 568 set_myself: myself-dwProcessId 568 20 302 [main] bash 568 time: 1126899895 = time (0) 408 710 [main] bash 568 environ_init: GetEnvironmentStrings returned 0x2552F8 - =C:=C:\Data\location 35 745 [main] bash 568 environ_init: 0x10010238: !C:=C:\Data\location no more lines in this trace -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount -X and FAQ [Attn: FAQ Maintainer, tcl maintainer]
On 9/16/05, Eric Blake wrote: According to Williams, Gerald S (Jerry) on 9/15/2005 10:48 AM: The FAQ (http://www.cygwin.com/faq/faq_3.html) mentions using this idiom for strace and cygcheck, but not for Tcl/Tk. Perhaps these should be noted as well? Now that strace and cygcheck work in without having to explicitly mount them non-cygexec, the FAQ needs updating anyways. OK. Maybe I'll take a stab at creating a script to find exe's in /bin/ not linked to cygwin1.dll and put that in the FAQ instead. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount -X and FAQ [Attn: FAQ Maintainer, tcl maintainer]
On Fri, Sep 16, 2005 at 01:22:10PM -0700, Joshua Daniel Franklin wrote: On 9/16/05, Eric Blake wrote: According to Williams, Gerald S (Jerry) on 9/15/2005 10:48 AM: The FAQ (http://www.cygwin.com/faq/faq_3.html) mentions using this idiom for strace and cygcheck, but not for Tcl/Tk. Perhaps these should be noted as well? Now that strace and cygcheck work in without having to explicitly mount them non-cygexec, the FAQ needs updating anyways. OK. Maybe I'll take a stab at creating a script to find exe's in /bin/ not linked to cygwin1.dll and put that in the FAQ instead. Hooboy. Now you've done it. #!/bin/sh cd /bin; for f in `find . -type f -name '*.exe'`; do cygcheck $f | (fgrep -qi cygwin1.dll || echo $f) done Should do it. You can use this or one of the 27 variations on this that are sure to follow. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount -X and FAQ [Attn: FAQ Maintainer, tcl maintainer]
Joshua Daniel Franklin wrote: OK. Maybe I'll take a stab at creating a script to find exe's in /bin/ not linked to cygwin1.dll and put that in the FAQ instead. In the past I've done this with something like: find /bin -name \*.exe -type f | (while read FN; do cygcheck $FN | \ grep -qi cygwin1.dll || echo $FN: no cygwin1.dll; done) But this will only report strace and cygcheck (and some stuff in glui-examples), it will not detect tclsh84 which does link to cygwin1.dll: Found: C:\cygwin\bin\tclsh84.exe C:/cygwin/bin/tclsh84.exe C:\WINXP\System32\KERNEL32.dll C:\WINXP\System32\ntdll.dll C:\cygwin\bin\cygwin1.dll C:\WINXP\System32\ADVAPI32.DLL C:\WINXP\System32\RPCRT4.dll C:\cygwin\bin\tcl84.dll C:\WINXP\System32\USER32.dll C:\WINXP\System32\GDI32.dll So, I'm not sure if this would be of any use. It might be best just to mention a list of known files that must not be mounted cygexec in the FAQ -- currently just tclsh84. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mount -X and FAQ [Attn: FAQ Maintainer, tcl maintainer]
Brian Dessent wrote: FAQ -- currently just tclsh84. (and wish84) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
