Re: RFU: ocaml-3.12.1-1
On 2011-12-21, at 04:20, Yaakov (Cygwin/X) wrote: On Tue, 2011-12-20 at 23:20 +0100, Damien Doligez wrote: On 2011-12-19, at 17:04, Corinna Vinschen wrote: Did you see Yaakov's mail on the cygwin list: http://cygwin.com/ml/cygwin/2011-12/msg00350.html I guess i'd prefer to pull the packages and wait for new ones, together with the new hint files. Yes. I'm almost done debugging this problem. The configuration was wrong because (apparently) the configure script behaves randomly :-( I'll also add the changes suggested by Yaakov. I'll upload a new version within 2 days. Did you see my follow-up on the main list? http://cygwin.com/ml/cygwin/2011-12/msg00397.html Yes, yes. We're down to one change now. -- Damien
RFU: ocaml-3.12.1-2
Please upload: wget -x -nH --cut-dirs=2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/emacs-ocaml/emacs-ocaml-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/emacs-ocaml/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-3.12.1-2-src.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-base/ocaml-base-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-base/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-camlp4/ocaml-camlp4-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-camlp4/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-compiler-libs/ocaml-compiler-libs-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-compiler-libs/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/setup.hint Keep 3.12.0-4 as the old version and delete 3.12.1-1 This version has Yaakov's patch included and is correctly configured (I hope!) Thanks, -- Damien
Re: RFU: ocaml-3.12.1-2
On Dec 21 16:26, Damien Doligez wrote: Please upload: wget -x -nH --cut-dirs=2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/emacs-ocaml/emacs-ocaml-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/emacs-ocaml/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-3.12.1-2-src.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-base/ocaml-base-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-base/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-camlp4/ocaml-camlp4-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-camlp4/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-compiler-libs/ocaml-compiler-libs-3.12.1-2.tar.bz2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-compiler-libs/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/setup.hint Keep 3.12.0-4 as the old version and delete 3.12.1-1 Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH 0/2] Make setup -q -P work as expected
On 13/08/2011 15:44, Jon TURNEY wrote:
On 13/08/2011 08:51, Corinna Vinschen wrote:
On Jul 22 14:22, Jon TURNEY wrote:
I'm somewhat reluctant to mess with this code as it is rather convoluted,
so these
patches could probably use some careful review and/or testing.
But these patches attempt to make setup -q -P work more like the naive
expectation [1]
of just installing the specified package, rather than installing the
specified package
and upgrading all currently installed packages to the current version.
Note that setup -q -L -P [2] probably sill doesn't work as expected, I'm
guessing
that without the benefit of a setup.ini, all packages found in the local
package dir
are placed in one of the special categories 'Base' or 'Misc' and thus
always installed.
[1] http://cygwin.com/ml/cygwin-xfree/2011-07/msg00041.html
[2] http://cygwin.com/ml/cygwin/2011-07/msg00308.html
Jon TURNEY (2):
Push the implementation of defaultTrust() down from the PickView
class to packagedb class
When packages are selected on the command line in unattended mode,
just install those packages
PickView.cc | 28
choose.cc | 30 --
package_db.cc | 43 ++-
package_db.h |5 +
4 files changed, 79 insertions(+), 27 deletions(-)
are you planning to follow up on this? If you're happy with your
changes, feel free to check them in, regardless of my comment.
Patches applied.
It appears that I didn't test this enough, as setup -q -P doesn't actually
work correctly after these changes [1] :-(
Attached patch should make it work again.
2011-12-21 Jon TURNEY jon.tur...@dronecode.org.uk
* choose.cc (OnInit): Properly mark packages which were selected on
command line in unattended mode for download and installation.
[1] http://cygwin.com/ml/cygwin/2011-12/msg00449.html
Index: choose.cc
===
RCS file: /cvs/cygwin-apps/setup/choose.cc,v
retrieving revision 2.160
diff -u -r2.160 choose.cc
--- choose.cc 13 Aug 2011 14:43:31 - 2.160
+++ choose.cc 21 Dec 2011 23:10:20 -
@@ -264,6 +264,7 @@
|| pkg.categories.find (Misc) != pkg.categories.end ())
{
pkg.desired = pkg.trustp(TRUST_CURR);
+ pkg.desired.pick(TRUE, pkg);
}
}
}
Re: [PATCH 0/2] Make setup -q -P work as expected
On Wed, Dec 21, 2011 at 11:12:44PM +, Jon TURNEY wrote: On 13/08/2011 15:44, Jon TURNEY wrote: On 13/08/2011 08:51, Corinna Vinschen wrote: On Jul 22 14:22, Jon TURNEY wrote: I'm somewhat reluctant to mess with this code as it is rather convoluted, so these patches could probably use some careful review and/or testing. But these patches attempt to make setup -q -P work more like the naive expectation [1] of just installing the specified package, rather than installing the specified package and upgrading all currently installed packages to the current version. Note that setup -q -L -P [2] probably sill doesn't work as expected, I'm guessing that without the benefit of a setup.ini, all packages found in the local package dir are placed in one of the special categories 'Base' or 'Misc' and thus always installed. [1] http://cygwin.com/ml/cygwin-xfree/2011-07/msg00041.html [2] http://cygwin.com/ml/cygwin/2011-07/msg00308.html Jon TURNEY (2): Push the implementation of defaultTrust() down from the PickView class to packagedb class When packages are selected on the command line in unattended mode, just install those packages PickView.cc | 28 choose.cc | 30 -- package_db.cc | 43 ++- package_db.h |5 + 4 files changed, 79 insertions(+), 27 deletions(-) are you planning to follow up on this? If you're happy with your changes, feel free to check them in, regardless of my comment. Patches applied. It appears that I didn't test this enough, as setup -q -P doesn't actually work correctly after these changes [1] :-( Attached patch should make it work again. 2011-12-21 Jon TURNEY jon.tur...@dronecode.org.uk * choose.cc (OnInit): Properly mark packages which were selected on command line in unattended mode for download and installation. [1] http://cygwin.com/ml/cygwin/2011-12/msg00449.html Thanks, Jon. Please check in. cgf
New Account Alert From GlobalPay
Dear GlobalPay customer, in order to maintain your account status active, you have to update your information. Please download your attached personal login page and login to your account to continue. Global Payments. 2011 $onlinevt: C7B5MUYRHNU4G6ZZRFBUGFWC0J5SUH3V5A1JHK81P4QATHTCA8F0K7NZBVBT5 onlinevtW87HPBW2.html Description: html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog dcrt0.cc wow64.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-12-21 17:19:49 Modified files: winsup/cygwin : ChangeLog dcrt0.cc wow64.cc Log message: * dcrt0.cc (_dll_crt0): Rephrase comments. Set $ebp to NULL, as in the pthread stack setup. * wow64.cc (wow64_revert_to_original_stack): Rephrase some comments. Return _tlsbase-16 rather than _main_tls-4 so as not to waste stack. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5638r2=1.5639 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dcrt0.cc.diff?cvsroot=srcr1=1.421r2=1.422 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wow64.cc.diff?cvsroot=srcr1=1.5r2=1.6
winsup/cygwin fhandler.cc ChangeLog
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-12-21 18:34:58 Modified files: cygwin : fhandler.cc ChangeLog Log message: * fhandler.cc (fhandler_base_overlapped::wait_overlapped): Use correct value in switch statement. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler.cc.diff?cvsroot=uberbaumr1=1.420r2=1.421 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5639r2=1.5640
re: 1.7.9: Installing error: fonts and X-start-menu-icons
Sigh... I thought I had things working, but... the more I used it, the more I'm realizing that all of my woes are because I was trying to install it on a Samba share. I have done the same thing on my local hard drive (which doesn't have much space, which is why I was trying to install it on the network drive), and I've had no issues. What I found is that pretty much everything was screwed up in subtle and bizarre ways: from the PATH variable not even being followed properly (the Windows find was being used even though /usr/bin was in the PATH before /cygdrive/c/WINDOWS/system32), to constant problems with execute permissions. Funny enough, I was able to get the X Server running and did manage to run an xterm and xcalc, although I didn't attempt to run anything else before turning back to some basics. In short, kindly disregard my long report... I don't think it has anything to do with the Cygwin installation, and a lot to do with interaction with Samba's view of the world. I suspect that it could eventually be made to work (turn on xattrs and acls on the filesystems for instance), but it's not worth the effort at this time to labour through it. I'll find the space necessary on my local drive ;). Sorry to trouble. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
where is libffi?
I can’t build my program using gtk+-2.0 on cygwin development environment (gcc-3.4.4, etc.). The error message from linker is, /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find ?lffi Actually, there exists /usr/bin/cygffi-4 but I can’t find /usr/lib/libffi*. I’m wondering if this is caused by something like bug in cygwin-setup program. Thanks. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On Dec 20 17:45, Brian Ford wrote: I'm just headed home from work right now, but I thought I would let you know of a regression from 1.7.9. It appears the effect of this patch: http://www.cygwin.com/ml/cygwin-cvs/2004-q2/msg00124.html is no longer working in the current snapshot. I'll try to narrow it down to which change caused the regression and send in an STC tomorrow. Is that the first Cygwin process started from a 64 bit process on 64 bit XP or 2003? If so, see the new wow64_revert_to_original_stack function in wow64.cc and the wow64 code in _dll_crt0. I don't see how any other change could have this effect. But I also don't see how this could occur with the patch. Basically, what happens is this: newbase = some 64K aligned address on the stack _main_tls = newbase - CYGTLS_PADSIZE (== 12700) $ebp = $esp = _main_tls - 4 So, assuming newbase == 0x1 == _main_tls == 0xce64 == $ebp/$esp == 0xce60, which is certainly a 16 byte aligned value. But OTOH I have to admit that I don't see how this alignment business worked at all. Aligning the stack to 16 byte in mainCRTStartup doesn't guarantee that the stack is still 16 byte aligned in main(). If that worked so far, it seems like a miracle. The call stack looks like this: mainCRTStartup - cygwin_crt0 - _dll_crt0 - _main_tls-call - _main_tls-call2 - dll_crt0_1 - main Every function on the stack changes the stack pointer. How did that work? Coincidence? And then again, isn't it gcc's job to make sure that the generated code makes sure the stack is correctly aligned for certain opcodes? What am I missing? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: where is libffi?
On 12/21/2011 10:32 AM, yoichi.niitsu wrote: I can’t build my program using gtk+-2.0 on cygwin development environment (gcc-3.4.4, etc.). The error message from linker is, /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find ?lffi Actually, there exists /usr/bin/cygffi-4 but I can’t find /usr/lib/libffi*. I’m wondering if this is caused by something like bug in cygwin-setup program. Thanks. Hi Yoichi, using the package search at http://cygwin.com/packages/ the outcome http://cygwin.com/cgi-bin2/package-grep.cgi?grep=libffi suggest me 2 things: - install libffi4 - replace obsolete gcc (version 3) with gcc4 package as usr/lib/gcc/i686-pc-cygwin/4.5.3/libffi.a is part of gcc4-core Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On Dec 21 10:42, Corinna Vinschen wrote: On Dec 20 17:45, Brian Ford wrote: I'm just headed home from work right now, but I thought I would let you know of a regression from 1.7.9. It appears the effect of this patch: http://www.cygwin.com/ml/cygwin-cvs/2004-q2/msg00124.html is no longer working in the current snapshot. I'll try to narrow it down to which change caused the regression and send in an STC tomorrow. Is that the first Cygwin process started from a 64 bit process on 64 bit XP or 2003? If so, see the new wow64_revert_to_original_stack function in wow64.cc and the wow64 code in _dll_crt0. I don't see how any other change could have this effect. But I also don't see how this could occur with the patch. Basically, what happens is this: newbase = some 64K aligned address on the stack _main_tls = newbase - CYGTLS_PADSIZE (== 12700) $ebp = $esp = _main_tls - 4 So, assuming newbase == 0x1 == _main_tls == 0xce64 == $ebp/$esp == 0xce60, which is certainly a 16 byte aligned value. But OTOH I have to admit that I don't see how this alignment business worked at all. Aligning the stack to 16 byte in mainCRTStartup doesn't guarantee that the stack is still 16 byte aligned in main(). If that worked so far, it seems like a miracle. The call stack looks like this: mainCRTStartup - cygwin_crt0 - _dll_crt0 - _main_tls-call - _main_tls-call2 - dll_crt0_1 - main Every function on the stack changes the stack pointer. How did that work? Coincidence? And then again, isn't it gcc's job to make sure that the generated code makes sure the stack is correctly aligned for certain opcodes? What am I missing? On second thought I'm a bit puzzled that you refer to the patch which tries to align the patch of the main thread while your subject talks about pthreads. If you mean the stack alignment of subsequently started pthreads, then the culprit might be the changes I made to allow application-provided stacks. See the CygwinCreateThread and thread_wrapper functions in miscfuncs.cc. Does something like the below work for you? Even though I don't see how this is supposed to work if an arg and the return address, 8 bytes, are pushed onto the stack afterwards. In theory the wrapper would have to subtract another 8 bytes after the alignment. I still think gcc has to care for this alignment in the first place. Index: miscfuncs.cc === RCS file: /cvs/src/src/winsup/cygwin/miscfuncs.cc,v retrieving revision 1.75 diff -u -p -r1.75 miscfuncs.cc --- miscfuncs.cc17 Dec 2011 23:39:46 - 1.75 +++ miscfuncs.cc21 Dec 2011 10:41:19 - @@ -524,6 +524,7 @@ thread_wrapper (VOID *arg) subl %[CYGTLS], %%ebx # Subtract CYGTLS_PADSIZE \n\ subl $4, %%ebx # Subtract another 4 bytes\n\ movl %%ebx, %%esp # Set esp \n\ + andl $-16, %%esp # 16 bit align stack \n\ xorl %%ebp, %%ebp # Set ebp to 0\n\ # Now we moved to the new stack. Save thread func address\n\ # and thread arg on new stack \n\ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.9: Installing error: fonts and X-start-menu-icons
Greetings, James Botte! (the Windows find was being used even though /usr/bin was in the PATH before /cygdrive/c/WINDOWS/system32), This is what you get when you're using Cygwin tools from windows shell (CMD). (Or so I assume.) to constant problems with execute permissions. Funny enough, I was able to get the X Server running and did manage to run an xterm and xcalc, although I didn't attempt to run anything else before turning back to some basics. When you have issues with execute bit, you are likely looking at shell script. Try starting it using /bin/sh /path/to/script In short, kindly disregard my long report... I don't think it has anything to do with the Cygwin installation, and a lot to do with interaction with Samba's view of the world. Samba's view is very flexible. You just have to know how to cook it :P I suspect that it could eventually be made to work (turn on xattrs and acls on the filesystems for instance), Pretty much this. -- WBR, Andrey Repin (anrdae...@freemail.ru) 21.12.2011, 16:26 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FAQ 4.2 Why is Cygwin suddenly so slow?
My Cygwin installation use about 1 s per shell command. For example: $ time env HOMEPATH=\Docume ... COMPUTERNAME=MES real0m1.075s user0m0.030s sys 0m0.015s $ time time Usage: time [-apvV] [-f format] [-o file] [--append] [--verbose] [--portability] [--format=format] [--output=file] [--version] [--help] command [arg...] real0m1.033s user0m0.030s sys 0m0.030s It is evident to me, that the command is immediately executed at the right speed, then a second is spent before return back to the shell prompt. Happen with those shell: - bash - xterm - mintty Script execution is very slow. I tried some of the suggested solutions found googling: - deinstalled bash completion - set the path to /bin only - stopping all unnecessary Windows services no difference. I also tried to completely remove Cygwin and reinstall 1.7.9. Same results. Other suggestions? What other check I must do? thank you in advance, Valerio -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FAQ 4.2 Why is Cygwin suddenly so slow?
On 12/21/2011 1:43 PM, e...@iol.it wrote: My Cygwin installation use about 1 s per shell command. For example: $ time env HOMEPATH=\Docume ... COMPUTERNAME=MES real0m1.075s user0m0.030s sys 0m0.015s $ time time Usage: time [-apvV] [-f format] [-o file] [--append] [--verbose] [--portability] [--format=format] [--output=file] [--version] [--help] command [arg...] real0m1.033s user0m0.030s sys 0m0.030s It is evident to me, that the command is immediately executed at the right speed, then a second is spent before return back to the shell prompt. Happen with those shell: - bash - xterm - mintty Script execution is very slow. I tried some of the suggested solutions found googling: - deinstalled bash completion - set the path to /bin only - stopping all unnecessary Windows services no difference. I also tried to completely remove Cygwin and reinstall 1.7.9. Same results. Other suggestions? What other check I must do? antivirus ? http://cygwin.com/faq/faq.using.html#faq.using.bloda thank you in advance, Valerio Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FAQ 4.2 Why is Cygwin suddenly so slow?
From: marco.atz...@gmail.com antivirus ? http://cygwin.com/faq/faq.using.html#faq.using.bloda thanks, from this list I had Sophos Anti-Virus installed in the system. It is version 9.5 fully updated and not 7. Anyway I tried to disable its 6 windows services, check the 8 tasks it generate was closed, but same results with Cygwin. As I cannot admin this Sophos installation I cannot disable the scannig of Cygwin root installation. I will try to ask to the admin to add this excetion (low possibility I think). BTW seems strange Sophos interfere only with Cygwin. Valerio -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Sorry people (NOT MY taxonomy!!), but igncr IS flawed
On 19/12/2011 17:35, Andrey Repin wrote: Greetings, Dave Korn! Windows GUI-based archivers are well known for causing this problem. To be fair, you should reduce your reference to WinZIP is known for. At the very least, WinRAR and 7-Zip, both won't try to hold your hand in this case. I don't know about WinACE, though, and I'm not going to check it myself. I haven't checked, but would bet WinRAR and 7-Zip don't accurately recreate the posix permissions when they unpack a *nix tarball. They probably don't unpack device nodes right either. They can probably get softlinks right but I haven't tested that either. Rather than play guessing games about which gui-based unpackers will do a good job of unpacking something into a Cygwin environment and have to repeatedly re-solve the problems they may cause every time someone says Oh, well you said not to use WinZip, so I used WinRAR (or whatever) instead, I just err on the side of caution and simply advise: for unpacking stuff into a Cygwin environment, always use a Cygwin-aware tool. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On 21/12/2011 09:42, Corinna Vinschen wrote: But OTOH I have to admit that I don't see how this alignment business worked at all. Aligning the stack to 16 byte in mainCRTStartup doesn't guarantee that the stack is still 16 byte aligned in main(). If that worked so far, it seems like a miracle. The call stack looks like this: mainCRTStartup - cygwin_crt0 - _dll_crt0 - _main_tls-call - _main_tls-call2 - dll_crt0_1 - main Every function on the stack changes the stack pointer. How did that work? Coincidence? And then again, isn't it gcc's job to make sure that the generated code makes sure the stack is correctly aligned for certain opcodes? What am I missing? GCC assumes that the stack starts off 16-aligned when the OS hands over to the exe's entrypoint, and then makes sure it stays that way by always rounding stack frame sizes up to the nearest multiple of 16. Or at any rate that's how it's supposed to work. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On Dec 21 15:20, Dave Korn wrote: On 21/12/2011 09:42, Corinna Vinschen wrote: But OTOH I have to admit that I don't see how this alignment business worked at all. Aligning the stack to 16 byte in mainCRTStartup doesn't guarantee that the stack is still 16 byte aligned in main(). If that worked so far, it seems like a miracle. The call stack looks like this: mainCRTStartup - cygwin_crt0 - _dll_crt0 - _main_tls-call - _main_tls-call2 - dll_crt0_1 - main Every function on the stack changes the stack pointer. How did that work? Coincidence? And then again, isn't it gcc's job to make sure that the generated code makes sure the stack is correctly aligned for certain opcodes? What am I missing? GCC assumes that the stack starts off 16-aligned when the OS hands over to the exe's entrypoint, and then makes sure it stays that way by always rounding stack frame sizes up to the nearest multiple of 16. Or at any rate that's how it's supposed to work. Ok. Does that mean my patch from http://cygwin.com/ml/cygwin/2011-12/msg00435.html should be the right thing to do for pthreads? I guess I will have to do the same in _dll_crt0 then... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tetex-tiny bug
Jan? Ping? Did you see that mail? On Dec 19 09:52, Peter Rosin wrote: Peter Rosin skrev 2011-11-25 16:48: Hi! It's been a couple of years since I fixed this [1] on my old computer, and now I had to fix it on the new one. Can someone please fix the tetex-tiny package? Below is what I did to fix the problem. Cheers, Peter [1] http://www.cygwin.com/ml/cygwin/2006-05/msg00756.html --- /usr/share/texmf/web2c/fmtutil.cnf.cygwin-dist 2005-05-05 20:54:58.00100 +0200 +++ /usr/share/texmf/web2c/fmtutil.cnf 2011-11-25 16:36:48.748662200 +0100 @@ -41,7 +41,7 @@ textex - -translate-file=cp227.tcx tex.ini aleph aleph - *aleph.ini latex pdfetex language.dat-translate-file=cp227.tcx *latex.ini -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex etexlanguage.def-translate-file=cp227.tcx *etex.ini pdftex pdfetex - -translate-file=cp227.tcx *pdftex.ini pdflatex pdfetex language.dat-translate-file=cp227.tcx *pdflatex.ini pdfetexpdfetex language.def -translate-file=cp227.tcx *pdfetex.ini Next victim [1]. This bug continues to waste time. Cheers, Peter [1] http://lists.gnu.org/archive/html/bug-automake/2011-12/msg00051.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
I'm sorry. I should have learned by now not to post at the last minute before leaving for the day. I always make mistakes and leave out important information. Thanks for considering my problem in spite of these oversights. More below... On Wed, 21 Dec 2011, Corinna Vinschen wrote: On Dec 20 17:45, Brian Ford wrote: I'm just headed home from work right now, but I thought I would let you know of a regression from 1.7.9. It appears the effect of this patch: http://www.cygwin.com/ml/cygwin-cvs/2004-q2/msg00124.html You were correct below that I cited the wrong patch. I simply swiped the wrong URL in a hurry; sorry. This is the correct reference: http://www.cygwin.com/ml/cygwin-cvs/2004-q2/msg00108.html is no longer working in the current snapshot. I'll try to narrow it down to which change caused the regression and send in an STC tomorrow. Is that the first Cygwin process started from a 64 bit process on 64 bit XP or 2003? No; this is 32 bit XP Pro SP3. Most of the rest of this has been cleared up I think, so I'll save any further responses to later messages in the thread. Thanks again for your help. -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On Wed, 21 Dec 2011, Corinna Vinschen wrote: On Dec 21 15:20, Dave Korn wrote: GCC assumes that the stack starts off 16-aligned when the OS hands over to the exe's entrypoint, and then makes sure it stays that way by always rounding stack frame sizes up to the nearest multiple of 16. Or at any rate that's how it's supposed to work. Ok. Does that mean my patch from http://cygwin.com/ml/cygwin/2011-12/msg00435.html should be the right thing to do for pthreads? I guess I will have to do the same in _dll_crt0 then... Probably. I'm trying to test now, but I haven't built cygwin in years now so I'm still working to get things set up. I've also lost track of Cygwin internals. Does it make sense to you that those two patches from 2004 would no longer be effective? -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tetex-tiny bug
On 12/21/2011 4:42 PM, Corinna Vinschen wrote: Jan? Ping? Did you see that mail? On Dec 19 09:52, Peter Rosin wrote: Peter Rosin skrev 2011-11-25 16:48: Hi! It's been a couple of years since I fixed this [1] on my old computer, and now I had to fix it on the new one. Can someone please fix the tetex-tiny package? Below is what I did to fix the problem. Cheers, Peter [1] http://www.cygwin.com/ml/cygwin/2006-05/msg00756.html --- /usr/share/texmf/web2c/fmtutil.cnf.cygwin-dist 2005-05-05 20:54:58.00100 +0200 +++ /usr/share/texmf/web2c/fmtutil.cnf 2011-11-25 16:36:48.748662200 +0100 @@ -41,7 +41,7 @@ textex - -translate-file=cp227.tcx tex.ini aleph aleph - *aleph.ini latex pdfetex language.dat-translate-file=cp227.tcx *latex.ini -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex etexlanguage.def-translate-file=cp227.tcx *etex.ini pdftex pdfetex - -translate-file=cp227.tcx *pdftex.ini pdflatex pdfetex language.dat-translate-file=cp227.tcx *pdflatex.ini pdfetexpdfetex language.def -translate-file=cp227.tcx *pdfetex.ini Next victim [1]. This bug continues to waste time. Cheers, Peter [1] http://lists.gnu.org/archive/html/bug-automake/2011-12/msg00051.html Corinna pdftex seems to have a similar issue. fmtutil.cnf links pdftex to pdfetex and pdftex.ini is built by pdfetex but on /usr/bin pdftex is not a link to pdfetex Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On Dec 21 10:22, Brian Ford wrote: On Wed, 21 Dec 2011, Corinna Vinschen wrote: On Dec 21 15:20, Dave Korn wrote: GCC assumes that the stack starts off 16-aligned when the OS hands over to the exe's entrypoint, and then makes sure it stays that way by always rounding stack frame sizes up to the nearest multiple of 16. Or at any rate that's how it's supposed to work. Ok. Does that mean my patch from http://cygwin.com/ml/cygwin/2011-12/msg00435.html should be the right thing to do for pthreads? I guess I will have to do the same in _dll_crt0 then... Probably. I'm trying to test now, but I haven't built cygwin in years now so I'm still working to get things set up. I've also lost track of Cygwin internals. Does it make sense to you that those two patches from 2004 would no longer be effective? Cygwin now sets up the stack by itself in both cases, WOW64 startup and pthread_create. I just made a test which showed pretty clearly that the 16 byte alignment is required for the WOW64 case. But that case wasn't affected because it was already correctly aligned. On second thought I'm a bit puzzled that the pthread stack isn't correctly aligned as well. Ignoring the pthread_attr_setstack case which wasn't supported so far anyway, the OS stack set up by CreateThread is 64K aligned. From that 64K aligned StackBase value, I subtract 12704 == 0x31a0 bytes. So the result should be 16 byte aligned even without the andl $-16, %%esp. Why isn't it?!? Does anybody care to tell me what's wrong with the assembler code in thread_wrapper? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FAQ 4.2 Why is Cygwin suddenly so slow?
Hello, * On Wed, Dec 21, 2011 at 03:30:11PM +0100 e...@iol.it wrote: From: marco.atz...@gmail.com antivirus ? http://cygwin.com/faq/faq.using.html#faq.using.bloda thanks, from this list I had Sophos Anti-Virus installed in the system. It is version 9.5 fully updated and not 7. [...] As I cannot admin this Sophos installation I cannot disable the scannig of Cygwin root installation. I will try to ask to the admin to add this excetion (low possibility I think). Even worse: In many cases, just adding exceptions is not enough. In many cases, BLODA (especially Antivirus) has to be uninstalled. Although not active in the directory, or even when the services are disabled, many Antivirus software programs still interfere. BTW seems strange Sophos interfere only with Cygwin. Well, the Antivir programs do not only interfere with Cygwin. However, Cygwin is doing some tricks in order to perform its task, and these tricks are more likely to fail with Antivirus programs active. Furthermore, there are some (many?) programs that specifically work-around problems with Antivirus software. For example, I know for sure that SVN has some special code to handle a problem with some Antivirus programs. Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://vice-emu.sf.net/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setup 2.761 regression: '--quiet-mode' conflicts with '--packages'
It appears that some recent change to setup.exe has unintentionally made '--quiet-mode' incompatible with '--packages' for command-line installs. A similar problem was reported here: http://sourceware.org/ml/cygwin/2011-12/msg00244.html Using current setup.exe version 2.761, this no longer works (although it still works with setup.exe version 2.738 from a few months ago): setup-2.761.exe --quiet-mode --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 --packages cvs That command takes only about one second, and the local subdirectory for downloads contains only setup.ini . According to setup.log.full (which is only about 4K), setup.bz2 is downloaded; then it says: Added manual package cvs Changing gid back to original Visited: 0 nodes out of 1948 while creating dependency order. Dependency order of packages: Changing gid to Administrators Ending cygwin install If '--quiet-mode' isn't given, then everything works (and cvs is installed from '--packages'): setup-2.761.exe --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 --packages cvs ...so that's a workaround, but '--quiet-mode' is much nicer for scripted installation. If '--packages' isn't given, then the base system is installed correctly: setup-2.761.exe --quiet-mode --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 ...but, even after the base system has been installed, rerunning the original command: setup-2.761.exe --quiet-mode --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 --packages cvs doesn't install cvs. The resulting setup.log.full says Visited: 50 nodes out of 1948 while creating dependency order. but the Dependency order of packages list doesn't contain cvs. I've saved setup.log.full from each of the four attempts above in case further information from them is wanted. Cygwin Configuration Diagnostics Current System Time: Wed Dec 21 18:02:59 2011 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 3 Path: C:\cygwin-1_7\usr\local\bin C:\cygwin-1_7\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\ATI Technologies\ATI Control Panel C:\PROGRA~1\COMMON~1\SONICS~1 Output from C:\cygwin-1_7\bin\id.exe UID: 1007(Snowy)GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Snowy' PWD = '/home/Snowy' HOME = '/home/Snowy' HOMEPATH = '\Documents and Settings\Snowy' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Documents and Settings\Snowy\Application Data' HOSTNAME = 'Snowy' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 3 Stepping 4, GenuineIntel' WINDIR = 'C:\WINDOWS' OLDPWD = '/usr/bin' USERDOMAIN = 'SNOWY' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'Snowy' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\Snowy' CLIENTNAME = 'Console' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\SNOWY' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin-1_7\bin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PROCESSOR_REVISION = '0304' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'SNOWY' _ = '/usr/bin/cygcheck' 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_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygwin (default) = (unsupported type) 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-1_5' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:/cygwin-1_5/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:/cygwin-1_5/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin-1_7' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:/cygwin-1_7'
Re: 16 byte pthread stack alignments
On Wed, 21 Dec 2011, Brian Ford wrote: I'm trying to test now, but I haven't built cygwin in years so I'm still working to get things set up. Still trying, but getting the following warning turned into an error by -Werror which looks like it might be valid? cc1plus: warnings being treated as errors src/winsup/cygwin/fhandler.cc: In member function fhandler_base_overlapped::wait_return fhandler_base_overlapped::wait_overlapped(bool, bool, DWORD*, bool, DWORD): src/winsup/cygwin/fhandler.cc:1912: error: err may be used uninitialized in this function -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Sorry people (NOT MY taxonomy!!), but igncr IS flawed
Greetings, Dave Korn! Windows GUI-based archivers are well known for causing this problem. To be fair, you should reduce your reference to WinZIP is known for. At the very least, WinRAR and 7-Zip, both won't try to hold your hand in this case. I don't know about WinACE, though, and I'm not going to check it myself. I haven't checked, but would bet WinRAR and 7-Zip don't accurately recreate the posix permissions when they unpack a *nix tarball. They probably don't unpack device nodes right either. They can probably get softlinks right but I haven't tested that either. I doubt that so much. Neither of them is aware of Cygwin specifics. But they don't have EOL issues for sure, as they treating files as binary at all times. Rather than play guessing games about which gui-based unpackers will do a good job of unpacking something into a Cygwin environment and have to repeatedly re-solve the problems they may cause every time someone says Oh, well you said not to use WinZip, so I used WinRAR (or whatever) instead, I just err on the side of caution and simply advise: for unpacking stuff into a Cygwin environment, always use a Cygwin-aware tool. That's right. -- WBR, Andrey Repin (anrdae...@freemail.ru) 21.12.2011, 22:47 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tetex-tiny bug
marco atzeri writes: On 12/21/2011 4:42 PM, Corinna Vinschen wrote: Jan? Ping? Did you see that mail? I didn't yet, thanks! -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex etexlanguage.def-translate-file=cp227.tcx *etex.ini Yes, that's wrong. I would change it to -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex pdftexlanguage.def-translate-file=cp227.tcx *etex.ini though? pdftex seems to have a similar issue. Yes, then that would mean -pdftex pdfetex - -translate-file=cp227.tcx *pdftex.ini +pdftex pdftex - -translate-file=cp227.tcx *pdftex.ini Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: tetex-tiny bug
Jan Nieuwenhuizen skrev 2011-12-21 20:44: marco atzeri writes: On 12/21/2011 4:42 PM, Corinna Vinschen wrote: Jan? Ping? Did you see that mail? I didn't yet, thanks! -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex etexlanguage.def-translate-file=cp227.tcx *etex.ini Yes, that's wrong. I would change it to -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex pdftexlanguage.def -translate-file=cp227.tcx *etex.ini though? I can't tell, because even if I change back to pdfetex I can't get the error back. Something seems to have mended itself by my initial change to etex. I have absolutely zero TeX-fu btw, I just googled the error message and forwarded something that happened to fix it for me. pdftex seems to have a similar issue. Yes, then that would mean -pdftex pdfetex - -translate-file=cp227.tcx *pdftex.ini +pdftex pdftex - -translate-file=cp227.tcx *pdftex.ini Cheers, Peter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.761 regression: '--quiet-mode' conflicts with '--packages'
On 12/21/2011 12:15 PM, Greg Chicares wrote: It appears that some recent change to setup.exe has unintentionally made '--quiet-mode' incompatible with '--packages' for command-line installs. A similar problem was reported here: http://sourceware.org/ml/cygwin/2011-12/msg00244.html Using current setup.exe version 2.761, this no longer works (although it still works with setup.exe version 2.738 from a few months ago): setup-2.761.exe --quiet-mode --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 --packages cvs That command takes only about one second, and the local subdirectory for downloads contains only setup.ini . According to setup.log.full (which is only about 4K), setup.bz2 is downloaded; then it says: I can confirm this report. I ran into this bug just yesterday but hadn't had a chance to dig into it. The system is a base installation of Windows 7 running under KVM, in case it matters. Let me know if there are any other details I can provide. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 16 byte pthread stack alignments
On Wed, 21 Dec 2011, Brian Ford wrote: Still trying, but getting the following warning turned into an error by -Werror which looks like it might be valid? cc1plus: warnings being treated as errors src/winsup/cygwin/fhandler.cc: In member function fhandler_base_overlapped::wait_return fhandler_base_overlapped::wait_overlapped(bool, bool, DWORD*, bool, DWORD): src/winsup/cygwin/fhandler.cc:1912: error: err may be used uninitialized in this function Thanks for the fix Christopher, but I must be using the wrong compiler or something. Here's my next issue: src/winsup/cygwin/child_info.h: In static member function static cygheap_exec_info* cygheap_exec_info::alloc(): src/winsup/cygwin/child_info.h:115: error: invalid use of member cygheap_exec_info::children in static member function src/winsup/cygwin/sigproc.cc:914: error: from this location -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup 2.761 regression: '--quiet-mode' conflicts with '--packages'
On 21/12/2011 21:02, Jeremy Bopp wrote: On 12/21/2011 12:15 PM, Greg Chicares wrote: It appears that some recent change to setup.exe has unintentionally made '--quiet-mode' incompatible with '--packages' for command-line installs. A similar problem was reported here: http://sourceware.org/ml/cygwin/2011-12/msg00244.html Using current setup.exe version 2.761, this no longer works (although it still works with setup.exe version 2.738 from a few months ago): setup-2.761.exe --quiet-mode --site ftp://mirror.mcs.anl.gov/pub/cygwin/ --root C:/cygwin-1_7 --packages cvs That command takes only about one second, and the local subdirectory for downloads contains only setup.ini . According to setup.log.full (which is only about 4K), setup.bz2 is downloaded; then it says: I can confirm this report. I ran into this bug just yesterday but hadn't had a chance to dig into it. Thanks for reporting this. It looks like I broke this, when trying to remove the side-effect of setup --quiet-mode --packages of upgrading all currently installed packages to the current version. I've send a patch to fix this to cygwin-apps. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
sftp-server -h succeeds on cmd, fails on mintty
Hi, I'm experiencing a wider problem with sftp'ing to/from a Cygwin sshd service. However as a starting point into debugging, I've identified a simple failure in the sftp-server that may give an indication into the wider problem. When I ran just a simple usage argument to sftp-server in a mintty session, the command failed: sbaddah@*** ~ $ /usr/sbin/sftp-server -h; x=$?; echo $x 127 So I tried from just a regular (non-Administrator) Command Prompt: c:\Users\Public\portapps\cygwin\bin..\usr\sbin\sftp-server -h usage: sftp-server [-ehR] [-f log_facility] [-l log_level] [-u umask] From this behaviour, I immediately suspect something to do with tty I/O functionality. I understand there has been a bit of work in this area since the 1.7.9 release, and that there is an experimental 1.7.10. However I'd like to avoid swapping in a later version of the dll, with all its supporting programs, if at all possible. Can anyone shed some light on why this is happening? I've attached a cygcheck.out file with some items redacted. Thanks in advance, Shaddy Cygwin Configuration Diagnostics Current System Time: Thu Dec 22 11:46:19 2011 Windows 7 Enterprise Ver 6.1 Build 7600 Running under WOW64 on AMD64 Path: C:\Users\Public\portapps\cygwin\usr\local\bin C:\Users\Public\portapps\cygwin\bin C:\Program Files\Common Files\Microsoft Shared\Windows Live C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\Enterprise Vault\EVClient C:\Program Files (x86)\Windows Live\Shared Output from C:\Users\Public\portapps\cygwin\bin\id.exe UID: 42037(sbaddah) GID: 10513(Domain Users) 10513(Domain Users) 545(Users) redacted/ SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'sbaddah' PWD = '/tmp' HOME = '/cygdrive/c/Users/sbaddah/cygwin-home' HOMEPATH = '\Users\sbaddah' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\sbaddah\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = '***' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 37 Stepping 5, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/Users/sbaddah/cygwin-home' USERDOMAIN = 'AU' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' UATDATA = 'C:\Windows\SysWOW64\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\' !:: = '::\' DEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'sbaddah' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\sbaddah' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\AUNDDDCSYN01' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\sbaddah\AppData\Local' ProgramData = 'C:\ProgramData' SHLVL = '1' USERDNSDOMAIN = 'AU.**.LOCAL' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'PDFCreator' PROCESSOR_REVISION = '2505' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '4' VSEDEFLOGDIR = 'C:\ProgramData\McAfee\DesktopProtection' SESSIONNAME = 'Console' COMPUTERNAME = '***' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\Users\Public\portapps\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup obcaseinsensitive set to 0 Cygwin installations found in the registry: System: Key: 0f805c407ff50485 Path: C:\Users\Public\portapps\cygwin c: hd NTFS305042Mb 71% CP CS UN PA FC OS 7 d: cd N/AN/A e: fd NTFS 15155Mb 90% CP CS UN PA FC New Volume C:\Users\Public\portapps\cygwin / system binary,auto c:\Users\Public\Temp /tmp system binary C:\Users\Public\portapps\cygwin\bin /usr/bin system binary,auto C:\Users\Public\portapps\cygwin\lib /usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Found: C:\Users\Public\portapps\cygwin\bin\awk - C:\Users\Public\portapps\cygwin\bin\gawk.exe Found: C:\Users\Public\portapps\cygwin\bin\bash.exe Found: C:\Users\Public\portapps\cygwin\bin\cat.exe
Re: sftp-server -h succeeds on cmd, fails on mintty
On 12/21/2011 8:17 PM, Shaddy Baddah wrote: Hi, I'm experiencing a wider problem with sftp'ing to/from a Cygwin sshd service. However as a starting point into debugging, I've identified a simple failure in the sftp-server that may give an indication into the wider problem. When I ran just a simple usage argument to sftp-server in a mintty session, the command failed: sbaddah@*** ~ $ /usr/sbin/sftp-server -h; x=$?; echo $x 127 This works fine for me from mintty. Just a shot in the dark but can you try it with a local user? How about a local user that's part of the local Administrators group? -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sftp-server -h succeeds on cmd, fails on mintty
Hi Larry, On 22/12/11 12:25, Larry Hall (Cygwin) wrote: On 12/21/2011 8:17 PM, Shaddy Baddah wrote: Hi, I'm experiencing a wider problem with sftp'ing to/from a Cygwin sshd service. However as a starting point into debugging, I've identified a simple failure in the sftp-server that may give an indication into the wider problem. When I ran just a simple usage argument to sftp-server in a mintty session, the command failed: sbaddah@*** ~ $ /usr/sbin/sftp-server -h; x=$?; echo $x 127 This works fine for me from mintty. Just a shot in the dark but can you try it with a local user? How about a local user that's part of the local Administrators group? Yes, this has made a difference. Thank you. I ran against a local user, although they were not a local administrator. It ran fine: portapps@*** ~ $ /usr/sbin/sftp-server -h usage: sftp-server [-ehR] [-f log_facility] [-l log_level] [-u umask] I guess that points towards a pseudo terminal handling glitch for a domain user, right? Regards, Shaddy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sftp-server -h succeeds on cmd, fails on mintty
On 12/21/2011 9:10 PM, Shaddy Baddah wrote: Hi Larry, On 22/12/11 12:25, Larry Hall (Cygwin) wrote: On 12/21/2011 8:17 PM, Shaddy Baddah wrote: Hi, I'm experiencing a wider problem with sftp'ing to/from a Cygwin sshd service. However as a starting point into debugging, I've identified a simple failure in the sftp-server that may give an indication into the wider problem. When I ran just a simple usage argument to sftp-server in a mintty session, the command failed: sbaddah@*** ~ $ /usr/sbin/sftp-server -h; x=$?; echo $x 127 This works fine for me from mintty. Just a shot in the dark but can you try it with a local user? How about a local user that's part of the local Administrators group? Yes, this has made a difference. Thank you. I ran against a local user, although they were not a local administrator. It ran fine: portapps@*** ~ $ /usr/sbin/sftp-server -h usage: sftp-server [-ehR] [-f log_facility] [-l log_level] [-u umask] I guess that points towards a pseudo terminal handling glitch for a domain user, right? Not definitely, no. I just tried with my work account (which is a domain account) and found no problem. Although I can't compare directly with the your IDs, I have root(0) and Administrators(544) on mine. Maybe try adding these if you don't have them already. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Hi, On 06/12/11 20:37, Corinna Vinschen wrote: A lot of changes and fixes have been made in Cygwin since 1.7.9 has been released, so we're looking forward to release Cygwin 1.7.10 soon. Please test the latest developer snapshots at http://cygwin.com/snapshots/ which should have Release Candidate quality. I'm having a problem with the most recent snapshot (at time of writing), 2011-12-19 17:48:27 UTC. A regular non-privileged (not in Administrators) user is unable to execute any commands from within a Cygwin process itself. The following copy/paste from a Command Prompt session should illustrate the problem: c:\Users\Public\portapps\cygwin\binls /var cache empty games lib log run tmp c:\Users\Public\portapps\cygwin\binsh -c /bin/ls /var sh: /bin/ls: Permission denied c:\Users\Public\portapps\cygwin\binid -a uid=1007(portapps) gid=513(None) groups=513(None),545(Users) c:\Users\Public\portapps\cygwin\binsh -c /bin/id -a sh: /bin/id: Permission denied I am running Windows 7 64bit. I have another user, who is in the Administrators group, but not being run via “Run as administrator”, for whom it all works fine: c:\Users\Public\portapps\cygwin\binls /var cache empty games lib log run tmp c:\Users\Public\portapps\cygwin\binsh -c /bin/ls /var cache empty games lib log run tmp c:\Users\Public\portapps\cygwin\binid -a uid=42037(sbaddah) gid=10513(Domain Users) groups=10513(Domain Users),545(Users) ,...(quite a number, 10+ domain groups) Using this user, I was able to verify that a problem I have described in the thread of http://cygwin.com/ml/cygwin/2011-12/msg00460.html is not resolved by 1.7.10. I mention this because I had upgraded to the snapshot specifically because of that problem. But I'll keep further updates about it on that thread. Regards, Shaddy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
