Re: Upload: bash-3.0-3 [test]
Igor Pechtchanski schrieb: On Sat, 2 Jul 2005, Eric Blake wrote: When I'm at my home computer, my email is configured properly. rantBut when I'm elsewhere and have to use the piece-of-trash webmail interface from my ISP, there is no way for me to control it. I have already tried contacting comcast to tell them that wrapping long lines is essential, especially since SMTP allows servers to arbitrarily truncate lines at 999 characters, but to no avail yet (and as a result, have had some of my emails arbitrarily chopped without any warning to me). I try, but don't always remember, to add line breaks manually. And as the reply-to: header is not visible in their webmail interface, I'm never really sure which users prefer reading only the list except by previous experience./rant Sorry for giving you a bad email experience. Sorry to hear that. Yes, if more people would complain to the webmail providers and demand certain basic features, eventually someone will give in. If that someone is Yahoo or GMail, others will probably follow suit. One can hope. :-) Well, I doubt it. I implemented the webmail for a larger provider (top 100 worldwide) and this company didn't care about such complaints. They would have thought about a proper patch for the textbox (textarea wrap=virtual e.g. even if it's non-xhtml compliant), but getting this through would have been harder than contacting the upstream authors (an independent 2nd party) and plead there. -- Reini
Upload: bash-3.0-4 [test]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Changes from 3.0-3: - - compiled against cygwin-1.5.18 (because of the new strtoimax, this bash will not work with cygwin-1.5.17) - - added preremove script that nukes /bin/sh if it is a version of bash Corinna wrote: I'm ready when you're ready. Do I need to add a postinstall script or will your postinstall script care for everything? You should be able to use my postinstall script unchanged - /etc/postinstall/00bash.sh is a one-liner, although you may want to rename yours to 00ash.sh. Do you want to release ash as a test version first, to ensure that we don't have any surprises when running setup.exe? Under that assumption, my setup.hint still has 3.0-4 as a test version for today. You can delete 3.0-3. filesizemd5sum http://home.comcast.net/~ericblake/bash-3.0-4.tar.bz2 414777 792ee2d526faf12447521654456fb450 http://home.comcast.net/~ericblake/bash-3.0-4-src.tar.bz2 2492709 5b17fde01886e05ac410cdf0eee06779 http://home.comcast.net/~ericblake/bash.setup.hint (prev: 2.05b-16, curr: 2.05b-17, test: 3.0-4) 542 ffc95c4c4982946c10d7e32e865a0651 - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCyoww84KuGfSFAYARAq0SAJ4wnVRYV4FX/aiYqr0GC5VlcO4N7ACgyNh5 8+U3FJDeVz5tifszmrOpbgU= =Q5yt -END PGP SIGNATURE-
Re: Upload: bash-3.0-4 [test]
On Jul 5 07:33, Eric Blake wrote: Corinna wrote: I'm ready when you're ready. Do I need to add a postinstall script or will your postinstall script care for everything? You should be able to use my postinstall script unchanged - /etc/postinstall/00bash.sh is a one-liner, although you may want to rename yours to 00ash.sh. In theory. I'm just wondering if your script is safe enough. test -x /bin/sh.exe || link /bin/bash.exe /bin/sh.exe The point is, if somebody wants to upgrade bash but not ash for whatever reason (Gee, *nobody* needs ash, right?), this person will get stuck with ash as sh. without noticing. So, well, why not forcing users to have sh == bash, *if* bash is installed? 00ash.sh: #!/bin/ash link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe 00bash.sh: #!/bin/bash link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe This would also mean, you can get rid of your preremove script again. It seems somewhat dangerous to me anyway. I'd rather have a dangling /bin/sh.exe than none at all. Do you want to release ash as a test version first, to ensure that we don't have any surprises when running setup.exe? I love surprises. Especially if it's not me who's surprised ;-) that assumption, my setup.hint still has 3.0-4 as a test version for today. You can delete 3.0-3. file sizemd5sum http://home.comcast.net/~ericblake/bash-3.0-4.tar.bz2 414777 792ee2d526faf12447521654456fb450 http://home.comcast.net/~ericblake/bash-3.0-4-src.tar.bz2 2492709 5b17fde01886e05ac410cdf0eee06779 http://home.comcast.net/~ericblake/bash.setup.hint (prev: 2.05b-16, curr: 2.05b-17, test: 3.0-4) 542 ffc95c4c4982946c10d7e32e865a0651 I upload as soon as we have discussed the above. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Upload: bash-3.0-4 [test]
On Jul 5 16:03, Corinna Vinschen wrote: 00ash.sh: #!/bin/ash link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe 00bash.sh: #!/bin/bash link /bin/bash.exe /bin/sh.exe || link /bin/ash.exe /bin/sh.exe Erm... make that 00ash.sh: #!/bin/ash ln -f /bin/bash.exe /bin/sh.exe || ln -f /bin/ash.exe /bin/sh.exe 00bash.sh: #!/bin/bash ln -f /bin/bash.exe /bin/sh.exe || ln -f /bin/ash.exe /bin/sh.exe -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Corinna Vinschen wrote: This would also mean, you can get rid of your preremove script again. It seems somewhat dangerous to me anyway. I'd rather have a dangling /bin/sh.exe than none at all. One possible problem, BTW, is that if a process that uses /bin/sh is running concurrently with the postinstall script (which happens all-too-often), the link will fail, and there is no replace-on-reboot alternative (as setup offers). I love surprises. Especially if it's not me who's surprised ;-) Hehe. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Upload: bash-3.0-4 [test]
On Jul 5 16:05, Eric Blake wrote: At any rate, you are probably right that a postinstall script may be all that is needed (no preremove script) if it ensures that /bin/sh always exists, and that if it is missing, is ash, or is an older version of bash, that it gets upgraded. But I would still like to leave it alone if it does not fit those three categories. How about this for the postinstalls? 00ash.sh: #!/bin/ash # If /bin/sh is missing or is ash, upgrade to bash. If that fails, set # it to the latest ash (so that /bin/sh always exists after this script). case `(/bin/sh.exe --version) 21` in *not\ found* | GNU\ bash* | Illegal\ option\ --*) ln -f /bin/bash.exe /bin/sh.exe || ln -f /bin/ash.exe /bin/sh.exe ;; *) # User must have modified /bin/sh; leave it alone ;; esac #!/bin/bash # If /bin/sh is missing, ash, or bash, upgrade it to the current bash. case `/bin/sh.exe --version 21 *No\ such\ file* | GNU\ bash* | Illegal\ option\ --*) ln -f /bin/bash.exe /bin/sh.exe ;; *) # User must have modified /bin/sh; leave it alone ;; esac Note that the two postinstalls are not quite interchangeable - missing files have different behaviors (in ash, you must run the check in a subshell to capture the not found error for parsing in the case statement, while in bash, running in the current shell captures the No such file error). Furthermore, bash doesn't need a fallback, since /bin/bash must exist for the script to even be running. Cool with me (and thanks for preparing the ash script). If you want to release another test release using the above 00bash.sh script, please do. If you want to move bash out of test (this week or in August), just ping me and I'll release a new ash package. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Upload: bash-3.0-4 [test]
On Jul 5 18:22, Corinna Vinschen wrote: Cool with me (and thanks for preparing the ash script). If you want to release another test release using the above 00bash.sh script, please do. If you want to move bash out of test (this week or in August), just ping me and I'll release a new ash package. Hang on, what about /usr/share/man/man1/sh.1 ? Right now it's a fixed symlink to ash.1. THe postinstall scripts should better symlink it to the shell's man page which really is sh after the script did its job, right? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Eric Blake wrote: In theory. I'm just wondering if your script is safe enough. test -x /bin/sh.exe || link /bin/bash.exe /bin/sh.exe The point is, if somebody wants to upgrade bash but not ash for whatever reason (Gee, *nobody* needs ash, right?), this person will get stuck with ash as sh. without noticing. So, well, why not forcing users to have sh == bash, *if* bash is installed? My intent was to allow someone (presumably only those with more experience would attempt this) to replace /bin/sh with ksh or zsh, to match their preferences. After all, just because Linux has /bin/sh as bash doesn't mean that other systems do, and IIRC, MacOS prefers zsh as /bin/sh. Right. Would adding a dependency on bash to ash help? Then again, if someone is stupid enough to deselect ash (since it is part of Base) when doing their upgrade, then adding a bash dependency on ash won't do any good. It seems like it would be nice if dependency tracking could allow a package to require a minimum version of the packages it depends on. Well, the newer setup versions (snapshots) will warn if dependencies are unselected. At any rate, you are probably right that a postinstall script may be all that is needed (no preremove script) if it ensures that /bin/sh always exists, and that if it is missing, is ash, or is an older version of bash, that it gets upgraded. But I would still like to leave it alone if it does not fit those three categories. How about this for the postinstalls? 00ash.sh: #!/bin/ash # If /bin/sh is missing or is ash, upgrade to bash. If that fails, set # it to the latest ash (so that /bin/sh always exists after this script). case `(/bin/sh.exe --version) 21` in *not\ found* | GNU\ bash* | Illegal\ option\ --*) ln -f /bin/bash.exe /bin/sh.exe || ln -f /bin/ash.exe /bin/sh.exe ;; *) # User must have modified /bin/sh; leave it alone ;; esac #!/bin/bash # If /bin/sh is missing, ash, or bash, upgrade it to the current bash. case `/bin/sh.exe --version 21 FYI, this is missing a closing backtick and the in. *No\ such\ file* | GNU\ bash* | Illegal\ option\ --*) ln -f /bin/bash.exe /bin/sh.exe ;; *) # User must have modified /bin/sh; leave it alone ;; esac Note that the two postinstalls are not quite interchangeable - missing files have different behaviors (in ash, you must run the check in a subshell to capture the not found error for parsing in the case statement, while in bash, running in the current shell captures the No such file error). Furthermore, bash doesn't need a fallback, since /bin/bash must exist for the script to even be running. This isn't good enough -- I think you do need a preremove script. I've been trying to figure out why the no-preremove solution seems wrong, and came up with the following scenario: suppose bash is linked against an older libreadline, and the user upgrades both bash and libreadline to newer versions. /bin/sh will be a copy of the old version of bash, but after the upgrade it won't have the necessary DLLs. So, running the postinstall script (with /bin/sh --version) will result in a Can't locate DLL popup, which should be a no-no in a postinstall script. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Files created in postinstall (Was Re: Upload: bash-3.0-4 [test])
On Tue, 5 Jul 2005, Corinna Vinschen wrote: Hang on, what about /usr/share/man/man1/sh.1 ? Right now it's a fixed symlink to ash.1. THe postinstall scripts should better symlink it to the shell's man page which really is sh after the script did its job, right? Speaking of files/symlinks created in postinstall scripts -- perhaps we should come up with some unified mechanism for listing them. Some postinstall scripts use /etc/preremove/PKGNAME-manifest.lst. The reason it may be useful to have a common mechanism is that cygcheck -c could then use the manifest files in addition to the package listing to check whether the package is complete. That would have caught, for example, the man.conf problem reported recently on the main list. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Eric Blake wrote: #!/bin/bash # If /bin/sh is missing, ash, or bash, upgrade it to the current bash. case `/bin/sh.exe --version 21 FYI, this is missing a closing backtick and the in. Yep, you caught me typing on the fly instead of pasting a tested script. Should man/man1/sh.1 always belong to bash, or should I use readlink to ensure that I am only upgrading that link if it was to ash? In other words, for users smart enough to replace /bin/sh with zsh, are they also going to want to replace the /bin/sh manpage and expect that replacement to be preserved? This isn't good enough -- I think you do need a preremove script. I've been trying to figure out why the no-preremove solution seems wrong, and came up with the following scenario: suppose bash is linked against an older libreadline, and the user upgrades both bash and libreadline to newer versions. /bin/sh will be a copy of the old version of bash, but after the upgrade it won't have the necessary DLLs. So, running the postinstall script (with /bin/sh --version) will result in a Can't locate DLL popup, which should be a no-no in a postinstall script. Thanks for thinking through these issues. I think we are closing in on the best solution, and yes, I agree with your argument that bash should keep its preremove script. Is there anything (in cygutils, perhaps) that can request a replace-on-reboot if ln fails in the postinstall because /bin/sh was in use during the upgrade? Then again, we already recommend that all cygwin processes be stopped during an upgrade. -- Eric Blake
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Eric Blake wrote: On Tue, 5 Jul 2005, Eric Blake wrote: #!/bin/bash # If /bin/sh is missing, ash, or bash, upgrade it to the current bash. case `/bin/sh.exe --version 21 FYI, this is missing a closing backtick and the in. Yep, you caught me typing on the fly instead of pasting a tested script. :-D Should man/man1/sh.1 always belong to bash, or should I use readlink to ensure that I am only upgrading that link if it was to ash? In other words, for users smart enough to replace /bin/sh with zsh, are they also going to want to replace the /bin/sh manpage and expect that replacement to be preserved? I'd say you should only replace it if it belonged to ash. But it also seems to me that the whole postinstall process is getting too complex, and calls for some sort of helper apps. This isn't good enough -- I think you do need a preremove script. I've been trying to figure out why the no-preremove solution seems wrong, and came up with the following scenario: suppose bash is linked against an older libreadline, and the user upgrades both bash and libreadline to newer versions. /bin/sh will be a copy of the old version of bash, but after the upgrade it won't have the necessary DLLs. So, running the postinstall script (with /bin/sh --version) will result in a Can't locate DLL popup, which should be a no-no in a postinstall script. Thanks for thinking through these issues. I think we are closing in on the best solution, and yes, I agree with your argument that bash should keep its preremove script. Is there anything (in cygutils, perhaps) that can request a replace-on-reboot if ln fails in the postinstall because /bin/sh was in use during the upgrade? Not that I know of, but if there were such a tool, cygutils is where it would belong, IMO. It would seem that something like the following would be the right idiom for this: /bin/ln -f /bin/bash /bin/sh || /bin/replace-on-reboot -f /bin/bash /bin/sh RANT However, the whole replace-on-reboot issue has a few consequences that are, IMO, undesirable (such as a reboot). One of the things I've been meaning to do is change setup to notify the user (in interactive mode, of course) that some processes are running, and give the user an option of stopping the relevant processes and retrying the update (or choosing to do the default thing and replace-on-reboot). When (and if) I get to it, the postinstall scripts should be able to offer the same options. There's also the question of notification (Some in-use files were replaced, please reboot) -- whatever mechanism is used in postinstall scripts, it would be useful to communicate the replace-on-reboot usage to setup. I also wonder if setup should be able to tell the postinstall scripts whether it's running in interactive mode. /RANT Then again, we already recommend that all cygwin processes be stopped during an upgrade. Yes, but that doesn't mean that the setup process shouldn't be robust enough to handle users who don't follow directions. :-) 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Upload: bash-3.0-4 [test]
On Jul 5 12:33, Igor Pechtchanski wrote: This isn't good enough -- I think you do need a preremove script. I've been trying to figure out why the no-preremove solution seems wrong, and came up with the following scenario: suppose bash is linked against an older libreadline, and the user upgrades both bash and libreadline to newer versions. /bin/sh will be a copy of the old version of bash, but after the upgrade it won't have the necessary DLLs. So, running the postinstall script (with /bin/sh --version) will result in a Can't locate DLL popup, which should be a no-no in a postinstall script. Actually that would be covered by postinstall scripts which don't use /bin/sh at all. What about using md5sum to figure out if it's bash or ash and if it's an old or new version? I still don't like the idea of a preremove script removing /bin/sh under whatever circumstances. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Upload: bash-3.0-4 [test]
On Jul 5 13:32, Igor Pechtchanski wrote: How about using a dummy executable that doesn't depend on anything and does nothing but print out some pre-defined message, and copying that to /bin/sh in the preremove script? That way, there will always be a (non-working, but who cares) /bin/sh... I was going to suggest /bin/false, but the new version actually depends on cygintl-3.dll and cygiconv-2.dll -- go figure. Aren't we making this all too complicated? If you ask me, we should release a new setup.exe which refuses to deinstall the packages from the Base category. If anybody suffers from manual deinstalles, it's entirely a user fault and the person deserves all types of suffering. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Corinna Vinschen wrote: On Jul 5 13:32, Igor Pechtchanski wrote: How about using a dummy executable that doesn't depend on anything and does nothing but print out some pre-defined message, and copying that to /bin/sh in the preremove script? That way, there will always be a (non-working, but who cares) /bin/sh... I was going to suggest /bin/false, but the new version actually depends on cygintl-3.dll and cygiconv-2.dll -- go figure. Aren't we making this all too complicated? If you ask me, we should release a new setup.exe which refuses to deinstall the packages from the Base category. If anybody suffers from manual deinstalles, it's entirely a user fault and the person deserves all types of suffering. It's not a question of deinstalling -- this also happens during upgrades. We want to be able to upgrade /bin/sh cleanly. FWIW, I don't think it matters that /bin/sh doesn't exist in the short time between removing the old version and installing the new one, so a preremove approach is just fine. This doesn't invalidate your point about not allowing to uninstall stuff in Base (at least, not without multiple warnings and Are you sure?s). 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Upload: bash-3.0-4 [test]
This isn't good enough -- I think you do need a preremove script. I've been trying to figure out why the no-preremove solution seems wrong, and came up with the following scenario: suppose bash is linked against an older libreadline, and the user upgrades both bash and libreadline to newer versions. /bin/sh will be a copy of the old version of bash, but after the upgrade it won't have the necessary DLLs. So, running the postinstall script (with /bin/sh --version) will result in a Can't locate DLL popup, which should be a no-no in a postinstall script. Maybe we are getting ahead of ourselves. libreadline, libintl, and libiconv are all versioned libraries, maintained by capable people who understand the importance of maintaining backwards compatibility. Upgrading bash and the libraries simultaneously should not break the older version of bash; even if the library API changes, it would mean the introduction of a new package (such as libreadline7, rather than breaking libreadline6). All I can think of is upgrading bash while removing one of the libraries, in which case the user deserves the Can't locate DLL popup (that is, if the new bash is even runnable without those same libraries just deleted). [side note - when is the new setup.exe ever going to be declared ready for release, so that users are more forcefully warned that they are deselecting required dependencies?] And even new versions of bash that depend on new versions of libraries can still list the old library package name as a dependency, to ensure that the upgrade does not delete the old library. Actually that would be covered by postinstall scripts which don't use /bin/sh at all. Yep, that's what I meant. OK, then, does anyone else have ideas on how to determine if /bin/sh is ash with resorting to running it, and without resorting to packing an ever-increasing list of known md5sums of all prior versions in the bash postinstall script? I still think parsing '/bin/sh --version' is the cleanest approach, even if it does lead to the risk of a popup box if the user uninstalled a library. What message gets printed by bash when trying to invoke an executable whose dependent library can't be found? Even if the user does get the popup box, the bash script can still be made to treat that the same as /bin/sh not being installed, as its trigger to update to the current version of bash. In other words, the popup box would be annoying, but would not prevent the upgrade from happening. I still don't like the idea of a preremove script removing /bin/sh under whatever circumstances. How about using a dummy executable that doesn't depend on anything and does nothing but print out some pre-defined message, and copying that to /bin/sh in the preremove script? That way, there will always be a (non-working, but who cares) /bin/sh... I was going to suggest /bin/false, but the new version actually depends on cygintl-3.dll and cygiconv-2.dll -- go figure. Again, do we need to go to this much effort? If the postinstall script can upgrade bash gracefully (insofar as the user is not running /bin/sh concurrently in the background and has not manually deselected dependencies), then leaving /bin/sh untouched at preremove time is the simplest course of action. -- Eric Blake
Re: Upload: bash-3.0-4 [test]
What message gets printed by bash when trying to invoke an executable whose dependent library can't be found? Even if the user does get the popup box, the bash script can still be made to treat that the same as /bin/sh not being installed, as its trigger to update to the current version of bash. In other words, the popup box would be annoying, but would not prevent the upgrade from happening. Answering myself, I just uninstalled libkpathsea*, then tried to invoke lilypond. Bash reports an exit status of 128 (which doesn't match any signal name), and prints nothing, but the following idiom would allow me to check for failed invocations, once the user clicks the popup box away [RANT - why can't Windows give us a means to find out about missing dependencies without a stupid modal box?]: case `/bin/sh --version 2/dev/null || echo invocation failed` in GNU\ bash* | Illegal\ option\ --* | *No\ such\ file*) # working bash, ash, or missing /bin/sh, so upgrade ;; invocation\ failed) # no output whatsoever, assume broken bash, so upgrade ;; *) # Some other output, regardless of whether in included # invocation failed, so leave alone esac Or, I could first do cygcheck /bin/sh.exe, and see if Error: could not find libname.dll appears in the output, before ever trying to invoke /bin/sh --version. -- Eric Blake
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Eric Blake wrote: This isn't good enough -- I think you do need a preremove script. I've been trying to figure out why the no-preremove solution seems wrong, and came up with the following scenario: suppose bash is linked against an older libreadline, and the user upgrades both bash and libreadline to newer versions. /bin/sh will be a copy of the old version of bash, but after the upgrade it won't have the necessary DLLs. So, running the postinstall script (with /bin/sh --version) will result in a Can't locate DLL popup, which should be a no-no in a postinstall script. Maybe we are getting ahead of ourselves. Perhaps we are. I'm just uncomfortable with running an old version of some package after upgrading to the new version. libreadline, libintl, and libiconv are all versioned libraries, maintained by capable people who understand the importance of maintaining backwards compatibility. Upgrading bash and the libraries simultaneously should not break the older version of bash; even if the library API changes, it would mean the introduction of a new package (such as libreadline7, rather than breaking libreadline6). All I can think of is upgrading bash while removing one of the libraries, in which case the user deserves the Can't locate DLL popup (that is, if the new bash is even runnable without those same libraries just deleted). I disagree. The removal may happen via a dummy upgrade helper, for example. As I said above, I'm uncomfortable with running a program when it's not guaranteed that all of its dependencies are present. Sure, we can prevent this by being careful, but someone is bound to screw up sooner or later -- isn't it better to avoid the whole situation altogether? This may not apply to the bash/ash interaction, BTW, but in general I think we should design it right from the start. [side note - when is the new setup.exe ever going to be declared ready for release, so that users are more forcefully warned that they are deselecting required dependencies?] Even if it's released soon, this won't help, as the dependency is not of the new package, but of the old one, and setup doesn't check for that. And even new versions of bash that depend on new versions of libraries can still list the old library package name as a dependency, to ensure that the upgrade does not delete the old library. Ugh, that's bad. You'll need to make bash depend on all libraries that all previous versions of bash ever depended on -- remember, the old bash could be *any version*. Actually that would be covered by postinstall scripts which don't use /bin/sh at all. Yep, that's what I meant. OK, then, does anyone else have ideas on how to determine if /bin/sh is ash with resorting to running it, and without resorting to packing an ever-increasing list of known md5sums of all prior versions in the bash postinstall script? I do. :-) Run cmp /bin/bash /bin/sh in the preremove script, when you're guaranteed that if /bin/sh is bash, it's the exact same bash that is currently installed. I still think parsing '/bin/sh --version' is the cleanest approach, even if it does lead to the risk of a popup box if the user uninstalled a library. What message gets printed by bash when trying to invoke an executable whose dependent library can't be found? Even if the user does get the popup box, the bash script can still be made to treat that the same as /bin/sh not being installed, as its trigger to update to the current version of bash. In other words, the popup box would be annoying, but would not prevent the upgrade from happening. Unfortunately, it would, since the popup is modal. Welcome to Windows. I still don't like the idea of a preremove script removing /bin/sh under whatever circumstances. How about using a dummy executable that doesn't depend on anything and does nothing but print out some pre-defined message, and copying that to /bin/sh in the preremove script? That way, there will always be a (non-working, but who cares) /bin/sh... I was going to suggest /bin/false, but the new version actually depends on cygintl-3.dll and cygiconv-2.dll -- go figure. Again, do we need to go to this much effort? If the postinstall script can upgrade bash gracefully (insofar as the user is not running /bin/sh concurrently in the background and has not manually deselected dependencies), then leaving /bin/sh untouched at preremove time is the simplest course of action. Why all this effort of avoiding removing /bin/sh? The two times the preremove script would be run are on uninstall and on upgrade. Uninstall should be disallowed by other means (e.g., explicitly checking in setup when packages in Base are uninstalled), and upgrades are harmless, IMO. So why try to avoid removing /bin/sh in a preremove script? Igor -- http://cs.nyu.edu/~pechtcha/ |\
Re: Upload: bash-3.0-4 [test]
On Jul 5 18:23, Eric Blake wrote: Or, I could first do cygcheck /bin/sh.exe, and see if Error: could not find libname.dll appears in the output [...] Or even just test -f... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Trial Cygwin packages available for octave-2.1.71
James R. Phillips wrote: Trial Cygwin packages are now available for octave-2.1.71. These packages are dependent on the lapack-3.0 package now awaiting upload. Looks good. A very nice contribution to the cygwin packages. octave starts and seems to work, though I can't judge that very well since I never used octave so far. I overrode the PATH in my .bash_login, so the /usr/lib/lapack was not in the PATH, leading to cygblas.dll and cyglapack.dll not being found. Maybe an idea to put a remark on the importance of /usr/lib/lapack being in the PATH in octave-2.1.71.README. The cygwin specific documentation dwells in /usr/doc/Cygwin and /usr/doc/octave-2.71. I guess this should be /usr/share/doc. Teun
Re: Upload: bash-3.0-4 [test]
Or, I could first do cygcheck /bin/sh.exe, and see if Error: could not find libname.dll appears in the output [...] Or even just test -f... test -f /bin/sh.exe checks whether /bin/sh exists. From there, cygcheck /bin/sh.exe and parsing the output for Error: could not find checks whether attempting to run sh would cause a popup box. (Too bad cygcheck exit status doesn't currently work). So, how about this, which only runs /bin/sh --version if cygcheck found no missing dependencies: 00bash.sh: #!/bin/bash # Update /bin/sh to be this version of bash if it is missing, ash, # older bash, or un-runnable. Leave it alone if it is anything else. running=yes update=yes test -x /bin/sh.exe || running=no # missing executable case `cygcheck /bin/sh.exe` in *Error:\ could\ not\ find*) running=no;; # missing library esac test $running = yes case `/bin/sh.exe --version 21` in Illegal\ option\ --*) ;; # ash GNU\ bash*) ;; # possibly-older version of bash *) update=no ;; # leave anything else alone esac test $update = yes ln -f /bin/bash.exe /bin/sh.exe This works even on the upgrade path that Igor originally complained about, without requiring a separate preremove. Users wanting to completely uninstall cygwin already have enough other files which setup.exe won't remove, that leaving a dangling /bin/sh won't be any worse than the status quo. -- Eric Blake
Re: Trial Cygwin packages available for octave-2.1.71
--- Teun Burgers wrote: I overrode the PATH in my .bash_login, so the /usr/lib/lapack was not in the PATH, leading to cygblas.dll and cyglapack.dll not being found. Maybe an idea to put a remark on the importance of /usr/lib/lapack being in the PATH in octave-2.1.71.README. OK. I'll fix that before sending an upload request. Similarly, I think I will put in remarks about needing to have gnuplot and X11 installed in order to use plotting functions. The cygwin specific documentation dwells in /usr/doc/Cygwin and /usr/doc/octave-2.71. I guess this should be /usr/share/doc. Good catch. Again, I'll fix before sending an upload request. Thanks for your review. Jim Phillips
Re: Upload: bash-3.0-4 [test]
On Tue, 5 Jul 2005, Igor Pechtchanski wrote: On Tue, 5 Jul 2005, Eric Blake wrote: OK, then, does anyone else have ideas on how to determine if /bin/sh is ash with resorting to running it, and without resorting to packing an ever-increasing list of known md5sums of all prior versions in the bash postinstall script? I do. :-) Run cmp /bin/bash /bin/sh in the preremove script, when you're guaranteed that if /bin/sh is bash, it's the exact same bash that is currently installed. I second that method. It's the only thing that makes sense to me. Why all this effort of avoiding removing /bin/sh? The two times the preremove script would be run are on uninstall and on upgrade. Uninstall should be disallowed by other means (e.g., explicitly checking in setup when packages in Base are uninstalled), and upgrades are harmless, IMO. So why try to avoid removing /bin/sh in a preremove script? FWIW, I agree with this too. -- 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: Files created in postinstall (Was Re: Upload: bash-3.0-4 [test])
Speaking of files/symlinks created in postinstall scripts -- perhaps we should come up with some unified mechanism for listing them. Some postinstall scripts use /etc/preremove/PKGNAME-manifest.lst. The reason it may be useful to have a common mechanism is that cygcheck -c could then use the manifest files in addition to the package listing to check whether the package is complete. That would have caught, for example, the man.conf problem reported recently on the main list. Sounds good to me. The upcoming bash-3.0-5 now includes /etc/preremove/bash-manifest.lst, and attached is a patch to g-b-s to make it easier to build one (just add CYGWIN-PATCHES/manifest.lst). I guess I should also update cygwin.com/setup.html - where is that stored in CVS? 2005-07-05 Eric Blake [EMAIL PROTECTED] * templates/generic-build-script (options): Add almostall, help, version. (help, version): New functions. (install): Support manifest lists. -- Eric Blake gbs.patch Description: Binary data
winsup/cygwin ChangeLog malloc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-07-05 15:11:49 Modified files: cygwin : ChangeLog malloc.cc Log message: * malloc.cc: Update to version 2.8.2. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2991r2=1.2992 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/malloc.cc.diff?cvsroot=uberbaumr1=1.8r2=1.9
winsup/cygwin malloc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Branch: vendor Changes by: [EMAIL PROTECTED] 2005-07-05 15:21:27 Modified files: cygwin : malloc.cc Log message: Check in base 2.8.2. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/malloc.cc.diff?cvsroot=uberbaumonly_with_tag=vendorr1=1.9r2=1.9.2.1
winsup/cygwin ChangeLog dcrt0.cc sigproc.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-07-05 20:20:49 Modified files: cygwin : ChangeLog dcrt0.cc sigproc.cc Log message: * dcrt0.cc (cygwin_exit): Mark as noreturn. * sigproc.cc (child_info::ready): Don't signal parent that we are a cygwin process if we are dynamically loaded. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2992r2=1.2993 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/dcrt0.cc.diff?cvsroot=uberbaumr1=1.247r2=1.248 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.229r2=1.230
winsup/utils ChangeLog cygcheck.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-07-05 21:41:38 Modified files: utils : ChangeLog cygcheck.cc Log message: * cygcheck.cc (track_down, cygcheck): Return true on success. (main): Reflect cygcheck failures in exit status. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/utils/ChangeLog.diff?cvsroot=uberbaumr1=1.321r2=1.322 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/utils/cygcheck.cc.diff?cvsroot=uberbaumr1=1.74r2=1.75
cygcheck exit status
As mentioned on cygwin (hopefully I'm not falling afoul of trivial patch size,
since I don't have assignment; and hopefully gmane didn't kill this):
2005-07-05 Eric Blake [EMAIL PROTECTED]
* cygcheck.cc (track_down, cygcheck): Return true on success.
(main): Reflect cygcheck failures in exit status.
Index: winsup/utils/cygcheck.cc
===
RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
retrieving revision 1.74
diff -u -b -p -r1.74 cygcheck.cc
--- winsup/utils/cygcheck.cc30 May 2005 15:49:31 - 1.74
+++ winsup/utils/cygcheck.cc5 Jul 2005 20:46:38 -
@@ -364,7 +364,7 @@ struct ImpDirectory
};
-static void track_down (char *file, char *suffix, int lvl);
+static bool track_down (char *file, char *suffix, int lvl);
#define CYGPREFIX (sizeof (%%% Cygwin ) - 1)
static void
@@ -554,26 +554,27 @@ dll_info (const char *path, HANDLE fh, i
cygwin_info (fh);
}
-static void
+// Return true on success, false if error printed
+static bool
track_down (char *file, char *suffix, int lvl)
{
if (file == NULL)
{
display_error (track_down: NULL passed for file, true, false);
- return;
+ return false;
}
if (suffix == NULL)
{
display_error (track_down: NULL passed for suffix, false, false);
- return;
+ return false;
}
char *path = find_on_path (file, suffix, 0, 1);
if (!path)
{
printf (Error: could not find %s\n, file);
- return;
+ return false;
}
Did *d = already_did (file);
@@ -589,7 +590,7 @@ track_down (char *file, char *suffix, in
printf (%s, path);
printf ( (recursive)\n);
}
- return;
+ return true;
case DID_INACTIVE:
if (verbose)
{
@@ -598,7 +599,7 @@ track_down (char *file, char *suffix, in
printf (%s, path);
printf ( (already done)\n);
}
- return;
+ return true;
default:
break;
}
@@ -609,7 +610,7 @@ track_down (char *file, char *suffix, in
if (!path)
{
printf (%s not found\n, file);
- return;
+ return false;
}
printf (%s, path);
@@ -620,7 +621,7 @@ track_down (char *file, char *suffix, in
if (fh == INVALID_HANDLE_VALUE)
{
printf ( - Cannot open\n);
- return;
+ return false;
}
d-state = DID_ACTIVE;
@@ -629,6 +630,7 @@ track_down (char *file, char *suffix, in
d-state = DID_INACTIVE;
if (!CloseHandle (fh))
display_error (track_down: CloseHandle());
+ return true;
}
static void
@@ -653,14 +655,15 @@ ls (char *f)
display_error (ls: CloseHandle());
}
-static void
+// Return true on success, false if error printed
+static bool
cygcheck (char *app)
{
char *papp = find_on_path (app, (char *) .exe, 1, 0);
if (!papp)
{
printf (Error: could not find %s\n, app);
- return;
+ return false;
}
char *s = strdup (papp);
char *sl = 0, *t;
@@ -675,7 +678,7 @@ cygcheck (char *app)
paths[0] = s;
}
did = 0;
- track_down (papp, (char *) .exe, 0);
+ return track_down (papp, (char *) .exe, 0);
}
@@ -1590,6 +1593,7 @@ int
main (int argc, char **argv)
{
int i;
+ bool ok = true;
load_cygwin (argc, argv);
(void) putenv(POSIXLY_CORRECT=1);
@@ -1677,7 +1681,7 @@ main (int argc, char **argv)
{
if (i)
puts ();
- cygcheck (argv[i]);
+ ok = cygcheck (argv[i]);
}
if (sysinfo)
@@ -1693,5 +1697,5 @@ main (int argc, char **argv)
puts (Use -h to see help about each section);
}
- return 0;
+ return ok ? EXIT_SUCCESS : EXIT_FAILURE;
}
Re: cygcheck exit status
On Tue, Jul 05, 2005 at 08:49:06PM +, Eric Blake wrote:
@@ -1677,7 +1681,7 @@ main (int argc, char **argv)
{
if (i)
puts ();
- cygcheck (argv[i]);
+ ok = cygcheck (argv[i]);
Why are you anding the result here? Why not just set ok = cygcheck (...)?
cgf
Re: cygcheck exit status
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes:
On Tue, Jul 05, 2005 at 08:49:06PM +, Eric Blake wrote:
at at -1677,7 +1681,7 at at main (int argc, char **argv)
{
if (i)
puts ();
- cygcheck (argv[i]);
+ ok = cygcheck (argv[i]);
Why are you anding the result here? Why not just set ok = cygcheck (...)?
Because it's in a for loop, and when the first file fails but second succeeds,
you still want the overall command to exit with failure.
Re: Qestion about Bash Fork Resource Temporily Unavailable for NS2.28 and NS2.27
Hi, Larry, While I install NS2.28, it tells no gcc, but I actually installed gcc, and during the installation, it said my gcc is not a cross compile, I don't know if this is matter. And if it is, which gcc version shall I install? I ran the strace.exe command, get the following lines, Thank you for support. I look forward to your reply. m = normalize_win32_path (c:\WINDOWS\System32\Wbem) 163 13894 [main] install 15336 mount_info::conv_to_posix_path: /cygdriv INDOWS/System32/Wbem = conv_to_posix_path (c:\WINDOWS\System32\Wbem) 161 14055 [main] install 15336 mount_info::conv_to_posix_path: conv_to_ _path (c:\Program Files\ATI Technologies\ATI Control Panel, keep-rel, no-ad sh) 187 14242 [main] install 15336 normalize_win32_path: c:\Program Files\A chnologies\ATI Control Panel = normalize_win32_path (c:\Program Files\ATI T logies\ATI Control Panel) 200 14442 [main] install 15336 mount_info::conv_to_posix_path: /cygdriv rogram Files/ATI Technologies/ATI Control Panel = conv_to_posix_path (c:\Pr Files\ATI Technologies\ATI Control Panel) 200 14642 [main] install 15336 mount_info::conv_to_posix_path: conv_to_ _path (c:\Program Files\PC-Doctor for Windows\services, keep-rel, no-add-sl 171 14813 [main] install 15336 normalize_win32_path: c:\Program Files\P tor for Windows\services = normalize_win32_path (c:\Program Files\PC-Doctor Windows\services) 192 15005 [main] install 15336 mount_info::conv_to_posix_path: /cygdriv rogram Files/PC-Doctor for Windows/services = conv_to_posix_path (c:\Progra es\PC-Doctor for Windows\services) 195 15200 [main] install 15336 mount_info::conv_to_posix_path: conv_to_ _path (c:\matlab\bin\win32, keep-rel, no-add-slash) 154 15354 [main] install 15336 normalize_win32_path: c:\matlab\bin\win3 ormalize_win32_path (c:\matlab\bin\win32) 151 15505 [main] install 15336 mount_info::conv_to_posix_path: /cygdriv atlab/bin/win32 = conv_to_posix_path (c:\matlab\bin\win32) 158 15663 [main] install 15336 mount_info::conv_to_posix_path: conv_to_ _path (c:\Program Files\SSH Communications Security\SSH Secure Shell, keep- no-add-slash) 217 15880 [main] install 15336 normalize_win32_path: c:\Program Files\S mmunications Security\SSH Secure Shell = normalize_win32_path (c:\Program F SSH Communications Security\SSH Secure Shell) 197 16077 [main] install 15336 mount_info::conv_to_posix_path: /cygdriv rogram Files/SSH Communications Security/SSH Secure Shell = conv_to_posix_p c:\Program Files\SSH Communications Security\SSH Secure Shell) 337 16414 [main] install 15336 win_env::add_cache: posix /usr/local/bin /bin:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILITIES:/ ive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbe gdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Progr les/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdrive/c ram Files/SSH Communications Security/SSH Secure Shell 330 16744 [main] install 15336 win_env::add_cache: native PATH=C:\CYGWI \local\bin;C:\CYGWIN\bin;C:\CYGWIN\bin;C:\CYGWIN\usr\X11R6\bin;c:\PROGRAM F THINKPAD\UTILITIES;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem; ogram Files\ATI Technologies\ATI Control Panel;c:\Program Files\PC-Doctor f ndows\services;c:\matlab\bin\win32;c:\Program Files\SSH Communications Secu SSH Secure Shell 328 17072 [main] install 15336 posify: env var converted to PATH=/usr/l bin:/usr/bin:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTI S:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/Syst Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive ogram Files/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cy e/c/Program Files/SSH Communications Security/SSH Secure Shell 373 17445 [main] install 15336 environ_init: 0x10010800: PATH=/usr/loca :/usr/bin:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILIT cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System3 m:/cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/ am Files/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdr /Program Files/SSH Communications Security/SSH Secure Shell 384 17829 [main] install 15336 environ_init: 0x10010698: PATHEXT=.COM;. BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH 195 18024 [main] install 15336 environ_init: 0x100106D8: PKG_CONFIG_PAT r/X11R6/lib/pkgconfig 189 18213 [main] install 15336 environ_init: 0x10010708: PRINTER=Acroba tiller 185 18398 [main] install 15336 environ_init: 0x10010728: PROCESSOR_ARCH URE=x86 184 18582 [main] install 15336 environ_init: 0x10010748: PROCESSOR_IDEN R=x86 Family 6 Model 9 Stepping 5, GenuineIntel 201 18783 [main] install 15336 environ_init: 0x10010790: PROCESSOR_LEVE 155 18938 [main] install 15336 environ_init: 0x100107A8: PROCESSOR_REVI 0905 184 19122 [main] install 15336 environ_init: 0x100107C8: PROGRAMFILES=C gram Files
Re: Qestion about Bash Fork Resource Temporily Unavailable for NS2.28 and NS2.27
Hi, Larry Hall, I run installation again for NS2.28. It stopped with errors: C:\CYGWIN\bin\gcc.exe (62636): *** thread handle not set - 0x00x0, Win32 error 1450 gcc: Internal error: Hangup (program as) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [tkText.o] Error 1 tk8.4.5 make failed! Exiting ... For problems with Tcl/Tk see http://www.scriptics.com and I run strace.ext ./install, I got the following line, m = normalize_win32_path (c:\WINDOWS\System32\Wbem) 156 40878 [main] install 63420 mount_info::conv_to_posix_path: /cygdrive/c/W INDOWS/System32/Wbem = conv_to_posix_path (c:\WINDOWS\System32\Wbem) 161 41039 [main] install 63420 mount_info::conv_to_posix_path: conv_to_posix _path (c:\Program Files\ATI Technologies\ATI Control Panel, keep-rel, no-add-sla sh) 215 41254 [main] install 63420 normalize_win32_path: c:\Program Files\ATI Te chnologies\ATI Control Panel = normalize_win32_path (c:\Program Files\ATI Techno logies\ATI Control Panel) 196 41450 [main] install 63420 mount_info::conv_to_posix_path: /cygdrive/c/P rogram Files/ATI Technologies/ATI Control Panel = conv_to_posix_path (c:\Program Files\ATI Technologies\ATI Control Panel) 200 41650 [main] install 63420 mount_info::conv_to_posix_path: conv_to_posix _path (c:\Program Files\PC-Doctor for Windows\services, keep-rel, no-add-slash) 162 41812 [main] install 63420 normalize_win32_path: c:\Program Files\PC-Doc tor for Windows\services = normalize_win32_path (c:\Program Files\PC-Doctor for Windows\services) 193 42005 [main] install 63420 mount_info::conv_to_posix_path: /cygdrive/c/P rogram Files/PC-Doctor for Windows/services = conv_to_posix_path (c:\Program Fil es\PC-Doctor for Windows\services) 207 42212 [main] install 63420 mount_info::conv_to_posix_path: conv_to_posix _path (c:\matlab\bin\win32, keep-rel, no-add-slash) 153 42365 [main] install 63420 normalize_win32_path: c:\matlab\bin\win32 = n ormalize_win32_path (c:\matlab\bin\win32) 154 42519 [main] install 63420 mount_info::conv_to_posix_path: /cygdrive/c/m atlab/bin/win32 = conv_to_posix_path (c:\matlab\bin\win32) 159 42678 [main] install 63420 mount_info::conv_to_posix_path: conv_to_posix _path (c:\Program Files\SSH Communications Security\SSH Secure Shell, keep-rel, no-add-slash) 190 42868 [main] install 63420 normalize_win32_path: c:\Program Files\SSH Co mmunications Security\SSH Secure Shell = normalize_win32_path (c:\Program Files\ SSH Communications Security\SSH Secure Shell) 198 43066 [main] install 63420 mount_info::conv_to_posix_path: /cygdrive/c/P rogram Files/SSH Communications Security/SSH Secure Shell = conv_to_posix_path ( c:\Program Files\SSH Communications Security\SSH Secure Shell) 344 43410 [main] install 63420 win_env::add_cache: posix /usr/local/bin:/usr /bin:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILITIES:/cygdr ive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cy gdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Program Fi les/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdrive/c/Prog ram Files/SSH Communications Security/SSH Secure Shell 335 43745 [main] install 63420 win_env::add_cache: native PATH=C:\CYGWIN\usr \local\bin;C:\CYGWIN\bin;C:\CYGWIN\bin;C:\CYGWIN\usr\X11R6\bin;c:\PROGRAM FILES\ THINKPAD\UTILITIES;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;c:\Pr ogram Files\ATI Technologies\ATI Control Panel;c:\Program Files\PC-Doctor for Wi ndows\services;c:\matlab\bin\win32;c:\Program Files\SSH Communications Security\ SSH Secure Shell 323 44068 [main] install 63420 posify: env var converted to PATH=/usr/local/ bin:/usr/bin:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILITIE S:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/ Wbem:/cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Pr ogram Files/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdriv e/c/Program Files/SSH Communications Security/SSH Secure Shell 383 44451 [main] install 63420 environ_init: 0x10010818: PATH=/usr/local/bin :/usr/bin:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILITIES:/ cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbe m:/cygdrive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Progr am Files/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdrive/c /Program Files/SSH Communications Security/SSH Secure Shell 380 44831 [main] install 63420 environ_init: 0x100106B0: PATHEXT=.COM;.EXE;. BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH 196 45027 [main] install 63420 environ_init: 0x100106F0: PKG_CONFIG_PATH=/us r/X11R6/lib/pkgconfig 198 45225 [main] install 63420 environ_init: 0x10010720: PRINTER=Acrobat Dis tiller 186 45411 [main] install 63420 environ_init: 0x10010740: PROCESSOR_ARCHITECT URE=x86 186 45597
Re: Qestion about Bash Fork Resource Temporily Unavailable for NS2.28 and NS2.27
Hi, Larry, I reinstall NS2.28 again, it stopped at a different place this time, that is, not at TK installation but at TCLCL installation, * Build Tclcl-1.16 No .configure file found in current directory Continuing with default options... checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... ./configure: line 2538: /usr/bin/sed: Resourc e temporarily unavailable ./configure: line 2542: /usr/bin/rm: Resource temporarily unavailable no ./configure: line 2570: /usr/bin/cat: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable ./configure: line 2574: /usr/bin/cat: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable tclcl-1.16 configuration failed! Exiting ... Please check http://www.isi.edu/nsnam/ns/ns-problems.html for common problems and bug fixes. -- Then, I run strace.exe again, got the following line, You help is appreciated! 152 39317 [main] install 980 normalize_win32_path: c:\WINDOWS = normalize_wi n32_path (c:\WINDOWS) 155 39472 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/WIN DOWS = conv_to_posix_path (c:\WINDOWS) 152 39624 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\WINDOWS\System32\Wbem, keep-rel, no-add-slash) 156 39780 [main] install 980 normalize_win32_path: c:\WINDOWS\System32\Wbem = normalize_win32_path (c:\WINDOWS\System32\Wbem) 155 39935 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/WIN DOWS/System32/Wbem = conv_to_posix_path (c:\WINDOWS\System32\Wbem) 161 40096 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\Program Files\ATI Technologies\ATI Control Panel, keep-rel, no-add-slash ) 189 40285 [main] install 980 normalize_win32_path: c:\Program Files\ATI Tech nologies\ATI Control Panel = normalize_win32_path (c:\Program Files\ATI Technolo gies\ATI Control Panel) 390 40675 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/Pro gram Files/ATI Technologies/ATI Control Panel = conv_to_posix_path (c:\Program F iles\ATI Technologies\ATI Control Panel) 202 40877 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\Program Files\PC-Doctor for Windows\services, keep-rel, no-add-slash) 162 41039 [main] install 980 normalize_win32_path: c:\Program Files\PC-Docto r for Windows\services = normalize_win32_path (c:\Program Files\PC-Doctor for Wi ndows\services) 192 41231 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/Pro gram Files/PC-Doctor for Windows/services = conv_to_posix_path (c:\Program Files \PC-Doctor for Windows\services) 204 41435 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\matlab\bin\win32, keep-rel, no-add-slash) 153 41588 [main] install 980 normalize_win32_path: c:\matlab\bin\win32 = nor malize_win32_path (c:\matlab\bin\win32) 154 41742 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/mat lab/bin/win32 = conv_to_posix_path (c:\matlab\bin\win32) 158 41900 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\Program Files\SSH Communications Security\SSH Secure Shell, keep-rel, no -add-slash) 189 42089 [main] install 980 normalize_win32_path: c:\Program Files\SSH Comm unications Security\SSH Secure Shell = normalize_win32_path (c:\Program Files\SS H Communications Security\SSH Secure Shell) 199 42288 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/Pro gram Files/SSH Communications Security/SSH Secure Shell = conv_to_posix_path (c: \Program Files\SSH Communications Security\SSH Secure Shell) 505 42793 [main] install 980 win_env::add_cache: posix /usr/local/bin:/usr/b in:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILITIES:/cygdriv e/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygd rive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Program File s/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdrive/c/Progra m Files/SSH Communications Security/SSH Secure Shell 336 43129 [main] install 980
Re: Qestion about Bash Fork Resource Temporily Unavailable for NS2.28 and NS2.27
Hi, Larry, I reinstall NS2.28 again, it stopped at a different place this time, that is, not at TK installation but at TCLCL installation, * Build Tclcl-1.16 No .configure file found in current directory Continuing with default options... checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... ./configure: line 2538: /usr/bin/sed: Resourc e temporarily unavailable ./configure: line 2542: /usr/bin/rm: Resource temporarily unavailable no ./configure: line 2570: /usr/bin/cat: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable ./configure: line 2574: /usr/bin/cat: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable ./configure: fork: Resource temporarily unavailable tclcl-1.16 configuration failed! Exiting ... Please check http://www.isi.edu/nsnam/ns/ns-problems.html for common problems and bug fixes. -- Then, I run strace.exe again, got the following line, You help is appreciated! 152 39317 [main] install 980 normalize_win32_path: c:\WINDOWS = normalize_wi n32_path (c:\WINDOWS) 155 39472 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/WIN DOWS = conv_to_posix_path (c:\WINDOWS) 152 39624 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\WINDOWS\System32\Wbem, keep-rel, no-add-slash) 156 39780 [main] install 980 normalize_win32_path: c:\WINDOWS\System32\Wbem = normalize_win32_path (c:\WINDOWS\System32\Wbem) 155 39935 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/WIN DOWS/System32/Wbem = conv_to_posix_path (c:\WINDOWS\System32\Wbem) 161 40096 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\Program Files\ATI Technologies\ATI Control Panel, keep-rel, no-add-slash ) 189 40285 [main] install 980 normalize_win32_path: c:\Program Files\ATI Tech nologies\ATI Control Panel = normalize_win32_path (c:\Program Files\ATI Technolo gies\ATI Control Panel) 390 40675 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/Pro gram Files/ATI Technologies/ATI Control Panel = conv_to_posix_path (c:\Program F iles\ATI Technologies\ATI Control Panel) 202 40877 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\Program Files\PC-Doctor for Windows\services, keep-rel, no-add-slash) 162 41039 [main] install 980 normalize_win32_path: c:\Program Files\PC-Docto r for Windows\services = normalize_win32_path (c:\Program Files\PC-Doctor for Wi ndows\services) 192 41231 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/Pro gram Files/PC-Doctor for Windows/services = conv_to_posix_path (c:\Program Files \PC-Doctor for Windows\services) 204 41435 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\matlab\bin\win32, keep-rel, no-add-slash) 153 41588 [main] install 980 normalize_win32_path: c:\matlab\bin\win32 = nor malize_win32_path (c:\matlab\bin\win32) 154 41742 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/mat lab/bin/win32 = conv_to_posix_path (c:\matlab\bin\win32) 158 41900 [main] install 980 mount_info::conv_to_posix_path: conv_to_posix_p ath (c:\Program Files\SSH Communications Security\SSH Secure Shell, keep-rel, no -add-slash) 189 42089 [main] install 980 normalize_win32_path: c:\Program Files\SSH Comm unications Security\SSH Secure Shell = normalize_win32_path (c:\Program Files\SS H Communications Security\SSH Secure Shell) 199 42288 [main] install 980 mount_info::conv_to_posix_path: /cygdrive/c/Pro gram Files/SSH Communications Security/SSH Secure Shell = conv_to_posix_path (c: \Program Files\SSH Communications Security\SSH Secure Shell) 505 42793 [main] install 980 win_env::add_cache: posix /usr/local/bin:/usr/b in:/usr/bin:/usr/X11R6/bin:/cygdrive/c/PROGRAM FILES/THINKPAD/UTILITIES:/cygdriv e/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygd rive/c/Program Files/ATI Technologies/ATI Control Panel:/cygdrive/c/Program File s/PC-Doctor for Windows/services:/cygdrive/c/matlab/bin/win32:/cygdrive/c/Progra m Files/SSH Communications Security/SSH Secure Shell 336 43129 [main] install 980
Re: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
I'll risk wasting some more precious time (ypurs or mine) adding a Perl stackdump I found in the Mozilla directory where the build failed: ===begin stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610AA95A eax=2F632F65 ebx=0800 ecx=871C9010 edx=871C9000 esi=2F632F65 edi=871C26C8 ebp=0074E998 esp=0074E970 program=C:\CYGWIN\BIN\PERL.EXE, pid 975019, thread main cs=018F ds=0197 es=0197 fs=51EF gs= ss=0197 Stack trace: Frame Function Args 0074E998 610AA95A (, 10140168, 0074E9C8, 6109CD52) 0074E9C8 6104EC66 (871C3640, 102B2EC8, 0074E9F8, 6109CD52) 0074E9F8 610844FF (101401C8, 102B5280, 0074EA28, 101255F0) 0074EA28 10032A1F (101401C8, 102B5AC0, 0074EA58, 6109CD52) 0074EA58 10032A1F (101401C8, 102B5AE0, 0074EA88, 101255F0) 0074EA88 10032A1F (101401C8, 102B5B00, 0074EAB8, 6109CD52) 0074EAB8 10032A1F (101401C8, 102B5B20, 10169050, 101255F0) 0074EAE8 10032A1F (101401C8, 102B5B40, 0074EB18, 6109CD52) 0074EB18 10032A1F (101401C8, 102B5B60, 0074EB48, 6109CD52) 0074EB48 10032A1F (101401C8, 102B5B80, 0074EB78, 101255F0) 0074EB78 10032A1F (101401C8, 102B4FE0, 0074EBA8, 6109CD52) 0074EBA8 10032A1F (101401C8, 102B5BE0, 0074EBD8, 6109CD52) 0074EBD8 10032A1F (101401C8, 102B5C00, , ) 0074EC08 10032A1F (101401C8, 10143CC0, 102DA2A4, 101410B8) 0074ED58 10008053 (101401C8, 00401220, 0012, 61157CB8) 0074ED98 00401146 (0012, 61157CB8, 10140090, ) End of stack trace (more stack frames may be present) end stackdump= This dump was most probably (I'll check it again today) created by this script: http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl (having 570 lines it's too long to copy) Take note that as in the Volker's example the script is supposed to create compressed fuiles using external binary (Cygwin zip in my case): system($zipprog $zipmoveopt -uX ../$jarfile.jar $subargs) == 0 or $err = $? 8; in the Mozilla script I used and $systemcall=$extracmd.'makecab.exe /V3 /F d:/w1/SRC680_m113/instsetoo_native/wntmsci10.pro/OpenOffice/ddf/en-US/openofficeorg1.ddf 21 |'; in Volker's OpenOffice script. So as I believed from the begining, there is a connection. The difference is he gets an (apparent) hang and I get compilation halt (which I called not very precisely a crash). It's cause may be simply Mozilla check better for errors. I'm thinking about creating a simple testcase but it's not easy as the script has so many external variables which values at the moment it is run in the offending directory I simply do not know. Regards, Jacek -- 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: man.conf missing after cygwin upgrade
On Mon, 4 Jul 2005, FischRon.external wrote: After upgrading cygwin to the most recent version, I found that man pages aren't displayed anymore; for example $ man man Warning: cannot open configuration file /usr/share/misc/man.conf That's not good... [snip] Now it does display the man-page, but before this it also writes the aforementioned error message. Sure it would. You're missing a config file, and man can't forgive that. Next I did $ /usr/sbin/makewhatis $ man -k shell Now I get that error message *twice* (but then man -k displays an overview of the available shell commands, as expected). Now I checked /usr/share/misc and found that it has permissions 000. I chmod the permissions to 0777. Also I found that /usr/share/misc is empty, i.e. there is no file man.conf in it. Ah, that could be the reason -- permissions 000 would make the postinstall script fail when copying the man.conf file from its default location. I found that all in a while, a file created under cygwin ends up with permission 000... If you haven't run setup since upgrading man, see if /var/log/setup.log.full has any messages from /etc/postinstall/man.sh. Nothing useful. man.sh is mentioned only once: Installing file cygfile:///etc/postinstall/man.sh man.conf is mentioned in several directories, such as Installing file cygfile:///usr/share/man/pt/man5/man.conf.5 but never in /usr/share/misc (where man is obviously looking for it). The only thing which might look like an error message does not seem related to the man problem: 2005/07/04 12:27:54 zsh 2005/07/04 12:27:54 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/base-files-mketc.sh Unknown system type ; exiting You should re-run /etc/postinstall/man.sh.done I guess you mean: /etc/postinstall/man.sh - there is no file /etc/postinstall/man.sh.done This went very quickly, and it created the file: /etc/postinstall $ man.sh Using the default version of /usr/share/misc/man.conf (/etc/defaults/usr/share/misc/man.conf) /etc/postinstall $ ls -l /usr/share/misc/man.conf -rw-r--r-- 1 fischron mkgroup_l_d 4576 Jul 5 08:46 /usr/share/misc/man.conf and now the error message on invoking man does not appear anymore. Thank you for helping! Now that your /usr/share/misc has better permissions, future man upgrades should work. If I were you, I'd investigate *why* /usr/share/misc ended up with 000 permissions in the first place (it's created by setup.exe using the inherited Windows permissions -- are the ACLs on / too strict?). As far I can tell, they look fine: $ getfacl / # file: / # owner: Administrators # group: mkgroup_l_d user::rwx group::rwx group:SYSTEM:rwx mask:rwx other:rwx default:user:Administrators:rwx default:group:SYSTEM:rwx default:mask:rwx I found that files with permission 000 are sometimes created when we run build scripts via ant. Just in case you are not familiar: ant is a tool for producing applications (used for similar tasks as one would use make), which is used a lot by Java developers. ant is a Java application, but of what I have seen, it uses the cygwin library (because it is platform independent). In most cases, things work fine, but sometimes, certain files are created with 000. We have never found out why this happens, and regularly do a chmod afterwards. Regards, Ronald -- 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: tcsh hangs after updating to cygwin 1.5.7-1. Expires with Out of Memory
Michael Bax bax3.NO at SPAM.bigfoot.com writes: I discovered that my .history file was 53 MB in size! This is with history 1024 savehist(1024 merge) in my .login. wc .history 0 3316299 53060768 .history I've got the same problem with the same symptoms (the only difference - I connect to my cygwin with putty via sshd). Removing/renaming .history file solves the problem. Boris -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
Hi, Using even more of your precious time I re-run the Mozilla suite compilation. This is the final part of the output: make[4]: Entering directory `/cygdrive/d/mozilla_source/mozilla/netwerk/resources' +++ making chrome /cygdrive/d/mozilla_source/mozilla/netwerk/resources = ../../dist/bin/chrome/comm.jar +++ updating chrome ../../dist/bin/chrome/installed-chrome.txt +++ overriding content/necko/contents.rdf adding: content/necko/contents.rdf (stored 0%) Signal 11 make[4]: *** [libs] Error 139 make[4]: Leaving directory `/cygdrive/d/mozilla_source/mozilla/netwerk/resources' Signal 11 is, of course, segmentation fault. BTW, make error 139 indicates that something that was run by 'make' did die with 'segmentation fault' (signal 11; error values above 128 mean that program exited because of a signal, and subtracting 128 from the given error number will give the signal number). [I learned this researching the problem and put it here as a note for myself] I clobbered the Mozilla tree before the build and therefore it is easy to notice that this is the first time that a .jar file is build (there are no other jar files with a recent date). It seems the Cygwin Perl script dies while using Cygwin zip, probably when (after?) closing the jar file as it exists, has the only file it was supposed to pack (contents.rdf) inside, and can be tests as a good zip file. I used make all in the same directory after downgrading to 1.5.17. The result was: make[1]: Entering directory `/cygdrive/d/mozilla_source/mozilla/netwerk/resources' +++ making chrome /cygdrive/d/mozilla_source/mozilla/netwerk/resources = ../../dist/bin/chrome/comm.jar +++ updating chrome ../../dist/bin/chrome/installed-chrome.txt +++ overriding content/necko/contents.rdf updating: content/necko/contents.rdf (stored 0%) make[1]: Leaving directory `/cygdrive/d/mozilla_source/mozilla/netwerk/resources' (that is: identical except for the segmentation fault). I hope that helps. Jacek -- 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: Memory error with PDKSH 5.2.14-3?
On Mon, Jun 06, 2005 at 10:26:26AM -0400, Igor Pechtchanski wrote: On Mon, 6 Jun 2005, Thomas Baker wrote: Just wanted to report that I was seeing error messages such as the following in Korn shell scripts: /home/tbaker/u/bin/urlists[50]: internal error: alloc: freeing memory outside of block (corrupted?) By running the scripts in debug mode (set -x), I found that the problem seemed to occur when declared functions (i.e., declared within the script) were invoked multiple times. The functions would work at first, then stop working -- as if the functions somehow ate up the available memory. Since rolling back from 5.2.14-3 to 5.2.14-2, the problem seems to have gone away. I am not a programmer and do not have time to test this systematically but thought others on this list might want to hear about this. Thanks for the report. However: I have no hope of reproducing this, do I? If it happens again, I'll log my actions more carefully. AFAICS, the few changes from 5.2.14-2 to 5.2.14-3 that could have possibly caused this are the fixes in the autoconf files. I doubt the struct option magic would matter, but it's possible, I guess, though by eyeballing the code the two versions do look functionally equivalent. It would help to have a script that demonstrates the problem. I can't do anything otherwise, sorry... By going back to previous versions I did try to reproduce the problem, but anyway it's working now.. -- even with 5.2.14-3! Thanks, Tom -- Dr. Thomas Baker [EMAIL PROTECTED] SUB - Goettingen State+49-551-39-3883 and University Library +49-30-8109-9027 Papendiek 14, 37073 G?ttingen -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
Chris, It is really strange. It should start immediately when running the script and the whole process lasts about 5 seconds. Using system $systemcall; instead of open (DDF, $systemcall) ... works fine. This also works: $systemcall='\\/c/WINDOWS/system32/makecab.exe /V3 /F ... And this too: $systemcall='/c/WINDOWS/system32/makecab.exe /V3 /F ... HTH, 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
Hi, More test results: I added -d to the Mozilla rule file that runs make-jars.pl (yes, it is definitely this script, see http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl for a copy). This is the output I got main::(/cygdrive/d/mozilla_source/mozilla/config/make-jars.pl:5): 5: my $cygwin_mountprefix = ; DB1 comm.jar: syntax error at (eval 16)[/usr/lib/perl5/5.8/perl5db.pl:628] line 2, near jar: DB2 * content/necko/contents.rdf (content/contents.rdf) Illegal division by zero at (eval 17)[/usr/lib/perl5/5.8/perl5db.pl:628] line 2. DB3 I have no idea whether this helps, as I never used a perl debugger before, or just wastes someone's time. Jacek -- 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: SV: Bug in printf ?
Original Message From: Peter J. Acklam Sent: 30 June 2005 13:13 Dave Korn [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ^^ Peter, please do http://cygwin.com/acronyms#PCYMTNQREAIYR before you get me loaded down with even more spam than I already suffer, thank you! How come 0.125 gets printed as 0.12, and not 1.3? Absolutely, there's a rounding error of some sort. For what it's worth: My Sunblade 100 running Solaris 9 has Solaris' /bin/printf and GNU's printf as /usr/local/bin/printf and both give 0.12, not 0.13. I am quite sure it is the printf returning 0.13 that is buggy. Note that the value 0.125 can be represented exactly with IEEE double precision arithmetic, so inexact representation is not the matter here. Progress report: Stepping through the code at the weekend, I followed the 0.105 case as far down as ldtoa_r, where I observed that although there was code that would round 0.105 up to 0.11 if asked for only two sig.figs, the loop that generates successive digits was coming up with the sequence '0.104.', and because the rounding only looks at one digit beyond the requested s.f., it 'correctly' rounds 0.104 down to 0.10. I say 'correctly' in quotes, because it's the correct way to round 0.104, but it's not in general correct to round a number by truncating it and then rounding the truncated version. That's at least part of the problem. I haven't checked yet whether 0.105 should be an exact representation in fp, but it could also be the case that some accuracy has been lost by the time it arrives there. [ I notice that mingw has a maths library in a subdir called mingwex, and it looks like this is a version of the same code (SLM's cephes lib, but the ldtoa implementation appears to be something that's been added subsequently AFAICT) and would show the same problem, but when you actually compile the testcase with -mno-cygwin the generated exe calls the msvcrt version of printf (which DTRT, and which is the version you'd expect it to call), so I'm not sure why it's there or what it's relevant to. ] 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
Original Message From: Jacek Piskozub Sent: 05 July 2005 10:19 Hi, More test results: I added -d to the Mozilla rule file that runs make-jars.pl (yes, it is definitely this script, see http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl for a copy). [EMAIL PROTECTED] /test/perl wget 'http://lxr.mozilla.org/seamonkey/source/config/make-j ars.pl' --11:28:42-- http://lxr.mozilla.org/seamonkey/source/config/make-jars.pl = `make-jars.pl' Resolving lxr.mozilla.org... 207.126.111.200 Connecting to lxr.mozilla.org[207.126.111.200]:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] [= ] 58,69672.56K/s 11:28:44 (72.56 KB/s) - `make-jars.pl' saved [58696] [EMAIL PROTECTED] /test/perl chmod a+x make-jars.pl [EMAIL PROTECTED] /test/perl ./make-jars.pl ./make-jars.pl: 1: Syntax error: newline unexpected [EMAIL PROTECTED] /test/perl head -5 make-jars.pl !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN html head META NAME=GENERATOR CONTENT=lxr-1998-06-10: http://lxr.linux.no; titleseamonkey/config/make-jars.pl/title [EMAIL PROTECTED] /test/perl 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
Hi, More random ramblings: I tried to debug the script using the ancient print inserting technique. The result was interesting. I can stop the crash from happening by adding a lot of print commands. Does it show it is a timing (race) problem? To make it even more interesting, by adding just one (meaning instead of the many) print command close to the system one I suspect is the culprit, I can reproduce the alledged hang! In fact it is not a hang but a delayed crash. I left the script hanging and after returning to my office found it crashed. Because it crashed in a novel way, I reproduce the output: make[1]: Entering directory `/cygdrive/d/mozilla_source/mozilla/netwerk/resources' +++ making chrome /cygdrive/d/mozilla_source/mozilla/netwerk/resources = ../.. /dist/bin/chrome/comm.jar +++ updating chrome ../../dist/bin/chrome/installed-chrome.txt /cygdrive/d/mozilla_source/mozilla/config/make-jars.pl: Could not get lockfile / cygdrive/d/mozilla_source/mozilla/dist/bin/chrome/installed-chrome.txt.lck. Remove /cygdrive/d/mozilla_source/mozilla/dist/bin/chrome/installed-chrome.txt.l ck to clear up make[1]: *** [libs] Error 255 make[1]: Leaving directory `/cygdrive/d/mozilla_source/mozilla/netwerk/resources' Please take note of the Could not get lockfile part. Cheerio, Jacek -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18 (corection)
Ignore my previous post. I attached the HTMLized version downloaded as a
test of wget :-(
This is the real script.
J.
#!/perl
# make-jars [-f] [-v] [-l] [-x] [-a] [-e] [-d chromeDir] [-s srcdir] [-t
topsrcdir] [-c localedir] [-z zipprog] [-o operating-system] jar.mn
my $cygwin_mountprefix = ;
if ($^O eq cygwin) {
$cygwin_mountprefix = $ENV{CYGDRIVE_MOUNT};
if ($cygwin_mountprefix eq ) {
$cygwin_mountprefix = `mount -p | awk '{ if (/^\\//) { print \$1; exit }
}'`;
if ($cygwin_mountprefix eq ) {
print Cannot determine cygwin mount points. Exiting.\n;
exit(1);
}
}
chomp($cygwin_mountprefix);
# Remove extra ^M caused by using dos-mode line-endings
chop $cygwin_mountprefix if (substr($cygwin_mountprefix, -1, 1) eq \r);
} else {
# we'll be pulling in some stuff from the script directory
require FindBin;
import FindBin;
push @INC, $FindBin::Bin;
}
use strict;
use Getopt::Std;
use Cwd;
use File::stat;
use Time::localtime;
use File::Copy;
use File::Path;
use File::Spec;
use File::Basename;
use IO::File;
use Config;
require mozLock;
import mozLock;
my $objdir = getcwd;
# if there's a --, everything after it goes into $defines. We don't do
# this with the remaining args in @ARGV after the getopts call because
# old versions of Getopt::Std don't understand --.
my $ddindex = 0;
foreach my $arg (@ARGV) {
++$ddindex;
last if ($arg eq --);
}
my $defines = join(' ', @ARGV[ $ddindex .. $#ARGV ]);
getopts(d:s:t:c:f:avlD:o:p:xz:e:);
my $baseFilesDir = .;
if (defined($::opt_s)) {
$baseFilesDir = $::opt_s;
}
my $topSrcDir;
if (defined($::opt_t)) {
$topSrcDir = $::opt_t;
}
my $localeDir;
if (defined($::opt_c)) {
$localeDir = $::opt_c;
}
my $maxCmdline = 4000;
if ($Config{'archname'} =~ /VMS/) {
$maxCmdline = 200;
}
my $chromeDir = .;
if (defined($::opt_d)) {
$chromeDir = $::opt_d;
}
my $verbose = 0;
if (defined($::opt_v)) {
$verbose = 1;
}
my $fileformat = jar;
if (defined($::opt_f)) {
($fileformat = $::opt_f) =~ tr/A-Z/a-z/;
}
if ($fileformat ne jar
$fileformat ne flat
$fileformat ne symlink
$fileformat ne both) {
print File format specified by -f option must be one of: jar, flat, both,
or symlink.\n;
exit(1);
}
my $zipmoveopt = ;
if ($fileformat eq jar) {
$zipmoveopt = -m -0;
}
if ($fileformat eq both) {
$zipmoveopt = -0;
}
my $nofilelocks = 0;
if (defined($::opt_l)) {
$nofilelocks = 1;
}
my $autoreg = 1;
if (defined($::opt_a)) {
$autoreg = 0;
}
my $useExtensionManifest = 0;
if (defined($::opt_e)) {
$useExtensionManifest = 1;
}
my $preprocessor = ;
if (defined($::opt_p)) {
$preprocessor = $::opt_p;
}
my $force_x11 = 0;
if (defined($::opt_x)) {
$force_x11 = 1;
}
my $zipprog = $ENV{ZIP};
if (defined($::opt_z)) {
$zipprog = $::opt_z;
}
if ($zipprog eq ) {
print A valid zip program must be given via the -z option or the ZIP
environment variable. Exiting.\n;
exit(1);
}
my $force_os;
if (defined($::opt_o)) {
$force_os = $::opt_o;
}
if ($verbose) {
print make-jars
. -v -d $chromeDir
. -z $zipprog
. ($fileformat ? -f $fileformat : )
. ($nofilelocks ? -l : )
. ($baseFilesDir ? -s $baseFilesDir : )
. \n;
}
my $win32 = ($^O =~ /((MS)?win32)|msys|cygwin|os2/i) ? 1 : 0;
my $macos = ($^O =~ /MacOS|darwin/i) ? 1 : 0;
my $unix = !($win32 || $macos) ? 1 : 0;
my $vms = ($^O =~ /VMS/i) ? 1 : 0;
if ($force_x11) {
$win32 = 0;
$macos = 0;
$unix = 1;
}
if (defined($force_os)) {
$win32 = 0;
$macos = 0;
$unix = 0;
if ($force_os eq WINNT) {
$win32 = 1;
} elsif ($force_os eq OS2) {
$win32 = 1;
} elsif ($force_os eq Darwin) {
$macos = 1;
} else {
$unix = 1;
}
}
sub foreignPlatformFile
{
my ($jarfile) = @_;
if (!$win32 index($jarfile, -win) != -1) {
return 1;
}
if (!$unix index($jarfile, -unix) != -1) {
return 1;
}
if (!$macos index($jarfile, -mac) != -1) {
return 1;
}
return 0;
}
sub zipErrorCheck($$)
{
my ($err,$lockfile) = @_;
return if ($err == 0 || $err == 12);
mozUnlock($lockfile) if (!$nofilelocks);
die (Error invoking zip: $err);
}
sub JarIt
{
my ($destPath, $jarfile, $args, $overrides) = @_;
my $oldDir = cwd();
chdir($destPath/$jarfile);
if ($fileformat eq flat || $fileformat eq symlink) {
unlink(../$jarfile.jar) if ( -e ../$jarfile.jar);
chdir($oldDir);
return 0;
}
#print cd $destPath/$jarfile\n;
my $lockfile = ../$jarfile.lck;
mozLock($lockfile) if (!$nofilelocks);
if (!($args eq )) {
my $cwd = getcwd;
my $err = 0;
#print $zipprog $zipmoveopt -uX ../$jarfile.jar $args\n;
# Handle posix cmdline limits
while (length($args) $maxCmdline) {
#print Exceeding POSIX cmdline limit: . length($args) . \n;
my $subargs = substr($args,
RE: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18 (corection)
Original Message From: Jacek Piskozub Sent: 05 July 2005 12:09 Ignore my previous post. I attached the HTMLized version downloaded as a test of wget :-( This is the real script. J. [EMAIL PROTECTED] /test/perl ./make-jars.pl : bad interpreter: No such file or directory [EMAIL PROTECTED] /test/perl write ./make-jars.pl [ changed shebang to /bin/perl ] [EMAIL PROTECTED] /test/perl d2u make-jars.pl make-jars.pl: done. [EMAIL PROTECTED] /test/perl ./make-jars.pl Can't locate mozLock.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin /usr/l ib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /u sr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/ vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at ./make-jars.pl line 37. [EMAIL PROTECTED] /test/perl 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18 (mozLock)
Dave,
Can't locate mozLock.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin
Find it attached.
Chris will probably kill me when he wakes up :-(
J.
#
# * BEGIN LICENSE BLOCK *
# Version: MPL 1.1/GPL 2.0/LGPL 2.1
#
# The contents of this file are subject to the Mozilla Public License Version
# 1.1 (the License); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
# http://www.mozilla.org/MPL/
#
# Software distributed under the License is distributed on an AS IS basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
# for the specific language governing rights and limitations under the
# License.
#
# The Original Code is mozilla.org code.
#
# The Initial Developer of the Original Code is
# Netscape Communications Corporation.
# Portions created by the Initial Developer are Copyright (C) 2001
# the Initial Developer. All Rights Reserved.
#
# Contributor(s):
# Christopher Seawood [EMAIL PROTECTED]
#
# Alternatively, the contents of this file may be used under the terms of
# either of the GNU General Public License Version 2 or later (the GPL),
# or the GNU Lesser General Public License Version 2.1 or later (the LGPL),
# in which case the provisions of the GPL or the LGPL are applicable instead
# of those above. If you wish to allow use of your version of this file only
# under the terms of either the GPL or the LGPL, and not to allow others to
# use your version of this file under the terms of the MPL, indicate your
# decision by deleting the provisions above and replace them with the notice
# and other provisions required by the GPL or the LGPL. If you do not delete
# the provisions above, a recipient may use your version of this file under
# the terms of any one of the MPL, the GPL or the LGPL.
#
# * END LICENSE BLOCK *
package mozLock;
use strict;
use IO::File;
use Cwd;
BEGIN {
use Exporter ();
use vars qw ($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
$VERSION = 1.00;
@ISA = qw(Exporter);
@EXPORT = qw(mozLock mozUnlock);
%EXPORT_TAGS = ( );
@EXPORT_OK = qw();
}
my $lockcounter = 0;
my $locklimit = 100;
my $locksleep = 0.1;
my %lockhash;
# File::Spec-rel2abs appears to be broken in ActiveState Perl 5.22
# so roll our own
sub priv_abspath($) {
my ($file) = @_;
my ($dir, $out);
my (@inlist, @outlist);
# Force files to have unix paths.
$file =~ s/\\/\//g;
# Check if file is already absolute
if ($file =~ m/^\// || substr($file, 1, 1) eq ':') {
return $file;
}
$out = cwd . /$file;
# Do what File::Spec-canonpath should do
@inlist = split(/\//, $out);
foreach $dir (@inlist) {
if ($dir eq '..') {
pop @outlist;
} else {
push @outlist, $dir;
}
}
$out = join '/',@outlist;
return $out;
}
sub mozLock($) {
my ($inlockfile) = @_;
my ($lockhandle, $lockfile);
$lockfile = priv_abspath($inlockfile);
#print LOCK: $lockfile\n;
$lockcounter = 0;
$lockhandle = new IO::File || die Could not create filehandle for
$lockfile: $!\n;
while ($lockcounter $locklimit) {
if (! -e $lockfile) {
open($lockhandle, $lockfile) || die $lockfile: $!\n;
$lockhash{$lockfile} = $lockhandle;
last;
}
$lockcounter++;
select(undef,undef,undef, $locksleep);
}
if ($lockcounter = $locklimit) {
undef $lockhandle;
die $0: Could not get lockfile $lockfile.\nRemove $lockfile to clear
up\n;
}
}
sub mozUnlock($) {
my ($inlockfile) = @_;
my ($lockhandle, $lockfile);
#$lockfile = File::Spec-rel2abs($inlockfile);
$lockfile = priv_abspath($inlockfile);
#print UNLOCK: $lockfile\n;
$lockhandle = $lockhash{$lockfile};
if (defined($lockhandle)) {
close($lockhandle);
$lockhash{$lockfile} = undef;
unlink($lockfile);
} else {
print WARNING: $0: lockhandle for $lockfile not defined. Lock may not
be removed.\n;
}
}
END {};
1;
--
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: chmod suddenly ceased to work on old files - AFTER CYGWIN UPDATE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to FischRon.external AT infineon DOT com on 7/4/2005 6:19 AM: And who knows, doing the update may even resolve your issue with chmod Unfortunately, it doesn't. chmod behaves still as before :-( I have enclosed an updated cygcheck log. Because of the upgrade, I now also have the 'stat' command, so here is the output of stat. Note that x is a file where chmod does not work, while y is a good file: $ stat x y File: `x' Size: 4 Blocks: 1 IO Block: 1024 regular file Device: f7h/247dInode: 17462571716233526985 Links: 1 Access: (0700/-rwx--) Uid: (56297/fischron) Gid: (10513/mkgroup_l_d) Access: 2005-06-30 09:09:02.315724000 +0200 Modify: 2004-01-19 07:37:44.274608000 +0100 Change: 2005-07-01 21:34:10.959402000 +0200 File: `y' Size: 4 Blocks: 1 IO Block: 1024 regular file Device: f7h/247dInode: 17462571716233526986 Links: 1 Access: (0600/-rw---) Uid: (56297/fischron) Gid: (10513/mkgroup_l_d) Access: 2005-06-28 09:07:20.109582000 +0200 Modify: 2005-07-04 14:17:51.193425000 +0200 Change: 2005-07-04 14:17:57.559365000 +0200 stat unfortunately does not show ACLs; running `getfacl x y' might provide better information here. C:\cygwin\bin\id.exe output (ntsec) UID: 56297(fischron) GID: 10513(mkgroup_l_d) 544(Administrators) 545(Users) 10513(mkgroup_l_d) Your group files are still out of date. Running mkgroup -l -d /etc/group and mkpasswd -l -d /etc/passwd will help here, and may be part of your problem. 948k 2003/03/18 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2003/3/18 15:20 Cygwin DLL version info: DLL version: 1.3.22 Did setup.exe ask you to reboot your machine, and did you ignore it? You are still running 1.3.22, so the update process hasn't completed yet (windows can't update a file that is currently in use without a reboot. The alternative is to ensure that all cygwin processes, including services, are stopped before you upgrade). 948k 2003/03/18 c:\Program Files\OpenSSH\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0 cygwin1.dll v0.0 ts=2003/3/18 15:20 Are you sure this is the updated cygcheck.out - you've got cygwin listed twice, with a copy still in OpenSSH. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCynxk84KuGfSFAYARApZlAKCoW78oM4gRJNX5hn6XAyj46poriACfVE40 5YFb9wmLFnEdhGv1itKICUY= =o5Qe -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/
Bug with strcat
This code produces an access violation. Commenting out the arr[] it works
fine. Leaving the arr[] and commenting out the strcat works too.
Anyway on a Linux with GCC 3.4.2 it works as it is presented here without
problems
#include stdarg.h
#include stdio.h
#include stdlib.h
#include string.h
int main()
{
int arr[] = {1,2,3,4,5};
char *buf = (char *) malloc (80);
if (buf == ((void *)0))
printf(LKD error: Not enough memory\n);
int a = 20;
{char tempBuffer[80];int bsize;snprintf (tempBuffer,80, Ivan %d, a
);bsize += strlen(tempBuffer) + 1; buf = (char *) realloc (buf, bsize);
strcat(buf, tempBuffer);}
return 0;
}
_
Charla con tus amigos en lÃnea mediante MSN Messenger:
http://messenger.latam.msn.com/
--
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/
Problem installing cygwin - no PATH, mounts, /etc/passwd ...
Hi, I'm having problems installing cygwin onto my PC. This is not the first time I've installed cygwin on this machine, but I wanted to do a clean install, so I deleted my C:\Cygwin directory, removed the icons, and deleted the registry entries, as suggested in the FAQ. I then downloaded the full install package set to a local directory, using setup.exe, and did an install from the local directory. I ran setup, said Install from local directory, selected All Users/Unix mounts, took the default packages and added X-start-menu-icons (and the dependencies this added) and set it going. Once the install was complete, I started the bash shell. I got no message about running mkpasswd, or about my .profile file, or anything - just a prompt. However, none of the Cygwin directories were in my $PATH, my CWD was /usr/bin, no mounts were set up, and generally things weren't working right. Checking the mailing lists, I found message http://sourceware.org/ml/cygwin/2005-04/msg00987.html which describes symptoms just like mine. I checked, and I had installed base-passwd. I also ran mkpasswd -l -c /etc/passwd and mkgroup -l -c /etc/group, but that made no difference that I could see. I have tried an install on my home PC, and this seems to work fine. However, on the PC with the problems, I am logged on as a domain user (with local administrator privileges) and HOMEDRIVE is set to O: (a network drive). I can't easily change these things (I don't have access to the local admin account), unfortunately. I attach the output of cygcheck -s -v -r - I hope I got the right format. I apologise if I've missed an explanation of my issue somewhere - I didn't have a lot of luck searching the mailing list (beyond the message quoted above), probably because I wasn't sure what search terms would help :-( Thanks in advance for any assistance, Paul. ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com Cygwin Configuration Diagnostics Current System Time: Tue Jul 05 14:16:08 2005 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Utils\GnuWin32\bin C:\Utils\Misc\bin C:\Utils\Aspell\bin C:\Apps\Mingw\bin C:\Apps\Emacs\bin C:\Apps\Tcl\bin C:\Apps\Perl\bin\ C:\Apps\Java\bin D:\Oracle\Ora92\bin C:\Program Files\Oracle\jre\1.3.1\bin C:\Program Files\Oracle\jre\1.1.8\bin C:\GEMSTools\USD\bin C:\Apps\MikTeX\miktex\bin C:\Program Files\Systems Internals C:\Apps\GHC\bin C:\Program Files\Symantec\pcAnywhere\ C:\Program Files\Subversion\bin SysDir: C:\WINNT\system32 WinDir: C:\WINNT PWD = `/usr/bin' HOME = `/cygdrive/o' HOMEPATH = `\' APPDATA = `D:\Documents and Settings\uk03306\Application Data' TERM = `cygwin' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel' WINDIR = `C:\WINNT' USERDOMAIN = `UKAO' OS = `Windows_NT' ALLUSERSPROFILE = `D:\Documents and Settings\All Users' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' APR_ICONV_PATH = `C:\Program Files\Subversion\iconv' !:: = `::\' TEMP = `/cygdrive/c/WINNT/TEMP' COMMONPROGRAMFILES = `C:\Program Files\Common Files' USERNAME = `UK03306' WF_RESOURCES = `D:\Oracle\Ora92\WF\RES\WFus.RES' PROCESSOR_LEVEL = `6' SYSTEMDRIVE = `C:' USERPROFILE = `D:\Documents and Settings\uk03306' LOGONSERVER = `\\UKDCA001' PROCESSOR_ARCHITECTURE = `x86' !C: = `C:\Cygwin\bin' SHLVL = `1' USERDNSDOMAIN = `uk.int.atosorigin.com' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' HOMEDRIVE = `O:' PROMPT = `$P$G' COMSPEC = `C:\WINNT\system32\cmd.exe' TMP = `/cygdrive/c/WINNT/TEMP' SYSTEMROOT = `C:\WINNT' PROCESSOR_REVISION = `0806' PROGRAMFILES = `C:\Program Files' HOMESHARE = `\\UKDCM001\UK03306$' NUMBER_OF_PROCESSORS = `1' COMPUTERNAME = `UKDCW5163' _ = `./cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\Cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\Cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\Cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 7569Mb 84% CP CS UN PA FC d: hd NTFS 11499Mb 86%
Re: Bug with strcat
On Jul 5 10:11, Ivan Mari wrote:
This code produces an access violation.
Yep, no wonder.
Commenting out the arr[] it works
fine. Leaving the arr[] and commenting out the strcat works too.
Anyway on a Linux with GCC 3.4.2 it works as it is presented here without
problems
Only coincidentally.
#include stdarg.h
#include stdio.h
#include stdlib.h
#include string.h
int main()
{
int arr[] = {1,2,3,4,5};
char *buf = (char *) malloc (80);
Using malloc does *not* initialize the allocated area to all zero.
if (buf == ((void *)0))
printf(LKD error: Not enough memory\n);
int a = 20;
{char tempBuffer[80];int bsize;snprintf (tempBuffer,80,
^
uninitialized auto variable
Ivan %d, a );bsize += strlen(tempBuffer) + 1; buf = (char *)
realloc
adding a value to an uninitialized auto variable
(buf, bsize); strcat(buf, tempBuffer);}
^^^
Using strcat on an uninitialized buffer
return 0;
}
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.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: Problem installing cygwin - no PATH, mounts, /etc/passwd ...
Original Message From: Paul Moore Sent: 05 July 2005 14:25 Hi, I'm having problems installing cygwin onto my PC. This is not the first time I've installed cygwin on this machine, but I wanted to do a clean install, so I deleted my C:\Cygwin directory, removed the icons, and deleted the registry entries, as suggested in the FAQ. snip Found: C:\Utils\GnuWin32\bin\cat.exe Warning: C:\Cygwin\bin\cat.exe hides C:\Utils\GnuWin32\bin\cat.exe Found: C:\Cygwin\bin\cp.exe Found: C:\Utils\GnuWin32\bin\cp.exe Warning: C:\Cygwin\bin\cp.exe hides C:\Utils\GnuWin32\bin\cp.exe Found: C:\Apps\Mingw\bin\cpp.exe Found: C:\Cygwin\bin\find.exe Found: C:\Utils\GnuWin32\bin\find.exe Warning: C:\Cygwin\bin\find.exe hides C:\Utils\GnuWin32\bin\find.exe Found: C:\Apps\Mingw\bin\gcc.exe Found: C:\Apps\Mingw\bin\gdb.exe Found: C:\Cygwin\bin\grep.exe Found: C:\Utils\GnuWin32\bin\grep.exe Warning: C:\Cygwin\bin\grep.exe hides C:\Utils\GnuWin32\bin\grep.exe Found: C:\Apps\Mingw\bin\ld.exe Found: C:\Cygwin\bin\ls.exe Found: C:\Utils\GnuWin32\bin\ls.exe Warning: C:\Cygwin\bin\ls.exe hides C:\Utils\GnuWin32\bin\ls.exe Not Found: make Found: C:\Cygwin\bin\mv.exe Found: C:\Utils\GnuWin32\bin\mv.exe Warning: C:\Cygwin\bin\mv.exe hides C:\Utils\GnuWin32\bin\mv.exe Found: C:\Cygwin\bin\rm.exe Found: C:\Utils\GnuWin32\bin\rm.exe Warning: C:\Cygwin\bin\rm.exe hides C:\Utils\GnuWin32\bin\rm.exe Found: C:\Cygwin\bin\sed.exe Found: C:\Utils\GnuWin32\bin\sed.exe Warning: C:\Cygwin\bin\sed.exe hides C:\Utils\GnuWin32\bin\sed.exe Not Found: sh Found: C:\Cygwin\bin\tar.exe Found: C:\Utils\GnuWin32\bin\tar.exe Warning: C:\Cygwin\bin\tar.exe hides C:\Utils\GnuWin32\bin\tar.exe snip Shoulda removed the ages-old GnuWin32 install as well, I reckon! All those incorrect versions of command line utilities will have made a hideous botch of running the postinstall scripts, and will mess up the /etc/profile and ~/.bashrc and other startup scripts, and will be interfering with pretty much everything you do when you try to use the cygwin install... 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
On Mon, Jul 04, 2005 at 07:39:39PM -0400, Volker Quetschke wrote: It is a standalone testcase, unfortunately it depends on the absolute path it resides in. To reproduce unpack perlfreeze.zip to d: and then do: $ cd /cygdrive/d/perlfreeze $ ./perltest.pl and see it hang. (In rxvt/bash) I've downloaded this and it does just sit there but I don't know how long I'm supposed to wait. Is it supposed to print a lot of stuff right away? Yes, it's supposed to produce a cab file while reporting what it is doing. I realized that if you press CTRL-c it really starts to build the cab file, but it doesn't produce any screen output. You can uncomment the $extracmd='sleep 1 '; line in the script and see what should happen. Last night's snapshot should fix this problem. http://cygwin.com/snapshots/ 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
On Tue, Jul 05, 2005 at 08:52:25AM +0200, Jacek Piskozub wrote: I'll risk wasting some more precious time (ypurs or mine) adding a Perl stackdump I found in the Mozilla directory where the build failed: ===begin stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610AA95A eax=2F632F65 ebx=0800 ecx=871C9010 edx=871C9000 esi=2F632F65 edi=871C26C8 ebp=0074E998 esp=0074E970 program=C:\CYGWIN\BIN\PERL.EXE, pid 975019, thread main cs=018F ds=0197 es=0197 fs=51EF gs= ss=0197 Stack trace: Frame Function Args 0074E998 610AA95A (, 10140168, 0074E9C8, 6109CD52) 0074E9C8 6104EC66 (871C3640, 102B2EC8, 0074E9F8, 6109CD52) 0074E9F8 610844FF (101401C8, 102B5280, 0074EA28, 101255F0) 0074EA28 10032A1F (101401C8, 102B5AC0, 0074EA58, 6109CD52) 0074EA58 10032A1F (101401C8, 102B5AE0, 0074EA88, 101255F0) 0074EA88 10032A1F (101401C8, 102B5B00, 0074EAB8, 6109CD52) 0074EAB8 10032A1F (101401C8, 102B5B20, 10169050, 101255F0) 0074EAE8 10032A1F (101401C8, 102B5B40, 0074EB18, 6109CD52) 0074EB18 10032A1F (101401C8, 102B5B60, 0074EB48, 6109CD52) 0074EB48 10032A1F (101401C8, 102B5B80, 0074EB78, 101255F0) 0074EB78 10032A1F (101401C8, 102B4FE0, 0074EBA8, 6109CD52) 0074EBA8 10032A1F (101401C8, 102B5BE0, 0074EBD8, 6109CD52) 0074EBD8 10032A1F (101401C8, 102B5C00, , ) 0074EC08 10032A1F (101401C8, 10143CC0, 102DA2A4, 101410B8) 0074ED58 10008053 (101401C8, 00401220, 0012, 61157CB8) 0074ED98 00401146 (0012, 61157CB8, 10140090, ) End of stack trace (more stack frames may be present) end stackdump= This is dying in malloc. That's usually a symptom of a double free. This is, AFAICT, unrelated to Volker's problem since there is no way that my fix from last night would affect a malloc problem. The malloc implementation in perl was updated to the latest version of Doug Lea's malloc so there is a possibility that this is a malloc bug. However, given that the perl on my linux system routinely trips a double free error from my glibc library, my money would be on perl. 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: man.conf missing after cygwin upgrade
Ron, Please make sure your mailer respects the Reply-To: header -- I set it for a reason. There's no need to Cc: me on the messages, as I read the list. On Tue, 5 Jul 2005, FischRon.external wrote: On Mon, 4 Jul 2005, FischRon.external wrote: Now I checked /usr/share/misc and found that it has permissions 000. I chmod the permissions to 0777. Also I found that /usr/share/misc is empty, i.e. there is no file man.conf in it. Ah, that could be the reason -- permissions 000 would make the postinstall script fail when copying the man.conf file from its default location. I found that all in a while, a file created under cygwin ends up with permission 000... This usually indicates wrong directory permissions on higher-level directories. Could you please post the output of getfacl /usr /usr/share /usr/share/misc (seeing as you've already posted the output of getfacl /). If you haven't run setup since upgrading man, see if /var/log/setup.log.full has any messages from /etc/postinstall/man.sh. Nothing useful. man.sh is mentioned only once: Installing file cygfile:///etc/postinstall/man.sh Very weird. So the postinstall script didn't run? man.conf is mentioned in several directories, such as Installing file cygfile:///usr/share/man/pt/man5/man.conf.5 but never in /usr/share/misc (where man is obviously looking for it). Right, because it's copied to /usr/share/misc by the postinstall script (to avoid overwriting user changes, if any). The only thing which might look like an error message does not seem related to the man problem: 2005/07/04 12:27:54 zsh 2005/07/04 12:27:54 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/base-files-mketc.sh Unknown system type ; exiting That's even weirder. What does uname -a show? You should not get that message on Win2k Pro (as your previously attached cygcheck output indicates). You should re-run /etc/postinstall/man.sh.done I guess you mean: /etc/postinstall/man.sh - there is no file /etc/postinstall/man.sh.done No, I meant /etc/postinstall/man.sh.done, since I didn't realize that the postinstall script didn't run. If you still haven't run setup since that fateful man installation (or if you kept a separate copy of it), please post /var/log/setup.log.full to the list -- something weird happened during your install, and, hopefully, the log will show it. This went very quickly, and it created the file: /etc/postinstall $ man.sh Using the default version of /usr/share/misc/man.conf (/etc/defaults/usr/share/misc/man.conf) /etc/postinstall $ ls -l /usr/share/misc/man.conf -rw-r--r-- 1 fischron mkgroup_l_d 4576 Jul 5 08:46 /usr/share/misc/man.conf and now the error message on invoking man does not appear anymore. Thank you for helping! Glad it helped. This still doesn't explain why the postinstall script didn't run, however. Now that your /usr/share/misc has better permissions, future man upgrades should work. If I were you, I'd investigate *why* /usr/share/misc ended up with 000 permissions in the first place (it's created by setup.exe using the inherited Windows permissions -- are the ACLs on / too strict?). As far I can tell, they look fine: $ getfacl / # file: / # owner: Administrators # group: mkgroup_l_d user::rwx group::rwx group:SYSTEM:rwx mask:rwx other:rwx default:user:Administrators:rwx default:group:SYSTEM:rwx default:mask:rwx Hmm, hopefully the Cygwin security experts will chime in here. All I can tell is the fact that the directory is owned by a group, and that you have default permissions, looks suspicious. Does your /etc/passwd contain the Administrators user? I found that files with permission 000 are sometimes created when we run build scripts via ant. Just in case you are not familiar: ant is a tool for producing applications (used for similar tasks as one would use make), which is used a lot by Java developers. ant is a Java application, but of what I have seen, it uses the cygwin library (because it is platform independent). In most cases, things work fine, but sometimes, certain files are created with 000. We have never found out why this happens, and regularly do a chmod afterwards. Must be something on your system -- probably some directory has weird permissions which are inherited. For the record: ant doesn't use any Cygwin libraries, except that the invocation script uses /bin/sh. Once ant is invoked, it's a pure Java application. Files created by Java follow Windows permission inheritance rules. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse...
Re: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
I've downloaded this and it does just sit there but I don't know how long I'm supposed to wait. Is it supposed to print a lot of stuff right away? Yes, it's supposed to produce a cab file while reporting what it is doing. I realized that if you press CTRL-c it really starts to build the cab file, but it doesn't produce any screen output. You can uncomment the $extracmd='sleep 1 '; line in the script and see what should happen. Last night's snapshot should fix this problem. http://cygwin.com/snapshots/ It does, thanks! I'll test it with a complete OpenOffice build tonight. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
RE: Problem installing cygwin - no PATH, mounts, /etc/passwd ...
On Tue, 5 Jul 2005, Dave Korn wrote: Original Message From: Paul Moore Sent: 05 July 2005 14:25 Hi, I'm having problems installing cygwin onto my PC. This is not the first time I've installed cygwin on this machine, but I wanted to do a clean install, so I deleted my C:\Cygwin directory, removed the icons, and deleted the registry entries, as suggested in the FAQ. snip Found: C:\Cygwin\bin\cp.exe Found: C:\Utils\GnuWin32\bin\cp.exe Warning: C:\Cygwin\bin\cp.exe hides C:\Utils\GnuWin32\bin\cp.exe [snip more of the same] Not Found: sh ! snip Shoulda removed the ages-old GnuWin32 install as well, I reckon! All those incorrect versions of command line utilities will have made a hideous botch of running the postinstall scripts, and will mess up the /etc/profile and ~/.bashrc and other startup scripts, and will be interfering with pretty much everything you do when you try to use the cygwin install... I don't see why it should. Setup does prepend the Cygwin /bin and /usr/bin directories to the PATH (see init_run_script in script.cc), so the Cygwin versions should be picked up by the postinstall scripts. I'd be much more concerned about the Not found: sh line above (marked with '!'s). Did the OP unselect ash when installing Cygwin? Since he did Install from Local Directory, was the ash tarball corrupted or missing? 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
On Tue, Jul 05, 2005 at 10:17:28AM -0400, Christopher Faylor wrote: The malloc implementation in perl was updated to the latest version of Doug Lea's malloc so there is a possibility that this is a malloc bug. However, given that the perl on my linux system routinely trips a double free error from my glibc library, my money would be on perl. What perl version (on linux)? Do you have a test case? -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
Yitzchak Scott-Thoennes sthoenna at efn dot org wrote: What perl version (on linux)? Do you have a test case? No, it works fine on Linux. Same script, same Mozilla build, same Perl version (5.8.6). I would bet my money that the fault is on cygwin side, especially as with cygwin 1.5.17, mozilla builds work fine. Funny thing but it seems this cygwin update fried both OpenOffice and Mozilla builds on win32 platform. No, I do not have a test case. I cannot imagine how to create one as adding or substracting print commands from the perl script cures or kill it. It is no simple malloc problem (or at least not only that). Cheerio, Jacek -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
On Tue, 5 Jul 2005, Jacek Piskozub wrote: Yitzchak Scott-Thoennes sthoenna at efn dot org wrote: What perl version (on linux)? Do you have a test case? No, it works fine on Linux. Same script, same Mozilla build, same Perl version (5.8.6). I would bet my money that the fault is on cygwin side, especially as with cygwin 1.5.17, mozilla builds work fine. Either that, or some change in Cygwin tickled a bug in Perl that hasn't manifested on either Linux or prior Cygwin versions. Funny thing but it seems this cygwin update fried both OpenOffice and Mozilla builds on win32 platform. Both of which use Perl extensively and in large-scale builds? No, I do not have a test case. I cannot imagine how to create one as adding or substracting print commands from the perl script cures or kill it. It is no simple malloc problem (or at least not only that). Well, malloc problems are like this -- any change in memory behavior (such as adding print commands, which may do allocation in Perl) will affect the outcome. Linux, for example, is notorious for zeroing malloc'ed data, and keeping free()d blocks around, which allows many buggy programs to work. 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: Exiting Emacs (Attn: emacs maintainer)
[EMAIL PROTECTED] wrote: On Sat, 2 Jul 2005, Nick Kirchner wrote: I just installed Cygwin on my Windows 98 computer and tried playing around with Emacs. Having toyed with it a little in the past, I know that C-x C-c is supposed to exit the program. As you may have guessed, C-x C-c did nothing other than beep. What exactly is going wrong here? As mentioned in the announcement (http://cygwin.com/ml/cygwin-announce/2004-04/msg0.html), you need to have tty in your CYGWIN environment variable. This needs to be set *before* the shell is started, so good places would be /Cygwin.bat or the system environment (i.e., don't do this in shell startup files). Does this apply to using (X)Emacs under X? David Masterson -- 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: Exiting Emacs (Attn: User's Guide maintainer)
On Tue, 5 Jul 2005, David Masterson wrote: [EMAIL PROTECTED] wrote: http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. On Sat, 2 Jul 2005, Nick Kirchner wrote: I just installed Cygwin on my Windows 98 computer and tried playing around with Emacs. Having toyed with it a little in the past, I know that C-x C-c is supposed to exit the program. As you may have guessed, C-x C-c did nothing other than beep. What exactly is going wrong here? As mentioned in the announcement (http://cygwin.com/ml/cygwin-announce/2004-04/msg0.html), you need to have tty in your CYGWIN environment variable. This needs to be set *before* the shell is started, so good places would be /Cygwin.bat or the system environment (i.e., don't do this in shell startup files). Does this apply to using (X)Emacs under X? Good question. No, it doesn't. As should be described in the User's Guide[1], the 'tty' setting in $CYGWIN serves only to compensate for the deficiencies of the Windows console terminal handling (Ctrl-C and NUL). If emacs is invoked in any terminal other than the cmd.exe console (e.g., rxvt, or xterm), no special settings are needed. Neither does this apply to windowed modes of emacs, which do their own keyboard input handling. Igor [1] http://cygwin.com/cygwin-ug-net/using-cygwinenv.html -- 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! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
On Tue, Jul 05, 2005 at 07:59:32AM -0700, Yitzchak Scott-Thoennes wrote: On Tue, Jul 05, 2005 at 10:17:28AM -0400, Christopher Faylor wrote: The malloc implementation in perl was updated to the latest version of Doug Lea's malloc so there is a possibility that this is a malloc bug. However, given that the perl on my linux system routinely trips a double free error from my glibc library, my money would be on perl. What perl version (on linux)? Do you have a test case? I used to predictably get it any time I ran 'perl -de 0' so I suspected that it had something to to with Perl::ReadLine or Perl::ReadKey, i.e., http://gentoo-portage.com/dev-lang/perl/bugs I can't trip it regularly anymore after the above update but I am fairly certain that I see it every so often at random times. I really wasn't thinking of this as fodder for a cygwin problem when it happened so I wasn't paying too much attention. OTOH, I could be wrong, since I just noticed YA update for malloc. It doesn't seem like the changes in malloc 2.8.2 would have fixed this problem but a new version of cygwin1.dll is available, regardless. 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18
On Tue, Jul 05, 2005 at 12:52:49PM -0400, Christopher Faylor wrote: On Tue, Jul 05, 2005 at 07:59:32AM -0700, Yitzchak Scott-Thoennes wrote: On Tue, Jul 05, 2005 at 10:17:28AM -0400, Christopher Faylor wrote: The malloc implementation in perl was updated to the latest version of Doug Lea's malloc so there is a possibility that this is a malloc bug. However, given that the perl on my linux system routinely trips a double free error from my glibc library, my money would be on perl. What perl version (on linux)? Do you have a test case? I used to predictably get it any time I ran 'perl -de 0' so I suspected that it had something to to with Perl::ReadLine or Perl::ReadKey, i.e., http://gentoo-portage.com/dev-lang/perl/bugs I can't trip it regularly anymore after the above update but I am fairly certain that I see it every so often at random times. I really wasn't thinking of this as fodder for a cygwin problem when it happened so I wasn't paying too much attention. OTOH, I could be wrong, since I just noticed YA update for malloc. It doesn't seem like the changes in malloc 2.8.2 would have fixed this problem but a new version of cygwin1.dll is available, regardless. Specifically at: http://cygwin.com/snapshots/ . 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: tcsh hangs after updating to cygwin 1.5.7-1. Expires with Out of Memory
At 04:02 AM 7/5/2005, you wrote: Michael Bax bax3.NO at SPAM.bigfoot.com writes: I discovered that my .history file was 53 MB in size! This is with history 1024 savehist(1024 merge) in my .login. wc .history 0 3316299 53060768 .history I've got the same problem with the same symptoms (the only difference - I connect to my cygwin with putty via sshd). Removing/renaming .history file solves the problem. OK. Please read and follow the problem reporting guidelines at the link below if you'd like to have someone on the list review your issue. Problem reports: http://cygwin.com/problems.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Subversion depends on crypt
Mikael Eriksson wrote: Not sure if this is the right list, I do hope so. Please also cc me since I'm not subscribed. When installing subversion via setup.exe, crypt is not installed. Therefore the message cygcrypt-0.dll could not be found is displayed when I run svn.exe Actually subversion depends on libaprutil0 which depends on crypt. Dependency inserted, thanks for the report. Max. -- 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/
Path Statement Not Being Evaluated by Bash in Cygwin
I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin. I have installed the additional packages needed for KDE 3.4 and I even did a complete re-install of all packages to ensure that I have a clean system. when I start bash and enter 'echo $path'. This is the path statement returned. C:\cygwinbash bash-2.05b$ pwd / bash-2.05b$ echo $path /usr/bin:/usr/X11R6/bin:/opt/qt/3.3/bin:/cygdrive/c/PROGRA~1/COMMON~1/GTK/2.0/bi n:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/ Wbem:/cygdrive/c/Program Files/Support Tools/:/cygdrive/c/Program Files/Microsof t Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/bin:/usr/bin:/cygdrive/c/Program Files/Microsoft Platform SDK/Include:/cygd rive/c/Program Files/Microsoft Platform SDK/Bin:/cygdrive/c/Program Files/Micros oft Visual Studio 8/VC/lib:/cygdrive/e/livemedia-unix2/live/testProgs:/cygdrive/ c/Program Files/OpenVPN/bin:. When I run my startup script for KDE. bash-2.05b$ cd home bash-2.05b$ cd Ross MacGillivray bash-2.05b$ ls startkde bash-2.05b$ cat startkde usr/bin/echo $path usr/sbin/cygserver export CYGWIN=server export DISPLAY=127.0.0.1:0 usr/X11R6/bin/XWin -multiwindow usr/X11R6/bin/xwinclip usr/X11R6/bin/xhost + export SHELL=/bin/bash opt/kde3.4/bin/kdeinit +kicker I get two windows error messages report that two dll's cannot be found. The dll's are: cygX11-6.dll and cyggt-mt-3.dll. One DLL is in /usr/X11R6/bin and one DLL is in /opt/qt/3.3/bin Both paths are in the path statement above. What's going on here? /Ross MacGillivray -- 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: Freeze in perl script after cygwin upgrade 1.5.17 - 1.5.18 (mozLock)
Jacek Piskozub wrote: Dave, Can't locate mozLock.pm in @INC (@INC contains: /usr/lib/perl5/5.8/cygwin Find it attached. Chris will probably kill me when he wakes up :-( Lol. 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/
Load a shared library using gcc/Cygwin
Hi,
main.c below is for loading the shared library module.dll
/* command to create main.exe
cl -c main.c
link main.obj
*/
#include stdio.h
#include windows.h
int main(){
void *handle;
int (*fp)();
char *modname = ./module.dll;
HMODULE h;
void (*init)();
printf(hello1\n);
h = LoadLibrary(cygwin1.dll);
printf(hello1 h = %p\n, h);
init = ( void (*)())GetProcAddress(h, cygwin_dll_init);
printf(init = %p\n, init);
init(); // CRASH HERE...!!!
printf(hello2\n);
handle = LoadLibrary(modname);
printf(hello2 handle = %p\n, handle);
if (handle == NULL) {
fprintf(stderr, Can't load %s in LoadLibrary()\n, modname);
exit(1);
}
fp = ( int (*)())GetProcAddress(handle, foo);
if (fp== NULL) {
fprintf(stderr, ERROR: GetProcAddress()\n);
exit(1);
}
printf(ok1\n);
fp();
printf(ok2\n);
FreeLibrary(handle);
}
module.c below is the source code for creating module.dll
/* command to create
gcc -shared -o module.dll module.c
*/
#include stdio.h
#include windows.h
/*
__declspec(dllexport)
*/
int foo(int arg){
printf(foo() called\n);
return (arg * 2);
}
Makefile is for creating main.exe and module.dll
CC = cl
LINK = link
#CFLAGS = /MD
CFLAGS =
all: main.exe module.dll
main.exe: main.obj
$(LINK) main.obj
main.obj: main.c
$(CC) $(CFLAGS) -c main.c
module.dll: module.o
gcc -shared -o module.dll module.c
#gcc -shared -o module.dll module.o
module.o: module.c
gcc -c module.c
clean:
rm *.obj *.dll *.exe *.lib *.exp *.o main.exe.stackdump
I followed the instructions from FAQ to load a shared library.
But the program main.exe crashed at the line init() highlighted in the
main.c
How can I fix the problem?
Thanks
--
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/
cygcheck exit status
It is annoying that cygcheck exits with status 0, even if it could not find a file: $ cygcheck /bin/lilypond.exe C:/cygwin/bin/lilypond.exe C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL C:/cygwin/bin\cygguile-12.dll C:/cygwin/bin\cygcrypt-0.dll C:/cygwin/bin\cygguile-ltdl-1.dll C:/cygwin/bin\cygintl-3.dll C:/cygwin/bin\cygiconv-2.dll Error: could not find cygkpathsea-4.dll $ echo $? 0 $ cygcheck none Error: could not find none $ echo $? 0 This makes exit status worthless when trying to use cygcheck to verify if an existing file has any broken dependencies (a la the bash upgrade scenarios being discussed on cygwin-apps). I tried to prepare a patch, but returning EXIT_FAILURE from main() still produced a 0 exit status, so it might be that the magic that makes cygcheck know about cygwin1.dll while still being a Windows app needs fixing, too. -- 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: Problem installing cygwin - no PATH, mounts, /etc/passwd ...
Igor Pechtchanski [EMAIL PROTECTED] writes: On Tue, 5 Jul 2005, Dave Korn wrote: [...] Found: C:\Cygwin\bin\cp.exe Found: C:\Utils\GnuWin32\bin\cp.exe Warning: C:\Cygwin\bin\cp.exe hides C:\Utils\GnuWin32\bin\cp.exe [snip more of the same] Not Found: sh ! snip Shoulda removed the ages-old GnuWin32 install as well, I reckon! All those incorrect versions of command line utilities will have made a hideous botch of running the postinstall scripts, and will mess up the /etc/profile and ~/.bashrc and other startup scripts, and will be interfering with pretty much everything you do when you try to use the cygwin install... Hmm, I could be offended by that :-) The GnuWin32 stuff is not ages-old, it's right up to date. Also, I have it on my other machine at home (which worked) so I don't see how it could be the issue. And finally, as Igor mentions below, my reading of the output is that the cygwin stuff overrides the GnuWin32 stuff, so that the existence of GnuWin32 shouldn't affect it. Nevertheless, I did try removing GnuWin32 (removed it from PATH, and temporarily renamed the directory as well), but it made no difference. Thanks for the suggestion, though. I don't see why it should. Setup does prepend the Cygwin /bin and /usr/bin directories to the PATH (see init_run_script in script.cc), so the Cygwin versions should be picked up by the postinstall scripts. I'd be much more concerned about the Not found: sh line above (marked with '!'s). Did the OP unselect ash when installing Cygwin? Since he did Install from Local Directory, was the ash tarball corrupted or missing? *That's* the problem. For some reason, my local directory wasn't complete. I could swear that when I downloaded it, setup.exe completed without any warnings or error messages, but obviously something went wrong. Whatever it was, when I did a reinstall from the net plus the local cache, everything worked fine. Thanks very much for taking the time to diagnose what turned out to be dumb user error. Paul. -- This signature intentionally left blank -- 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: Path Statement Not Being Evaluated by Bash in Cygwin
Ross MacGillivray wrote: I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin. I have installed the additional packages needed for KDE 3.4 and I even did a complete re-install of all packages to ensure that I have a clean system. when I start bash and enter 'echo $path'. This is the path statement returned. C:\cygwinbash bash-2.05b$ pwd / bash-2.05b$ echo $path /usr/bin:/usr/X11R6/bin:/opt/qt/3.3/bin:/cygdrive/c/PROGRA~1/C OMMON~1/GTK/2.0/bi n:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c /WINDOWS/System32/ Wbem:/cygdrive/c/Program Files/Support Tools/:/cygdrive/c/Program Files/Microsof t Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/bin:/usr/bin:/cygdrive/c/Program Files/Microsoft Platform SDK/Include:/cygd rive/c/Program Files/Microsoft Platform SDK/Bin:/cygdrive/c/Program Files/Micros oft Visual Studio 8/VC/lib:/cygdrive/e/livemedia-unix2/live/testProgs:/cygdrive/ c/Program Files/OpenVPN/bin:. When I run my startup script for KDE. bash-2.05b$ cd home bash-2.05b$ cd Ross MacGillivray bash-2.05b$ ls startkde bash-2.05b$ cat startkde usr/bin/echo $path usr/sbin/cygserver export CYGWIN=server export DISPLAY=127.0.0.1:0 usr/X11R6/bin/XWin -multiwindow usr/X11R6/bin/xwinclip usr/X11R6/bin/xhost + export SHELL=/bin/bash opt/kde3.4/bin/kdeinit +kicker I get two windows error messages report that two dll's cannot be found. The dll's are: cygX11-6.dll and cyggt-mt-3.dll. One DLL is in /usr/X11R6/bin and one DLL is in /opt/qt/3.3/bin Both paths are in the path statement above. What's going on here? /Ross MacGillivray Not sure how you've got things setup, but `echo $path` should result in an empty return statement. the variable is PATH not path, case sensitive. reid -- 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/
problem with strtoimax?
The release notes for 1.5.18 state that strtoimax was added. But compare
the output of the following:
$ uname -a
CYGWIN_NT-5.0 eblake 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown
Cygwin
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
printf(%lld\n, strtoimax(1, NULL, 0));
return 0;
}
$ gcc -o foo foo.c
/cygdrive/c/DOCUME~1/eblake/LOCALS~1/Temp/ccQLtRpQ.o:foo.c:(.text+0x42):
undefined reference to `_strtoimax'
collect2: ld returned 1 exit status
$ gcc -o foo -mno-cygwin foo.c
$ ./foo
1
Also, there is a bug with strtoll (which cygwin.din claims should be the base
of strtoimax):
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
printf(%llx\n, strtoll(1, NULL, 10));
return 0;
}
$ gcc -o foo foo.c
$ ./foo
a0001
$ gcc -o foo -mno-cygwin foo.c
$ ./foo
1
--
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: Path Statement Not Being Evaluated by Bash in Cygwin
when I start bash and enter 'echo $path'. This is the path statement returned. Not sure how you've got things setup, but `echo $path` should result in an empty return statement. the variable is PATH not path, case sensitive. Or maybe you are thinking of tcsh syntax, where $path is a space-separated synonym for the colon-separated $PATH. tcsh syntax doesn't work in bash (hopefully, it is obvious why not), and your listing had colons, so even if you were to use tcsh with that $path you would have problems. -- Eric Blake cygwin bash maintainer -- 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: cygcheck exit status
On Tue, Jul 05, 2005 at 07:25:04PM +, Eric Blake wrote: It is annoying that cygcheck exits with status 0, even if it could not find a file: $ cygcheck /bin/lilypond.exe C:/cygwin/bin/lilypond.exe C:/cygwin/bin\cygwin1.dll C:\WINNT\system32\ADVAPI32.DLL C:\WINNT\system32\NTDLL.DLL C:\WINNT\system32\KERNEL32.DLL C:\WINNT\system32\RPCRT4.DLL C:/cygwin/bin\cygguile-12.dll C:/cygwin/bin\cygcrypt-0.dll C:/cygwin/bin\cygguile-ltdl-1.dll C:/cygwin/bin\cygintl-3.dll C:/cygwin/bin\cygiconv-2.dll Error: could not find cygkpathsea-4.dll $ echo $? 0 $ cygcheck none Error: could not find none $ echo $? 0 This makes exit status worthless when trying to use cygcheck to verify if an existing file has any broken dependencies (a la the bash upgrade scenarios being discussed on cygwin-apps). I tried to prepare a patch, but returning EXIT_FAILURE from main() still produced a 0 exit status, so it might be that the magic that makes cygcheck know about cygwin1.dll while still being a Windows app needs fixing, too. This should be fixed in the current snapshot. 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: problem with strtoimax?
On Tue, Jul 05, 2005 at 08:26:26PM +, Eric Blake wrote:
The release notes for 1.5.18 state that strtoimax was added. But compare
the output of the following:
$ uname -a
CYGWIN_NT-5.0 eblake 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown
Cygwin
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
printf(%lld\n, strtoimax(1, NULL, 0));
return 0;
}
$ gcc -o foo foo.c
/cygdrive/c/DOCUME~1/eblake/LOCALS~1/Temp/ccQLtRpQ.o:foo.c:(.text+0x42):
undefined reference to `_strtoimax'
collect2: ld returned 1 exit status
WJFFM. It seems like you have an outdated libcygwin.a.
$ gcc -o foo -mno-cygwin foo.c
$ ./foo
1
Also, there is a bug with strtoll (which cygwin.din claims should be the base
of strtoimax):
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
printf(%llx\n, strtoll(1, NULL, 10));
return 0;
}
$ gcc -o foo foo.c
$ ./foo
a0001
This, I can confirm. PTC.
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: chmod suddenly ceased to work on old files - AFTER CYGWIN UPDATE
On 05/07/05, FischRon wrote: Actually I wasn't able to use -d with mkpasswd, because this command hung, so I did a mkpasswd -l /etc/passwd instead. Maybe I should rerun mkgroup -l (without -d option)? Really hung, or just taking a very very long time (it will, if it is a large domain)? If the latter, you could try using the -c and/or -u options to mkpasswd to only get the information for a subset of the users (ie just the ones who use your machine). Or construct the /etc/passwd file by hand if you know what you're doing But in any case, recreating the /etc/group file did nothing to remedy my problem. What kind of server are these files on? If it is a SAMBA share (on eg linux, as opposed to a SMB share from WinNT), then maybe this message is helpful: http://www.cygwin.com/ml/cygwin/2000-12/msg00567.html Otherwise if it is an SMB share, maybe you need to give your accounts (both locally and on the server) the restore files and directories (SeRestorePrivilege) privilege, which may not be practical as its a security hole. Though from reading the mailing list archives it seems that so long as the machines are part of a domain and your user account is a domain account, then this is supposed to be unnecessary. Finally, you could always set the CYGWIN environment variable to include 'nosmbntsec' to switch off all use of ntsec on shares. Lev -- 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: Path Statement Not Being Evaluated by Bash in Cygwin
Ross MacGillivray ross_macgillivray at yahoo.ca writes: I am trying to test KDE 3.4 (and Qt 3.3) on Cygwin. I have installed the additional packages needed for KDE 3.4 and I even did a complete re-install of all packages to ensure that I have a clean system. when I start bash and enter 'echo $path'. This is the path statement returned. C:\cygwinbash bash-2.05b$ pwd / bash-2.05b$ echo $path /usr/bin:/usr/X11R6/bin:/opt/qt/3.3/bin:/cygdrive/c/PROGRA~1/COMMON~1/GTK/2.0 snip When I run my startup script for KDE. snip I get two windows error messages report that two dll's cannot be found. The dll's are: cygX11-6.dll and cyggt-mt-3.dll. One DLL is in /usr/X11R6/bin and one DLL is in /opt/qt/3.3/bin Both paths are in the path statement above. What's going on here? /Ross MacGillivray Thank you for the two quick replies. I had the following line in .bashrc path=/usr/bin:/usr/X11R6/bin:/opt/qt/3.3/bin:$PATH (note the small letters at the beginning of the statement - CAPITALS ROSS, CAPITALS!) Anyway, thank you for the help. /Ross -- 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: problem with strtoimax?
On Tue, Jul 05, 2005 at 08:26:26PM +, Eric Blake wrote: $ gcc -o foo foo.c /cygdrive/c/DOCUME~1/eblake/LOCALS~1/Temp/ccQLtRpQ.o:foo.c:(.text+0x42): undefined reference to `_strtoimax' collect2: ld returned 1 exit status WJFFM. It seems like you have an outdated libcygwin.a. Weird: $ ll /usr/lib/libcygwin.a /usr/i686-pc-cygwin/lib/libcygwin.a -rwxrwxrwx 1 Administrators Domain Users 3704450 Feb 24 07:29 /usr/i686-pc-cygwin/lib/libcygwin.a* -rwxrwxrwx 1 eblake Users 956656 Jul 2 18:30 /usr/lib/libcygwin.a* I don't recall ever touching /usr/i686-pc-cygwin/lib. Maybe when I played with installing a build from CVS? Is that directory normally present, or should I just nuke it? But gcc -v revealed that it does indeed do -L/usr/i6866-pc-cygwin/lib before -L/usr/lib. -- 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: problem with strtoimax?
$ cat foo.c
#include stdio.h
#include inttypes.h
int main(int argc, char**argv)
{
printf(%llx\n, strtoll(1, NULL, 10));
return 0;
}
$ gcc -o foo foo.c
$ ./foo
a0001
This, I can confirm. PTC.
No patch necessary (PEBCAK). strtoimax is in inttypes.h, but strtoll
is in stdlib.h. Compiling with -Wall would have shown my stupidity.
(Hint - implicit prototypes return int, but strtoll really needs to return
long long.)
--
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: Load a shared library using gcc/Cygwin
Yu-Cheng Chou wrote:
int main(){
void *handle;
int (*fp)();
char *modname = ./module.dll;
HMODULE h;
void (*init)();
printf(hello1\n);
h = LoadLibrary(cygwin1.dll);
printf(hello1 h = %p\n, h);
init = ( void (*)())GetProcAddress(h, cygwin_dll_init);
printf(init = %p\n, init);
init(); // CRASH HERE...!!!
Of course it crashes, you aren't doing anything to address the fact that
the bottom CYGTLS_PADSIZE bytes of the stack will be clobbered by
Cygwin's tls structure. This is mentioned in the FAQ and explained
further in how-cygtls-works.txt and the cygload sample. In a Cygwin
program, this is handled for you automatically by the startup code, but
not so if your program is compiled with VC++ and uses its runtime.
This means you have to add the necessary scratch space to the stack, as
low on the stack as possible after the entry to main(). But the
arguments to main() as well as its return location will already be on
the stack (as well as whatever arbitrary values the MSVCRT chooses to
put there) which means they will be clobbered as well. You can work
around this by making copies of the arguments and not returning from
main(). Or you can save the state of the stack pre-clobbering and then
restore it before returning from main(), as cygload does.
I followed the instructions from FAQ to load a shared library.
But the program main.exe crashed at the line init() highlighted in the
main.c
How can I fix the problem?
Go back and read the FAQ again and make sure you understand it all.
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: Gdb and stopping at assert or segmentation faults
Hi all Dave Korn dave.korn at artimi.com writes: Anyway, break __assert works for catching the assertions. Dunno what's up with the SEGVs. well, it turns out Dave's suggestion doesn't work anymore on latest cygwin (tested this only with C++ programs): GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) In fact, it will now break before entering main(), but not when the assert is called. Using break __assert says (gdb) break __assert Breakpoint 1 at 0x4ac3e6: file /usr/lib/gcc/i686-pc- cygwin/3.4.4/include/c++/iostream, line 77. (gdb) r Starting program: /home/kris/MyDocuments/mytest.exe Breakpoint 1, __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77 (gdb) c assertion overlap-epsilon failed: file ./include/stir/numerics/overlap_interpolate.inl, line 108 Program exited normally. Any other suggestions? Thanks Kris -- 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/
ssh problems
(If this is not the right place for this, please direct me.) I have recently updated an old Windows setup, including a new cygwing installation. We use this machine for nightly builds, using a shell script that connects to multiple machines and runs the builds (DevStudio in the Windows case). With the new cygwin these builds stopped with a mysterious error -- about 5 hours later I know that the problem is with sshd and some permission problems. After a brief look at http://www.cygwin.com/cygwin-ug-net/ntsec.html, I tried moving my .ssh away so I have to type a password, and indeed the build works fine. So it looks like devstudio is doing something that requires some permissions that I don't get unless I physically type a password. Is there any way to solve this? I've been trying to play with things like ssh-host-config and stuff in the global CYGWIN, but nothing seem to be making it work. TIA, -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! -- 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: Please try latest snapshot -- pthreads mutex users please note
Hi Chris, I've done a clean install of cygwin with dll 1.5.18 and also tried snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to threading and memory leaks as described in the following post - still exists: http://sources.redhat.com/ml/cygwin/2005-06/msg00186.html Regards Arash Partow __ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net We're coming close to a 1.5.18 release. Please try the latest snapshot at http://cygwin.com/snapshots/ and help verify that there are no regresions against 1.5.17. I'm particularly interested in hearing if the changes made (at users's requests) to the default mutex handling in pthread.h are working correctly. Specifically, does this: Index: include/pthread.h === RCS file: /cvs/uberbaum/winsup/cygwin/include/pthread.h,v retrieving revision 1.21 retrieving revision 1.23 diff -u -d -1 -r1.21 -r1.23 --- include/pthread.h 2 May 2005 03:50:09 - 1.21 +++ include/pthread.h 11 Jun 2005 04:56:36 - 1.23 @@ -55,3 +55,3 @@ #define PTHREAD_MUTEX_NORMAL 2 -#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK +#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL /* this should be too low to ever be a valid address */ do what was requested? This simple change required a lot of changes in the cygwin test suite so I'm not entirely convinced that it was a good thing yet. 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/ -- 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: ssh problems
At 08:45 PM 7/5/2005, you wrote: (If this is not the right place for this, please direct me.) I have recently updated an old Windows setup, including a new cygwing installation. We use this machine for nightly builds, using a shell script that connects to multiple machines and runs the builds (DevStudio in the Windows case). With the new cygwin these builds stopped with a mysterious error -- about 5 hours later I know that the problem is with sshd and some permission problems. After a brief look at http://www.cygwin.com/cygwin-ug-net/ntsec.html, I tried moving my .ssh away so I have to type a password, and indeed the build works fine. So it looks like devstudio is doing something that requires some permissions that I don't get unless I physically type a password. Is there any way to solve this? I've been trying to play with things like ssh-host-config and stuff in the global CYGWIN, but nothing seem to be making it work. You'll need to figure out what that something is that DevStudio is doing. Sounds to me like you're trying to access a network drive which requires authentication but that's just a WAG. But, if you think that's it, see: Why don't my services work (or access network shares)? http://cygwin.com/faq/faq_3.html#SEC33 -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Qestion about Bash Fork Resource Temporily Unavailable for NS2.28 and NS2.27
At 02:05 AM 7/5/2005, Question NS wrote: While I install NS2.28, it tells no gcc, but I actually installed gcc, and during the installation, it said my gcc is not a cross compile, I don't know if this is matter. And if it is, which gcc version shall I install? I ran the strace.exe command, get the following lines, Thank you for support. I look forward to your reply. OK, it appears that I have not been very clear with my previous response. Let me see if I can rectify that. I mentioned strace as one possible avenue to finding the source of the Resource temporarily unavailable message and perhaps some context. But I intended that to be a hopefully helpful option for you to explore on your end and *perhaps* report some digested portion to the list. There's really little value to dumping the output of strace into a mail message and sending it to the list, especially with little or no context. Also, in case we're not connecting on what constitutes a simple, small example, NS 2.28 does not fit that definition in my view, if you were thinking it might. If you can come up with an example of perhaps a few hundred lines of code or something similar, that might qualify. But I'm probably not going to download the 57MB or so of source to try to see if I can reproduce your problem and I expect others on this list would be similarly reluctant. As I expect you're aware (since you're far more familiar with NS than I am, having been introduced to it by you), there is a zip of binaries built for Cygwin that you can download and use directly: http://www.isi.edu/nsnam/dist/binary/ns-allinone-2.28-cygwin-binaries.zip But, presuming you do want to build from source rather than use pre-built binaries, I can offer one other suggestion. You've related 3 different errors, in 4 separate messages today, that may or may not have Cygwin as the least common denominator. So let me ask, do you have any virus program running? If so, you may want to try disabling it and perform your build without it. It could be causing you these difficulties too. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: ssh problems
On Jul 5, Larry Hall wrote: At 08:45 PM 7/5/2005, you wrote: (If this is not the right place for this, please direct me.) I have recently updated an old Windows setup, including a new cygwing installation. We use this machine for nightly builds, using a shell script that connects to multiple machines and runs the builds (DevStudio in the Windows case). With the new cygwin these builds stopped with a mysterious error -- about 5 hours later I know that the problem is with sshd and some permission problems. After a brief look at http://www.cygwin.com/cygwin-ug-net/ntsec.html, I tried moving my .ssh away so I have to type a password, and indeed the build works fine. So it looks like devstudio is doing something that requires some permissions that I don't get unless I physically type a password. Is there any way to solve this? I've been trying to play with things like ssh-host-config and stuff in the global CYGWIN, but nothing seem to be making it work. You'll need to figure out what that something is that DevStudio is doing. Is there any way to finding this? The most information I got was from the Event Viewer: Application popup: Microsoft Visual C++ Runtime Library : Runtime Error! Program: ...Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Sounds to me like you're trying to access a network drive which requires authentication but that's just a WAG. But, if you think that's it, see: Why don't my services work (or access network shares)? http://cygwin.com/faq/faq_3.html#SEC33 This did sound like something similar, but it doesn't look like it's the problem. My script doesn't use any shares, and in case DevStudio does something funny I disconnected the only mapped share I had. Don't know what a WAG is, and the above faq entry didn't help... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://www.barzilay.org/ Maze is Life! -- 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: Please try latest snapshot -- pthreads mutex users please note
Hi Chris, Actually things are getting slightly worse, basically same test scenario (not the full blown app you keep on mentioning), but this time mutex locks are failing + the ye-olde massive memory leaks. I have the mutex set to default mode, and after a few seconds of the test running mutexes locking unlocking, all of a sudden the mutexes stop locking, and basically report back EBUSY from pthread_mutex_lock. I know you weren't going to bother looking into it, but seeing as though you made a general request for testing updates relating to the new dll version, I thought it useful and relevant to put in my two cents. maybe in the future I wont even do that... Regards Arash Partow __ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net On Wed, Jul 06, 2005 at 01:36:54AM +, Arash Partow wrote: I've done a clean install of cygwin with dll 1.5.18 and also tried snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to threading and memory leaks as described in the following post - still exists: http://sources.redhat.com/ml/cygwin/2005-06/msg00186.html Right. I made no effort to fix anything since, I'm not going to try to debug a 308K application for alleged memory leaks and, AFAIK, Corinna didn't look into this either. I guess I implied that previously but didn't make that clear. You can assume that unless someone mentions that they've fixed some kind of memory leak issue, there will be no improvement in the situation that you've noted so, there's not need to send it still doesn't work mail here. OTOH, if things get better or worse that is interesting and worthy of raising a flag. 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/ -- 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: Please try latest snapshot -- pthreads mutex users please note
On Wed, Jul 06, 2005 at 04:17:34AM +, Arash Partow wrote: I have the mutex set to default mode, and after a few seconds of the test running mutexes locking unlocking, all of a sudden the mutexes stop locking, and basically report back EBUSY from pthread_mutex_lock. The message that you are replying to mentions a change in the behavior of default mutexes which was made to make cygwin jive with linux. I know you weren't going to bother looking into it, but seeing as though you made a general request for testing updates relating to the new dll version, I thought it useful and relevant to put in my two cents. maybe in the future I wont even do that... Hmm. If you want to send a still broken message every time I ask people to check a snapshot, please feel free. I was trying to tell you when and how it would be useful for you to report problems so that you wouldn't have to bother sending email which was basically a no-op. It's your choice, of course, as to when and how often you choose to send messages but I thought that delineating what was useful and what wasn't would be helpful. 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: Please try latest snapshot -- pthreads mutex users please note
Arash Partow wrote:
I've done a clean install of cygwin with dll 1.5.18 and also tried
snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to
threading and memory leaks as described in the following post - still
exists:
http://sources.redhat.com/ml/cygwin/2005-06/msg00186.html
I don't believe this is a valid test case. It has a severe memory leak,
that's definite. But it does the exact same thing under Linux:
$ ./example1 /dev/null thepid=$! ; while cat /proc/$thepid/stat | awk
'{ print $24*4 }'; do sleep 3; done [1] 1310
1088
61820
136244
206468
0
[1]+ Bus error ./example1 /dev/null
cat: /proc/1310/stat: No such file or directory
This runs the program and prints its RSS in Kbytes every three seconds.
As you can see it very quickly consumes all memory and crashes to a
halt. Whatever this problem is, I do not think it's related to Cygwin
in any way, except for the fact that it takes much longer under Cygwin
to exhaust all memory due to the slower pthread locking compared to
Linux.
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/
