Re: Cygwin/X : display error with latest x-related packages
On Mar 12 13:44, xflr6 wrote: Dear Cygwin/X users and developpers, Please note that the cygwin-xfree list has been deprecated. Use the cygwin AT cygwin DOT com list instead. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpWZJoQn3SlG.pgp Description: PGP signature
[ANNOUNCEMENT] Merge of cygwin-xfree-announce into cygwin-announce
Hi folks, it's becoming awkward having to split package announcements between two mailing lists. In fact, there's neither a good reason having to decide where to send an announcement, nor having to subscribe to two lists for Cygwin package announcements. Therefore, effectiv immediately, we're going to give up the cygwin-xfree-announce mailing list in favor of only the cygwin-announce mailing list. === In future, new Cygwin packages and package updates will be announced on cygwin-announce only. === If you're not subscribed to cygwin-announce, only to cygwin-xfree-announce, I'll suggest to subscribe to cygwin-announce instead. For reference and archeological diggings, the cygwin-xfree-announce archives will stay available. Peace, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cannot run Qt5 applications.
On Mar 3 14:48, Jon TURNEY wrote: On 03/03/2015 09:04, Corinna Vinschen wrote: Or you just add signal(SIGSYS, SIG_IGN) prior to calling shmget. SIGSYS is raised when calling a system call which isn't available. That's perfectly valid. This is true. I guess it's not how Linux behaves, though, so I think changing it ought to be considered to minimize porting effort. Done. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAsbfOyZl3B.pgp Description: PGP signature
Re: Cannot run Qt5 applications.
On Mar 2 17:34, Yaakov Selkowitz wrote: On Fri, 2015-02-13 at 18:32 +, Jon TURNEY wrote: On 05/02/2015 01:40, Jon TURNEY wrote: On 04/02/2015 23:20, David Stacey wrote: I'm having difficulty running any Qt5 application. These are the commands I'm issuing: [snip] and I see the clock, so X is up and running. Then: [snip] Possibly you need to install and start cygserver (See [1]) If so, this is because Qt5 is assuming shared memory is available, which could possibly be handled in a better way... This looks like a portability problem in Qt5, where it only handles shmget() failing with a return value of -1, not with SIGSYS, to fallback to using an image in unshared memory. Patch attached. Or is it a problem with our shmget()? http://pubs.opengroup.org/onlinepubs/9699919799/functions/shmget.html http://man7.org/linux/man-pages/man2/shmget.2.html Perhaps we should be just returning -1 with an errno (ENOSYS?) instead of raise(SIGSYS)? Or you just add signal(SIGSYS, SIG_IGN) prior to calling shmget. SIGSYS is raised when calling a system call which isn't available. That's perfectly valid. Of course, it would be nice if Qt5 used POSIX shared memory objects iunstead, but that's asked too much, probably. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgplD_qeT8_Zi.pgp Description: PGP signature
Re: Problem with xterm-301-1
On Feb 27 17:00, Thomas Dickey wrote: On Thu, Feb 27, 2014 at 06:05:48PM +, Matt Seitz (matseitz) wrote: From: Thomas Dickey [mailto:dic...@his.com] On Thu, Feb 20, 2014 at 06:45:00PM +, Matt Seitz (matseitz) wrote: From: Ola Strömfors [mailto:ola.stromf...@gmail.com] After updating from 291-1 to 301-1 xterm starts /bin/sh instead of my shell specified in /etc/passwd or in the SHELL environment variable. The workaround I have found is to create /etc/shells with a list of permitted shells, e.g. (whether xterm should use $SHELL incoming is a different issue that I am reconsidering) Is there any ETA for a resolution of this issue? I added that to my changes for #302 yesterday, and have a couple more issues to resolve (probably #302 will be available this weekend) I've been holding off on upgrading to xterm-301 because of this issue. I'm not sure if there is some patch coming soon (either to xterm or adding a default /etc/shells to Cygwin), or if I should just plan on manually creating my own /etc/shells. With #302, this will work: SHELL=whatever xterm but this is a special case (the program will run - a fix - but will need to be in /etc/shells to have xterm set $SHELL): xterm whatever May I politely ask why xterm cares at all? What is the reasoning behind this? Heere's why I'm asking: Xterm is not a login process, like login(1) or sshd(8). If somebody starts xterm, the login process itself has long exec'ed the login shell, and the permission problem what shell is allowed to be started as login shell is done. Afterwards, the user is usually allowed to start whatever process he or she has a right to. It looks really weird to me that a terminal emulator would decide that certain processes are not allowed to a user which otherwise work fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHL4xGcjK9K.pgp Description: PGP signature
Re: Broken Link - cygwin.com/setup.exe
On Aug 22 15:05, Brandon Kuan wrote: Sorry, I forgot to mention that the webpage having the broken link is at x.cygwin.com The name of the executable is now either setup-x86.exe for the 32-bit version of Cygwin, or setup-x86_64.exe fo the pretty new 64-bit distro. I just fixed that on the x.cygwin.com web page. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1qZUFZKkFd.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 21:59, Angelo Graziosi wrote: Ken Brown wrote: P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect. Thanks, I will wait for your patches and the Cygwin upgrade. Corin.. oops... Mum wrote it will be released tomorrow.. ;-) Yes, and Ken just release the new Emacs, so everything's in place now, son. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4n9W6PX02o.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? Anyway, that would be three extra pointers in the per_process structure, for memalig, posic_memalign, and valloc, and we could get rid of the `if (!use_internal) set_errno(ENOSYS);' in those functions and rather call the user provided functions then. Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpArzq541Qn1.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? Anyway, that would be three extra pointers in the per_process structure, for memalig, posic_memalign, and valloc, and we could get rid of the `if (!use_internal) set_errno(ENOSYS);' in those functions and rather call the user provided functions then. Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNEXZAvqeCa.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 06:28, Ken Brown wrote: On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. Anyway, that would be three extra pointers in the per_process structure, for memalig, posic_memalign, and valloc, and we could get rid of the `if (!use_internal) set_errno(ENOSYS);' in those functions and rather call the user provided functions then. Does that make sense? Yes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfsM6KM4miS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 12:53, Corinna Vinschen wrote: On Aug 14 06:28, Ken Brown wrote: On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpa98jiOgKrE.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 13:33, Corinna Vinschen wrote: On Aug 14 12:53, Corinna Vinschen wrote: On Aug 14 06:28, Ken Brown wrote: On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp0luhIEycfo.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 08:28, Ryan Johnson wrote: On 14/08/2013 7:59 AM, Corinna Vinschen wrote: On Aug 14 13:33, Corinna Vinschen wrote: On Aug 14 12:53, Corinna Vinschen wrote: On Aug 14 06:28, Ken Brown wrote: On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Wait, it's memalign that's obsolete and posix_memalign that you added a patch for, right? The last couple of paragraphs were a little confusing... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAQ5zLeQLu1.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 16:05, Corinna Vinschen wrote: On Aug 14 08:28, Ryan Johnson wrote: On 14/08/2013 7:59 AM, Corinna Vinschen wrote: On Aug 14 13:33, Corinna Vinschen wrote: On Aug 14 12:53, Corinna Vinschen wrote: Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. Oops. Make that valloc is just as obsolete as memalign. I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Wait, it's memalign that's obsolete and posix_memalign that you added a patch for, right? The last couple of paragraphs were a little confusing... Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpNIXaqU338V.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 14 11:55, Ken Brown wrote: On 8/14/2013 8:14 AM, Ken Brown wrote: On 8/14/2013 7:59 AM, Corinna Vinschen wrote: I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Thanks. It should only be emacs that needs rebuilding; glib doesn't supply its own malloc, but emacs does. I'll test it and report back. Success! Thanks very much for the quick fix. I've got new emacs packages ready to go for both 32-bit and 64-bit. Do you expect to release cygwin-1.7.24 soon? If not, I'll upload the new packages as test releases for anyone who wants to install the snapshot. Thanks for testing. I'll update to 1.7.24 tomorrow. We have lots of unused version numbers left ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpjGqTBJKirx.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Exactly; in glib-2.36, g_type_init has been moved to a ctor, which is automatically called before main(); hence, this setenv is too late now. Mozilla software is also affected by this, see: https://bugzilla.gnome.org/show_bug.cgi?id=687763 https://bugzilla.mozilla.org/show_bug.cgi?id=833117 and many others. Firefox et al already use launcher scripts, so adding one more line won't be a big deal for them. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_5JX_4OVdN.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental)
On Aug 4 19:17, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** XtoW-20130802-1 *** libxcwm0-20130802-1 *** libxcwm-devel-20130802-1 I fixed http://cygwin.com/cygwin-64bit-missing To use: * A startxtow script is provided, which writes a suitable xorg.conf, starts the X server, XtoW, xwinclip and a transparent urxvt. This script is intended to be temporary, to be replaced by something better later on... The script is missing in the 64 bit version. How to start XtoW without that script? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: XtoW, a native compositing window manager (experimental)
On Aug 5 11:00, Jon TURNEY wrote: On 05/08/2013 09:54, Corinna Vinschen wrote: On Aug 4 19:17, Jon TURNEY wrote: I fixed http://cygwin.com/cygwin-64bit-missing To use: * A startxtow script is provided, which writes a suitable xorg.conf, starts the X server, XtoW, xwinclip and a transparent urxvt. This script is intended to be temporary, to be replaced by something better later on... The script is missing in the 64 bit version. How to start XtoW without that script? Oops. It seems that I made a packaging error and startxtow is missing from both x86 and x86_64 packages. I've uploaded a XtoW-20130802-2 which includes the script. It'll still need some adjusting on x86_64, as it requires both perl-Win32-GUI and rxvt-unicode-X which aren't yet packaged, but you could work around that by hard-coding your display dimensions and using a different X terminal... Ok, thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe segmentation fault on Windows 7
On Aug 14 16:41, Chris LeBlanc wrote: Now the question is, if the same problem occurs, why? Please paste the contents of /etc/fstab and, if it exists, /etc/fstab.d/$USER into your reply. Thanks for the information, I think we're getting closer to finding the problem. /etc/fstab doesn't have anything in it apart from comments, and the /etc/fstab.d directory is empty. Here is the output from the mount command: C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type ntfs (binary,posix=0,user,noumount,auto) Segmentation fault (core dumped) It fails when it reaches a network share. Looking at them in Windows Explorer, they're all NcFsd network shares ... That was the essential information to find the bug. For the last Cygwin version I added support for the new ReFS filesystem and I changed one datastructure without also changing another, closely related datastructure. The bug would have shown for other FSes as well, but it would only have resulted in printing the wrong FS type in mount. Only for NcFsd it was bound to crash. This will be fixed in the (soon to come) Cygwin 1.7.17. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe segmentation fault on Windows 7
On Aug 13 13:17, Jon TURNEY wrote:
On 13/08/12 05:23, Chris LeBlanc wrote:
I compiled xorg with debugging from the source packages, and that
shows the same behaviour. I can step through the debugger, but the
output is the same as what Jon found in the previous email, failing on
the call to strcpy(). I've logged the gdb output to a file and can
attach it if anyone is interested.
Yes, please.
Assuming for the moment this is a defect in the cygwin DLL, it would
be interesting to see the output of 'mount'. You might also want to
install the cygwin-debuginfo package and see if you can debug the
problem in getmntent().
It might be worthwhile installing the latest cygwin snapshot [1] to
see if the problem still exists.
[1] http://cygwin.com/snapshots/
First step is to take XWin out of the picture. If this is a generic
problem with getmntent, then a standard getmntent loop should show the
same behaviour:
#include stdio.h
#include mntent.h
int main ()
{
FILE *fp;
struct mntent *mnt;
fp = setmntent (/etc/mtab, r);
while ((mnt = getmntent (fp)) != NULL)
printf (name: %s mount point: %s type: %s flags: %s\n,
mnt-mnt_fsname, mnt-mnt_dir, mnt-mnt_type, mnt-mnt_opts);
endmntent (fp);
return 0;
}
Now the question is, if the same problem occurs, why? Please paste
the contents of /etc/fstab and, if it exists, /etc/fstab.d/$USER
into your reply.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin mounted drives as Administrator on Windows 7
On Aug 31 11:40, Mobin Bhayat wrote: Hi, I’ve installed Cygwin 1.7 on a Windows 7 machine. The issue I’m having is with viewing mapped network drives. When running as a normal user I can see all the drives mounted correctly under /cygdrive E.G. /cygdrive/x, / cygdrive /y etc.. However when I run Cygwin as an Administrator only the C drive remains mounted under /cygdrive/c Is there any additional setup I need to run in order to view the drives correctly as an Administrator? That's UAC. See http://technet.microsoft.com/en-us/library/ee844140%28WS.10%29.aspx Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: considering modifier keys after gaining focus
On Aug 16 17:31, Oliver Schmidt wrote: Hi, I had the problem, that the state of the modifier keys was lost when a window is created (or raised). Example: in window A Ctrl + some key opens a window B, then in window B Ctrl + some other key triggers the next action. However after the opening of window B the Ctrl key has to be released and pressed again. If the user keeps the Ctrl key holding when the window B is opened, the next key press X will be interpreted as X and not as Ctrl+X. I send a patch to fix this problem with this email: I just extended the function winRestoreModeKeyStates in winkeybd.c to consider not only the mode switch key but also the modifiers Ctrl, Shift, Alt/AltGr by using the Windows function GetAsyncKeyState. This patch works fine for me. However one problem is unsolved: if the key combination for opening window B (in the above example) is an AltGr key combination, the GetAsyncKeyState will also report, that the Ctrl key is pressed, which is not true, since this is the well known Windows fake Ctrl_L :-( Any suggestions how to solve this? At that time, doesn't GetAsyncKeyState (VK_RMENU) also return 0? So, shouldn't something along these lines do the trick: BOOL ctrl = (GetAsyncKeyState (VK_CONTROL) 0); BOOL shift = (GetAsyncKeyState (VK_CONTROL) 0); BOOL alt = (GetAsyncKeyState (VK_CONTROL) 0); BOOL altlang = (GetAsyncKeyState (VK_CONTROL) 0); if (ctrl altlang) ctrl = FALSE; if (WIN_XOR (internalKeyStates ControlMask, ctrl) winSendKeyEvent (KEY_LCtrl, ctrl); if (WIN_XOR (internalKeyStates ShiftMask, shift)) winSendKeyEvent (KEY_ShiftL, shift); if (WIN_XOR (internalKeyStates Mod1Mask, alt)) winSendKeyEvent (KEY_Alt, alt); if (WIN_XOR (internalKeyStates Mod5Mask, altlang)) winSendKeyEvent (KEY_AltLang, altlang); Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Shared memory support (MIT-SHM) in 1.7?
On Jul 23 13:21, egerl...@aiai.de wrote: Hi, I've read in http://x.cygwin.com/docs/ug/using-shared-memory.html hat cygwin supports shared memory, but: Note: for Cygwin 1.5 only. I ask me whether the documentation refers only to older versions of cygwin or also to newer versions 1.6 and 1.7. Who knows the answer? If 1.7 does not support shared memory, so I have to install legacy version 1.5 (see http://www.cygwin.com/win-9x.html ), right? I've just installed the latest version 1.7.x , so I uninstall this version (by deleting c:\cygwin, right?) an I install the setup-legacy.exe , right? No. Read http://x.cygwin.com/docs/ug/using-shared-memory.html again. It says exactly what you need to do to get XSI shared memory running. The *note* is for 1.5 only. Corinna (*) Btw., named POSIX shared mem support is available since 1.7. It's a pity that MIT-SHM extension uses XSI, rather than POSIX shared memory, since you don't need cygserver for the POSIX implementation. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. Attached is a small test-case which seems to demonstrate this problem. Run ./dev-windows-select-test and observe select() blocks for the full timeout, despite the fact that the /dev/windows fd is ready for reading (and it reported as such as the end of the timeout) If you run './dev-windows-select-test -skip' to skip the PeekMessage(), select() returns immediately, indicating the /dev/windows fd is ready for reading. Again, thanks for the testcase. I applied a patch to Cygwin which should make select on /dev/windows fully functional. The blessed solution is to replace the call to MsgWaitForMultipleObjects with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE flag set. This flag is defined to do exactly what we need. The only downside is that this flag does not exist on NT4 and its usage results in an invalid argument error. So, for NT4, I added the workaround I described in my yesterday's soliloquy. I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please give it a test as soon as possible. Here's a binary DLL for testing (build w/o optimization, so it's probably a bit slow): http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2 (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote:
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the
full timeout, despite the fact that the /dev/windows fd is ready for
reading (and it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the
PeekMessage(), select() returns immediately, indicating the
/dev/windows fd is ready for reading.
[...]
Thanks for the testcase. I examined this and I think I have a
workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for
MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the
wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I
did was to add the QS_ALLPOSTMESSAGE flag to the
MsgWaitForMultipleObjects call in select.cc, and to change the
PeekMessage call in select.cc:peek_windows() from
PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE)
to
PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE)
Same in your above test application. This appears to do the trick.
However, I'm not exactly sure if that's a valid fix. Patch below.
Corinna
Index: select.cc
===
RCS file: /cvs/src/src/winsup/cygwin/select.cc,v
retrieving revision 1.160
diff -u -p -r1.160 select.cc
--- select.cc 2 Apr 2010 22:36:44 - 1.160
+++ select.cc 29 Aug 2010 14:16:18 -
@@ -287,7 +287,8 @@ select_stuff::wait (fd_set *readfds, fd_
if (!windows_used)
wait_ret = WaitForMultipleObjects (m, w4, FALSE, ms);
else
- wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms, QS_ALLINPUT);
+ wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms,
+ QS_ALLINPUT | QS_ALLPOSTMESSAGE);
switch (wait_ret)
{
@@ -1531,7 +1532,7 @@ peek_windows (select_record *me, bool)
if (me-read_selected me-read_ready)
return 1;
- if (PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE))
+ if (PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE))
{
me-read_ready = true;
select_printf (window %d(%p) ready, me-fd, me-fh-get_handle ());
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server no longer launches urxvtc-X
On Aug 20 10:54, Charles Wilson wrote: On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Today I upgraded my cygwin install and all my menu items like the above no longer work. (as noted above I've tried both simply urxvtc-X and /bin/urxvtc-X If, however, I open up a command window using rxvt and then enter the above Line (by copy and paste) it works fine. My first guess was that the urxvt daemon (urxvtd-X) was not running, so the client failed. But if you can launch the client using some incantation, then that means the daemon is running. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. Ah. Here's the clue: launching a native win32 program fails. I bet this is related to the change in cygwin-1.7.6 where the cygwin current working directory and the win32 CWD are no longer automatically kept in sync (there are good reasons for this new behavior). Maybe that's related, but why? Does urxvtc-X start applications using CreateProcess? I'm asking because if they are started via fork/exec, the cwd for the child process gets set to the Cygwin cwd if the child is a native Win32 process, like Notepad. Cygwin executables OTOH shouldn't be affected, unless, again, they use native Win32 calls. And that also doesn't answer the question why starting /bin/urxvtc-X in the menu entries at the start of the mail are not working anymore, at least unless /bin/urxvtc-X is not a Cygwin application. This change has caused a number of problems, and it is not yet clear how they will be resolved. In the first place: http://cygwin.com/ml/cygwin/2010-08/msg00554.html and http://cygwin.com/ml/cygwin/2010-08/msg00562.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X Server no longer launches urxvtc-X
Please dont top-post. On Aug 20 14:14, Jay Goldman wrote: Another data point, when I try: black EXEC /bin/rxvt -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -i rxvt successfully starts up but displays: /bin/find: failed to restore initial working directory: No such file or directory Before .bash_profile is invoked Works for me without such a message. Do you know from where find is called? -Original Message- From: Corinna Vinschen On Aug 20 10:54, Charles Wilson wrote: On 8/20/2010 10:48 AM, Jay Goldman wrote: I have the following menu items in my .XWinrc: Black EXEC /bin/urxvtc-X -fg green -bg black -cr dodgerblue -g 80x40 -e /bin/bash -l -I dodger EXEC urxvtc-X -fg white -bg dodgerblue -cr blue -g 80x42 -e /bin/bash -l -I Which have been working for months . Doesn't work for me either, but has apparently nothing to do with the CWD issue. This looks more like a rebase problem. Note, menu items like: Xterm exec xterm Work correctly, While menu items such as: Notepad exec notepad Do not. I tried this as well now, and both menu entries work for me. Maybe the difference is the Cygwin DLL. Can you please try the latest Cygwin DLL from the developer snapshots at http://cygwin.com/snapshots/ and report back if this works better for you? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X11R7.5 and C.UTF-8
On Dec 3 07:48, Andy Koppe wrote: 2009/12/3 Linda Walsh: C.UTF_8 doesn't exist. Well, guess what: it does in Cygwin 1.7, and it's the default locale. Not exactly. The default locale is C.UTF-8. You can also use C.UTF8 or C.utf-8 or C.utf8, but not C.UTF_8 or C.utf_8. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X11R7.5 and C.UTF-8
On Dec 3 13:16, Andy Koppe wrote:
2009/12/3 Thomas Dickey:
From
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html,
§7.2:
The tables in Locale Definition describe the characteristics and
behavior of the POSIX locale for data consisting entirely of
characters from the portable character set and the control character
set. For other characters, the behavior is unspecified.
This means that characters 0..127 have to be treated as ASCII, but
beyond that an implementation can do what it wants. And on Cygwin 1.7,
plain C actually does imply UTF-8, which happily is
backward-compatible with ASCII.
That's an interpretation that so far hasn't been blessed by the standards
people. Any discussion of this topic should mention that, as a caveat.
Fair point. It also means that apps are entitled to assume that C
supports no more than ASCII, which is why Cygwin 1.7's default locale
is C.UTF-8. A default locale setting based on the user's language
selection would be better, but we don't have that (yet?).
Try the attached. Note: It has a hidden --testloop option...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
#define WINVER 0x0600
#include stdio.h
#include windows.h
#include getopt.h
#define VERSION 1.0
extern char *__progname;
void version () __attribute__ ((noreturn));
void usage (FILE *, int) __attribute__ ((noreturn));
void
version ()
{
printf (%s (Cygwin) %s\n, __progname, VERSION);
exit (0);
}
void
usage (FILE * stream, int status)
{
fprintf (stream, \n\
Usage: %s [-suU] [-l LCID]\n\
\n\
Return POSIX LANG identifier corresponding to a locale, default is the\n\
system default locale\n\
Possible options are:\n\
\n\
-s, --system return LANG for the system's default locale\n\
-u, --userreturn LANG for the current user's default locale\n\
-l, --lcid LCID return LANG for the LCID given as argument\n\
-U, --UTF-8 always attach .UTF-8 to LANG\n\
-h, --helpthis text\n\
-V, --version print the version of %s and exit\n,
__progname, __progname);
exit (status);
}
struct option longopts[] = {
{system, no_argument, NULL, 's'},
{user, no_argument, NULL, 'u'},
{lcid, required_argument, NULL, 'l'},
{UTF-8, no_argument, NULL, 'U'},
{help, no_argument, NULL, 'h'},
{version, no_argument, NULL, 'V'},
{testloop, no_argument, NULL, 'T'},
{0, no_argument, NULL, 0}
};
char *opts = dsul:UhV;
int
getlocale (LCID lcid, bool utf, bool test)
{
UINT codepage;
char iso639[10];
char iso3166[10];
if (!GetLocaleInfo (lcid, LOCALE_IDEFAULTANSICODEPAGE | LOCALE_RETURN_NUMBER,
(char *) codepage, sizeof codepage)
|| !GetLocaleInfo (lcid, LOCALE_SISO639LANGNAME, iso639, 10)
|| !GetLocaleInfo (lcid, LOCALE_SISO3166CTRYNAME, iso3166, 10))
{
if (!test)
fprintf (stderr, %s: Non existant locale\n, __progname);
return 2;
}
if (utf)
codepage = 0;
if (test)
{
char cty[256];
char lang[256];
GetLocaleInfo (lcid, LOCALE_SENGCOUNTRY, cty, 256);
GetLocaleInfo (lcid, LOCALE_SENGLANGUAGE, lang, 256);
printf (0x%04x=\%s_%s\, %s (%s)\n, (unsigned) lcid, iso639, iso3166,
lang, cty);
}
else
printf (LANG=\%s_%s%s\\n, iso639, iso3166, codepage ? : .UTF-8);
return 0;
}
#define d(X) {X, #X}
struct dl {
LCTYPE t;
const char *s;
} dlist[] = {
d(LOCALE_SLONGDATE),
d(LOCALE_SSHORTDATE),
d(LOCALE_STIMEFORMAT),
d(LOCALE_SYEARMONTH),
d(LOCALE_S1159),
d(LOCALE_S2359),
d(LOCALE_SDAYNAME1),
d(LOCALE_SDAYNAME2),
d(LOCALE_SDAYNAME3),
d(LOCALE_SDAYNAME4),
d(LOCALE_SDAYNAME5),
d(LOCALE_SDAYNAME6),
d(LOCALE_SDAYNAME7),
d(LOCALE_SABBREVDAYNAME1),
d(LOCALE_SABBREVDAYNAME2),
d(LOCALE_SABBREVDAYNAME3),
d(LOCALE_SABBREVDAYNAME4),
d(LOCALE_SABBREVDAYNAME5),
d(LOCALE_SABBREVDAYNAME6),
d(LOCALE_SABBREVDAYNAME7),
d(LOCALE_SMONTHNAME1),
d(LOCALE_SMONTHNAME2),
d(LOCALE_SMONTHNAME3),
d(LOCALE_SMONTHNAME4),
d(LOCALE_SMONTHNAME5),
d(LOCALE_SMONTHNAME6),
d(LOCALE_SMONTHNAME7),
d(LOCALE_SMONTHNAME8),
d(LOCALE_SMONTHNAME9),
d(LOCALE_SMONTHNAME10),
d(LOCALE_SMONTHNAME11),
d(LOCALE_SMONTHNAME12),
d(LOCALE_SMONTHNAME13),
d(LOCALE_SABBREVMONTHNAME1),
d(LOCALE_SABBREVMONTHNAME2),
d(LOCALE_SABBREVMONTHNAME3),
d(LOCALE_SABBREVMONTHNAME4),
d(LOCALE_SABBREVMONTHNAME5),
d(LOCALE_SABBREVMONTHNAME6),
d(LOCALE_SABBREVMONTHNAME7),
d(LOCALE_SABBREVMONTHNAME8),
d(LOCALE_SABBREVMONTHNAME9),
d(LOCALE_SABBREVMONTHNAME10),
d(LOCALE_SABBREVMONTHNAME11),
d(LOCALE_SABBREVMONTHNAME12),
d(LOCALE_SABBREVMONTHNAME13),
{ 0, NULL }
};
int main (int argc, char **argv)
{
int opt;
LCID lcid = LOCALE_SYSTEM_DEFAULT;
bool utf = false;
bool test = false;
bool dates = false;
while ((opt = getopt_long (argc, argv, opts, longopts, NULL)) != EOF)
switch (opt
Re: xterm not working
On Nov 29 22:42, Yaakov S wrote: On 29/11/2009 21:28, Joe Java wrote: Gone for Thanksgiving break, return and update cygwin, and now xterm does not show anymore. I have not upgraded to the latest 1.7 (I am waiting for the official release). I read the other messages and nothing seems to work. Does anyone have a SIMPLE solution to this problem. Downgrade the termcap package until there is another update thereto. Isn't xterm linked against ncurses? Why does it break on a termcap file at all? There's a big chance that I just missed the thread in which this has been discussed. A pointer would be nice. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't read lock file
On Nov 11 07:40, Fergus wrote: Q1. Is it still the case that this problem is not well understood as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file Hardlinks don't work on FAT filesystems since FAT doesn't support them. Up to Cygwin 1.7.0-60, hardlinks on FAT were faked by copying the file. This has obvious downsides (unsecure, potential denial-of-service problems, portability), so we discussed and decided to remove this fake and to return an error instead when trying to create a hardlink on a FAT FS: http://cygwin.com/ml/cygwin/2009-09/msg00208.html (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. As for X, it should have a fallback method if the /tmp filesystem doesn't support hardlinks. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygwin 1.7.0-63 problems with X programs
On Nov 7 09:27, Eliot Moss wrote: Like another user, I had difficulty getting X to fire up. After setting LANG=en_US.UTF-8 I got farther, but these issues remain: Each xterm, xemacs, and xclock I start outputs this: Warning: Missing charsets in String to FontSet conversion I also get a series of: twm: warning: font for charset XXX is lacking. Where XXX is replaced by each of these in turn: JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 Those three lines repeat 6 times. Also: 1) the whole deal takes noticeably longer to start 2) xemacs does not receive its normal geometry from .Xdefaults 3) each xterm started from .xinitrc has a blank line before the initial bash prompt, that wasn't present before I can reproduce that, but I can't make any sense of it. What on earth does that have to do with setting LANG to en_US.UTF-8?!? I'll redirect this to the cygwin-xfree list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X11R7.5 and C.UTF-8
On Oct 29 13:42, Jon TURNEY wrote: I haven't been following the discussion about C.UTF-8 closely, but curiously, for me at least, this test program shows that setlocale(LC_ALL, ) fails with LANG=C.UTF-8 (so that doesn't actually seem to be a valid locale, although if it's the default it probably doesn't make much difference), but this means that a subsequent setlocale(LC_ALL, NULL) just returns C What version of Cygwin 1.7 are you using? The change to newlib, which allows to specify C.UTF-8 as locale is from 2009-09-29, so Cygwin 1.7.0-62 from 2009-10-03 allows to specify this locale. The change which makes C.UTF-8 Cygwin's default locale is from 2009-10-09, so this change is only in Cygwin from CVS, or in developer snapshots from past that date. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xterm hangs with latest Cygwin (-62?)
On Oct 5 17:46, Yaakov S wrote: On 05/10/2009 13:47, Corinna Vinschen wrote: --- sys.c.ORIG 2009-10-05 19:23:58.0 +0200 +++ sys.c2009-10-05 19:18:34.0 +0200 @@ -408,7 +408,11 @@ openTty(char *line) int rc; int tty = -1; +#ifdef __CYGWIN__ +tty = open(line, O_RDWR); +#else tty = open(line, O_RDWR | O_NOCTTY); +#endif For portability, perhaps this should also be #ifdef TIOCSCTTY, if these two sections go hand-in-hand? Sure, sounds much better than #ifdef __CYGWIN__. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xterm hangs with latest Cygwin (-62?)
On Oct 4 17:06, Jim Reisert AD1C wrote: On 10/4/2009 1:52 PM, Corinna Vinschen wrote: Stracing shows that luit is called with `luit -argv0 -tcsh', but nowhere in the strace tcsh is actually started. Rather, it looks like luit starts /bin/sh with argv[0] set to -tcsh instead. Interesting. When I was experimenting with -62, I noticed several tcsh.exe processes in the Windows task manager. Maybe they're sort of starting, but don't get connected to the xterm somehow? Neither the strace, nor Task Manager show any tcsh process in my case. There's a difference, though, when starting xterm via the `run -p xterm -ls' shortcut. With Cygwin -61, xterm just starts tcsh and it works, with Cygwin -62, xterm tries to start the shell via luit, and that fails. If luit is missing on the system (renamed), xterm starts with a message Can't execvp /usr/bin/luit: No such file or directory, and then starts tcsh just fine afterwards. Since there's no difference otherwise, it's not clear to me why this occurs. In both cases the locale is set to the default C locale. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xterm hangs with latest Cygwin (-62?)
On Oct 5 10:20, Andy Koppe wrote: 2009/10/5 Corinna Vinschen: There's a difference, though, when starting xterm via the `run -p xterm -ls' shortcut. With Cygwin -61, xterm just starts tcsh and it works, with Cygwin -62, xterm tries to start the shell via luit, and that fails. If luit is missing on the system (renamed), xterm starts with a message Can't execvp /usr/bin/luit: No such file or directory, and then starts tcsh just fine afterwards. Since there's no difference otherwise, it's not clear to me why this occurs. In both cases the locale is set to the default C locale. Perhaps its behaviour depends on MB_CUR_MAX? Probably, but that's not the actual problem. The same happens in any other, valid non-C locale, evey time tcsh is started via luit. I digged deeper into this and it appears to be a bug in luit in the first place. In the second place it appears to be a bug in Cygwin as well. In the third place tcsh is not as smart as bash making the current terminal on the stdio descriptors its controlling tty. What happens is this, somewhat simplified: Xterm creates a pty, make that the controlling tty and starts luit. Luit creates another pty to run tcsh in it: /* Give up own controlling tty. */ close (0); close (1); close (2); /* Set process group to own pid and set controlling tty to -1. */ setsid (); /* Open tty as non-controlling tty. */ new_tty = open (line, O_RDWR | O_NOCTTY); /* Make new tty controlling tty. */ #ifdef TIOCSCTTY ioctl(tty, TIOCSCTTY, (char *)0); #endif And here's the problem. Cygwin doesn't have TIOCSCTTY, and the only way to make a terminal a controlling tty in Cygwin is to call open() on it, which tcsh misses to do. Bash, however, calls open(/dev/tty, O_RDWR), so bash doesn't have this problem. Unfortunately, luit has no alternative way to make the new tty the controlling tty. What we need is a patch like this in luit: --- sys.c.ORIG 2009-10-05 19:23:58.0 +0200 +++ sys.c 2009-10-05 19:18:34.0 +0200 @@ -408,7 +408,11 @@ openTty(char *line) int rc; int tty = -1; +#ifdef __CYGWIN__ +tty = open(line, O_RDWR); +#else tty = open(line, O_RDWR | O_NOCTTY); +#endif if(tty 0) goto bail; This works fine for me with tcsh now as well. This patch is really important, since not only tcsh is affected by this. If you call, for instance, `xterm -e /bin/vim', vim works, but it has no controlling tty either, as easily visible in `ps -e' output. So a patch to tcsh would only fix this for tcsh, but not for any other application. As for the Cygwin bug, it has to do with the return value of tcgetpgrp, which appears to be incorrect in a couple of situations. I'm not quite sure how to explain this, yet, nor if I really understood it. I'll follow up on this later this week on the cygwin-developers list. Yaakov, could you please generate a new luit package with the above patch? Thanks, Corinna P.S: I had to build luit manually for testing. Building with cyport failed: configure.ac:30: error: must install xorg-macros 1.3 or later before running autoconf/autogen -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xterm hangs with latest Cygwin (-62?)
On Oct 5 20:47, Corinna Vinschen wrote: Unfortunately, luit has no alternative way to make the new tty the controlling tty. What we need is a patch like this in luit: --- sys.c.ORIG2009-10-05 19:23:58.0 +0200 +++ sys.c 2009-10-05 19:18:34.0 +0200 @@ -408,7 +408,11 @@ openTty(char *line) int rc; int tty = -1; +#ifdef __CYGWIN__ +tty = open(line, O_RDWR); +#else tty = open(line, O_RDWR | O_NOCTTY); +#endif if(tty 0) goto bail; This works fine for me with tcsh now as well. Oh, btw., this only works with tcsh for me if the shortcut is run xterm -e /bin/tcsh -l In that case xterm calls `luit -- /bin/tcsh'. Or, it works to call `xterm -ls' from a Cygwin shell. However, it still behaves weird if the shortcut is run xterm -ls or if you start `xterm -ls' from a cmd shell. This results in xterm calling luit -argv0 -tcsh which in turn starts /bin/sh with argv[0] set to tcsh. This looks somehow like a bug in xterm. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xterm hangs with latest Cygwin (-62?)
On Oct 4 11:44, Jim Reisert AD1C wrote: Did you upgrade xorg-server at the same time? Maybe your problem is caused by the change in system.XWinrc that I reported yesterday: http://cygwin.com/ml/cygwin-xfree/2009-10/msg00023.html I already had the latest Xorg server. The only difference is the Cygwin version. -61 works, -62 hangs. This looks like a problem with the latest luit. I can start xterm, but I only get a /bin/sh prompt, not my usual tcsh prompt. Stracing shows that luit is called with `luit -argv0 -tcsh', but nowhere in the strace tcsh is actually started. Rather, it looks like luit starts /bin/sh with argv[0] set to -tcsh instead. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: PATCH /usr/include/X11/Xtrans/Xtranssock.c [WAS: Re: xhost package not compiled for IPv6]
On Aug 12 13:54, Jon TURNEY wrote:
diff --git a/Xtranssock.c b/Xtranssock.c
index 0935744..4d2e2cb 100644
--- a/Xtranssock.c
+++ b/Xtranssock.c
@@ -1260,7 +1260,11 @@ TRANS(SocketINETAccept) (XtransConnInfo ciptr, int
*status)
{
XtransConnInfo newciptr;
+#if defined(IPv6) defined(AF_INET6)
+struct sockaddr_storagesockname;
+#else
struct sockaddr_in sockname;
+#endif
SOCKLEN_T namelen = sizeof(sockname);
PRMSG (2, SocketINETAccept(%p,%d)\n, ciptr, ciptr-fd, 0);
Hmmm... but if it's really the size of the sockname argument which is
causing the accept() to fail, this would be a bug in cygwin's accept()
implementation, as it's supposed to truncate the data written to the
sockname, rather than fail if it won't fit [1]. If that actually is the
case, since we don't actually use the peer address here, the code as
stands is correct (if a little odd).
If so, it's a problem in WinSock in the first place. From MSDN it looks
like accept doesn't truncate the data, but rather returns WSAEFAULT if
the size argument is too small for the given socket domain.
I suppose I need to write a small test case to look at this...
That would be nice.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: [1.7] IPv6 accept() fails if address_len is sizeof(sockaddr_in6) [was Re: PATCH /usr/include/X11/Xtrans/Xtranssock.c [WAS: Re: xhost package not compiled for IPv6]]
On Aug 12 14:48, Jon TURNEY wrote: On 12/08/2009 13:54, Jon TURNEY wrote: Hmmm... but if it's really the size of the sockname argument which is causing the accept() to fail, this would be a bug in cygwin's accept() implementation, as it's supposed to truncate the data written to the sockname, rather than fail if it won't fit [1]. If that actually is the case, since we don't actually use the peer address here, the code as stands is correct (if a little odd). I suppose I need to write a small test case to look at this... [1] http://www.opengroup.org/onlinepubs/009695399/functions/accept.html A couple of small programs which hopefully demonstrate this problem. (As is, the connection fails, but uncommenting the alternate definition of cliaddr in listener.c allows it to work) I'd hazard a guess that perhaps this is because the underlying winsock accept() doesn't have this truncate behaviour and considers a too-small address_len an error. Thanks for the testcase! This confirms what I wrote about WinSock in http://cygwin.com/ml/cygwin-xfree/2009-08/msg00029.html Now for the patch to workaround that problem... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [1.7] IPv6 accept() fails if address_len is sizeof(sockaddr_in6) [was Re: PATCH /usr/include/X11/Xtrans/Xtranssock.c [WAS: Re: xhost package not compiled for IPv6]]
On Aug 12 16:20, Jon TURNEY wrote: On 12/08/2009 14:59, Corinna Vinschen wrote: On Aug 12 14:48, Jon TURNEY wrote: On 12/08/2009 13:54, Jon TURNEY wrote: Hmmm... but if it's really the size of the sockname argument which is causing the accept() to fail, this would be a bug in cygwin's accept() implementation, as it's supposed to truncate the data written to the sockname, rather than fail if it won't fit [1]. If that actually is the case, since we don't actually use the peer address here, the code as stands is correct (if a little odd). I suppose I need to write a small test case to look at this... [1] http://www.opengroup.org/onlinepubs/009695399/functions/accept.html A couple of small programs which hopefully demonstrate this problem. (As is, the connection fails, but uncommenting the alternate definition of cliaddr in listener.c allows it to work) I'd hazard a guess that perhaps this is because the underlying winsock accept() doesn't have this truncate behaviour and considers a too-small address_len an error. Thanks for the testcase! Oh, I meant to say A couple of small programs shamelessly copied from UNIX Network Programming. So don't thank me, thank W. Richard Stevens :-) I already thanked W. Richard Stevens in Cygwin's sources. He was *the* network guy for me. His books and the source codes are invaluable. I have applied a patch to accept(), btw. This should now work in the given scenario. It occured to me that the returned value is incorrect for AF_UNIX/AF_LOCAL sockets, but that was always the case and it's not a regression. Usually the peer address of an AF_UNIX socket is not of interest anyway. I added that to my TODO list and probably fix that in a later release. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: USB Device Configurations in Cygwin
On Jul 22 12:41, Waqar Ahmad wrote: I am trying to configure Kannel on Windows Vista using Cygwin. Installation is successful. What I don't know is how to configure a mobile device connected on USB port in Cygwin. I am using Nokia E51 as GSM modem connected via USB cable. This device shows up in Windows Vista Device Manager as connected on COM18. How should I specify settings in the kannel.config so that I can use E51 as GSM Modem? I tried ???device = COM18??? and also ???device = /dev/COM18??? but they don???t work. The documentation is your friend: http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Question for Corinna (was Re: Novice Question)
On Jun 29 10:50, Christopher Faylor wrote:
On Mon, Jun 29, 2009 at 12:09:12PM +0100, Jon TURNEY wrote:
Andy wrote:
/opt/wip/cygport-svn/xorg-server/xorg-server-1.6.0-10/src/xorg-server-1.6.0/
os/access.c
(gdb) p *ifr
$1 = {ifa_next = 0x1447798, ifa_name = 0x14474c4
{B8B51884-C69A-4592-B65D-89ABB3DCF18D}, ifa_flags = 69635,
ifa_addr = 0x14474f0, ifa_netmask = 0x14475f0, ifa_dstaddr = 0x0,
ifa_data
= 0x0}
:-)
It seems that the (new for Cygwin 1.7) getifaddr() function can return
interfaces with IFF_BROADCAST IFF_UP set, but no broadcast address, which
the X server assumes never happens
I was going to say that this sounds wrong but I see interfaces on my
linux box which have no broadcast addresses but still have IFF_BROADCAST
set.
Corinna, what do you think?
Thanks for nudging me by PM. I didn't notice this question, sorry.
As for the broadcast address, you *have* to expect that an interface
is broadcast capable and the ifa_broadaddr pointer is NULL. This
is at least true for all IPv6 entries. For IPv4 that shouldn't occur
under Cygwin.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Question for Corinna (was Re: Novice Question)
On Jul 1 19:46, Jon TURNEY wrote:
On 01/07/2009 16:42, Corinna Vinschen wrote:
On Mon, Jun 29, 2009 at 12:09:12PM +0100, Jon TURNEY wrote:
It seems that the (new for Cygwin 1.7) getifaddr() function can return
interfaces with IFF_BROADCAST IFF_UP set, but no broadcast address, which
the X server assumes never happens
[...]
As for the broadcast address, you *have* to expect that an interface
is broadcast capable and the ifa_broadaddr pointer is NULL. This
is at least true for all IPv6 entries. For IPv4 that shouldn't occur
under Cygwin.
The code in question (before I patched it) looks like this:
#if defined(IPv6) defined(AF_INET6)
if (family == FamilyInternet6)
/* IPv6 doesn't support broadcasting, so we drop out here */
continue;
#endif
if ((ifr-ifa_flags IFF_BROADCAST)
(ifr-ifa_flags IFF_UP))
broad_addr = *ifr-ifa_broadaddr;
else
continue;
XdmcpRegisterBroadcastAddress((struct sockaddr_in *)
broad_addr);
Staring at the code a bit, I think this means we have either an IPv4
interface, or an IPv6 interface with a mapped IPv4 address when the
broadcast address is looked at.
A v4inv6 address would also not have a broadcast info since it's still a
v6 address. For real v4 addresses the broadcast address is not provided
by Windows, but computed from address and netmask by Cygwin, so it's
always available.
However, without the actual interface data I can't tell. Maybe an
`ipconfig /all' sheds some light on this.
Oh, wait. Andy, please build and run the below test app under 1.7 with
$ gcc -o getifaddrs getifaddrs.c
$ ./getifaddrs
and paste the output into your reply, together with the `ipconfig /all'
output.
Thanks,
Corinna
=== START getifaddrs.c ===
#include stdio.h
#include sys/types.h
#include sys/socket.h
#include arpa/inet.h
#include netinet/in.h
#include net/if.h
#include ifaddrs.h
#define mk_addr(a) ((a) ? inet_ntop (AF_INET, ((struct sockaddr_in *)
(a))-sin_addr, buf, 256) : NULL)
#define mk_addr6(a) ((a) ? inet_ntop (AF_INET6, ((struct sockaddr_in6 *)
(a))-sin6_addr, buf, 256) : NULL)
int
main ()
{
struct ifaddrs *ifs, *ifp;
char buf[256];
if (getifaddrs (ifs))
{
perror (getifaddrs: );
return 1;
}
for (ifp = ifs; ifp; ifp = ifp-ifa_next)
{
if (ifp-ifa_addr-sa_family != AF_INET
ifp-ifa_addr-sa_family != AF_INET6)
continue;
printf (Name : %s\n, ifp-ifa_name);
printf (Flags: %x\n, ifp-ifa_flags);
switch (ifp-ifa_addr-sa_family)
{
case AF_INET:
printf (Addr : %s\n, mk_addr (ifp-ifa_addr));
printf (Mask : %s\n, mk_addr (ifp-ifa_netmask));
if (ifp-ifa_flags IFF_POINTOPOINT)
printf (Dest : %s\n, mk_addr (ifp-ifa_dstaddr));
else
printf (Bcast: %s\n, mk_addr (ifp-ifa_broadaddr));
break;
case AF_INET6:
printf (Addr : %s\n, mk_addr6 (ifp-ifa_addr));
printf (Mask : %s\n, mk_addr6 (ifp-ifa_netmask));
if (ifp-ifa_flags IFF_POINTOPOINT)
printf (Dest : %s\n, mk_addr6 (ifp-ifa_dstaddr));
else
printf (Bcast: %s\n, mk_addr6 (ifp-ifa_broadaddr));
break;
}
putchar ('\n');
}
freeifaddrs (ifs);
}
=== END getifaddrs.c ===
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Windows 7 RC1 and Cygwin 1.7
Hi Ben, sorry for the late response. That's what vacation does to you :} On May 19 21:04, richardvo...@gmail.com wrote: On Sat, May 16, 2009 at 4:41 AM, Corinna Vinschen As for the console windows popping up, thats a generic bug in the new console code in W7, affecting 32 and 64 bit versions. For some reason the AllocConsole call does not honor the fact that the application switched to another active WindowStation. Thus, console windows which are meant to be hidden in another, hidden WindowStation, are wrongly created on the desktop of the original, visible WindowStation. I reported this bug upstream as well, but unfortunately I got the reply that this bug won't be fixed in this Windows release. I'm still trying to convince Microsoft that this is a serious problem, though. Corinna, Do you have a link to a bug report on Connect? I'll upvote it. https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=443006SiteID=647 I don't know if upvoting will help, but it's worth a try, I guess. And should I download the latest release in order to validate this, or are there testing builds? I haven't installed Cygwin on my 64-bit Win7RC box yet but I need to, can't use any computer long without an ssh client. The problem is independent of any Cygwin release and actually independent of Cygwin at all. The above Connect issue even contains a bare Win32 testcase in source code. Are there any other bugs you'd like validated and upvoted? I'm not Well, there's this issue: https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=445558SiteID=647 The reply I got indicates that it's not yet clear if it will get a fix, though it's easy to reproduce. I don't think it's *very* critical, but I don't like the idea that a process tree can lose handles when the close-on-exec flag is set for console file descriptors. My other open issues are: https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=447597SiteID=647 Marked as resolved but I can still reproduce in the latest build. https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=447443SiteID=647 Has been fixed but introduces a new bug which I'm going to report today or tomorrow. A file not found on an NFS share now reports the wrong error code STATUS_OBJECT_PATH_NOT_FOUND instead of STATUS_NO_SUCH_FILE in the latest build. That's bad for Cygwin. But I still have to verify on a 32 bit system before I file the issue. https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=442994SiteID=647 is still heavily worked on. exactly sure how to reproduce that issue you found with the cost to access directories on NTFS increasing exponentially with nesting level well repro might not be hard but pinpointing MS-provided This is an old issue I reported as one of my MSDN cases. Given that it only occurs on NT kernels of the 5.x series and has been fixed in the 6.0 kernel, there won't be a fix for that. I already pulled it through all instances. After all, what's MVP status good for if not telling 'em they broke valuable cygwin stuff. Right :) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Windows 7 RC1 and Cygwin 1.7
On May 15 23:18, Christopher Faylor wrote: On Fri, May 15, 2009 at 01:22:23PM -0700, Mike Ayers wrote: P.S. That was speculation. Hopefully someone will have a real answer soon. This was already discussed in the main cygwin list. There is a workaround in the latest version of Cygwin 1.7.x. http://cygwin.com/ml/cygwin/2009-05/msg00477.html That's not a workaround for the problem with consoles popping up, but a workaround for a W7 x64 specific problem. There's a bug in the W7 x64 console code (which appears to be mostly rewritten in W7 anyway) which breaks DLL initialization in child processes which have no copy of the original console handles from console startup anymore. This bug has been reported upstream and is marked as being resolved, which hopefully means it will be fixed in the final W7 release. As for the console windows popping up, thats a generic bug in the new console code in W7, affecting 32 and 64 bit versions. For some reason the AllocConsole call does not honor the fact that the application switched to another active WindowStation. Thus, console windows which are meant to be hidden in another, hidden WindowStation, are wrongly created on the desktop of the original, visible WindowStation. I reported this bug upstream as well, but unfortunately I got the reply that this bug won't be fixed in this Windows release. I'm still trying to convince Microsoft that this is a serious problem, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X11R7 and rebasing
On Nov 19 14:30, Angelo Graziosi wrote: I have seen that after the release of X11R7, many problems are partially resolved by rebasing. Some time ago, I remember that on cigwin-apps list there was the suggestion that the package maintainer should build their packages adding '-Wl,--enable-auto-image-base' for DLLs. Has this be done for the recent release? If 'yes', just for curiosity, where, than, this need of rebasing comes from? --enable-auto-image-base is not a 100% solution because there is none. It just can ease the pain somewhat. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Issues with latest snapshot -- anybody else?
On Dec 12 08:07, Rodrigo Medina wrote: Hi, I have found that with cygwin1.dll-20061205 the XWin program never ends. It remains in the Windows list of process, but desappears from the cygwin list. The same happens to other programs too, like rxvt and run. The 20061023 works fine to me. I just tried startxwin.bat, startxwin.sh, and starting just rxvt. WJFFM. Maybe rebasing? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Vista RTM startxserver startxwin fail?
On Dec 1 21:39, Michael J. Wheeler wrote: tatus: RO Content-Length: 2639 Lines: 68 Please forgive me if I'm not posting this to the correct list... I've just done a fresh install of Windows Vista Business Enterprise. For some reason, I cannot get the cygwin X server to start. When I run either of the batch files in the subject, I get a popup message from the OS saying that sh.exe has stopped working. I could reproduce this error, then I straced it, then I changed to another DLL, then the error disappeared, then I switched back to the 1.5.22 DLL... and then the error *still* disappeared. From this time on I was totally unable to reproduce it. Go figure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Vista RTM startxserver startxwin fail?
On Dec 2 11:08, Michael J. Wheeler wrote: Sounds like the definition of a Bohr bug :) Looks like i'm using the 1.5.22-11 DLL. I didn't see an option in the setup to use a different version... How would I go about doing that? Either try the latest developer snapshot or build a new version from source. I did the latter with additional debug output. The problem still doesn't show up anymore, regardless of the version I use. You could also try stuff like rebasing to another base address, e.g. rebaseall -b 0x6500, rebase back to 0x7000, reboot, revert to the 1.5.22 DLL, whatever. Apparently *something* healed it for me. Maybe there's some self-healing feature within Vista... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: unixkill crashes under cygwin-1.5.20-1 (and cygwin1dll-20060707)
On Jul 8 08:32, Lester Ingber wrote: Corinna: I don't understand why I do not have any such crashes under cygwin1dll-1.5.19, but only with cygwin1dll-1.5.20-1 and the latest snapshot cygwin1dll-20060707? May I guess you didn't debug this situation? I did. Trust me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: unixkill crashes under cygwin-1.5.20-1
On Jul 4 13:21, Lester Ingber wrote: Has anyone else noticed that unixkill crashes under cygwin-1.5.20-1? When I press CNTL-ALT-BKSP, I do not get a confirmation prompt, my X windows do close, but I get an XWin.exe.stackdump -file and after getting out of Cygwin CNTL-ALT-DEL shows som hanging tcsh processes (my primary shell). This is a bug in the confirmation dialog routine in the 6.8.2.0 X server. That's fixed in 6.8.99.901. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
6.8.99.901-1 as current? (was Re: Testing snapshots - III)
On Mar 23 13:33, Angelo Graziosi wrote: For the sake of completeness. With the snapshots 20060322 the problems described in http://cygwin.com/ml/cygwin/2006-03/msg00624.html and in http://cygwin.com/ml/cygwin/2006-03/msg00435.html seem to be solved! I note, only, that after launching 'startxwin.bat', if one tries: mouse-3 on the X icon in the systray | Exit there is a stack dump and the XWin.exe.stackdup is created on the desktop. That's a bug in XWin. It just has not been present before due to a bug in newlib which has been fixed just a couple of days before. FWIW, the bug is apparently fixed in xorg-x11 version 6.8.99.901-1, which is available as test version using setup. Maybe we should make 6.8.99.901-1 the current version now? Is it stable enough for that? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Looking for Cygwin/X maintainer
On Mar 2 15:49, Alan Hourihane wrote: On Thu, 2006-03-02 at 10:45 -0500, Christopher Faylor wrote: Our Cygwin/X maintainer seems to have disappeared so it looks like we, once again, are looking for volunteers to be the go to person for Cygwin/X. That would mean building new releases, handling problems in this mailing list, and keeping the cygwin-xfree web site up-to-date. If you are interested please reply to this message. I'm still here, but v. busy. So if someone does want to take over - feel free. It would really be helpful for the Cygwin/X project if somebody could take over. We would really appreciate if somebody with more time to reply to problems on this list and to look for bug-fixes etc. would volunteer. Thanks in advance, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Looking for Cygwin/X maintainer
On Mar 2 17:28, Alan Hourihane wrote: On Thu, 2006-03-02 at 12:09 -0500, Christopher Faylor wrote: On Thu, Mar 02, 2006 at 05:00:48PM +0100, Corinna Vinschen wrote: On Mar 2 15:49, Alan Hourihane wrote: On Thu, 2006-03-02 at 10:45 -0500, Christopher Faylor wrote: Our Cygwin/X maintainer seems to have disappeared so it looks like we, once again, are looking for volunteers to be the go to person for Cygwin/X. That would mean building new releases, handling problems in this mailing list, and keeping the cygwin-xfree web site up-to-date. If you are interested please reply to this message. I'm still here, but v. busy. So if someone does want to take over - feel free. It would really be helpful for the Cygwin/X project if somebody could take over. We would really appreciate if somebody with more time to reply to problems on this list and to look for bug-fixes etc. would volunteer. And to clarify - both Corinna and I sent Alan personal email asking for feedback before I sent out my note. I wasn't trying to surprise Alan by sending that note. That's interesting - because I didn't get anything from either of you. Chris sent a mail on 2 Feb 2006, I'm cc'ed. I sent a follow-up mail on 20 Feb 2006, Chris was cc'ed. Both mails were sent to Alan Hourihane alanh AT fairlite DOT demon DOT co DOT uk Text: Hi Alan, Are you still interested in being the cygwin/x maintainer? I haven't seen much activity from you in the mailing list. I understand completely if you don't have the time for this but I think we need really need some active involvement on the mailing list and we probably need a new release as well. Should we open up this up for other volunteers? cgf My follow-up mail was just a ping. It's strange that both messages should be lost or being munched by a spam filter. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: port existing x windows application to win32
On Nov 10 11:19, Thomas Dickey wrote: On Thu, 10 Nov 2005, Michel Bardiaux wrote: So, I was right (rather than 'disregardable'). And that's from the horse's mouth, so to speak. Which brings back my query: is there a free but not GPL version of the X client libraries for Win32? rofl I have a better suggestion: since you don't understand any of the issues involved, perhaps you have some fellow employee who can understand the difference between cygwin's dll and libraries that may be distributed with it. I'm really wondering what you're up to. Michel's choice of words might be a bit unlucky, but it's a fact that his application will become GPL (or another compatible OSS license of choice), if he links it to the Cygwin/X client libs. This is obviously not a result of the X libs being GPLed, but a result of the fact that the Cygwin/X libs in turn require to link against the cygwin1.dll, or in other words, linking against Cygwin/X client libs will make the application a Cygwin application. So the question is still valid and was from the beginning, minus choice of words. However, this question is obviously off-topic for this list since this is the Cygwin/X list, not a native Win32 X list. So please move your question to another, more appropriate forum, Michel. Maybe you could start here: http://freedesktop.org/wiki/Xming Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Consensus about man and doc X11 directory structure
On Oct 10 21:59, Harold L Hunt II wrote: Charles Wilson wrote: Yaakov S (Cygwin Ports) wrote: [...] What's stopping us from moving the Win32 tcltk in /opt/win32, and making new *NIX tcl and tk packages in /usr? Then all that's necessary for insight is to add /opt/win32 to PATH (either through a script, profile.d, or manually). Similar packages (i.e. that have both X11/*NIX and Win32 flavors) could use /opt/win32 as well. All of this mucking about with tk and insight requires the concurrence of -- and oodles of extra work by -- the tk maintainer and the insight maintainer. Plus, speculation alert given the centrality of the debugger to the GNUPro product, this sort of change might meet resistance from the PowersThatBe channeled thru our local Benign Dictator(s). Umm... reality check: Fine with me. 1) How many of our BDs actually work for Red Hat anymore? 1 (one) 2) Is GNUPro even a product anymore? The only date I could find related to the product mentioned GNUPro 2001: http://www.redhat.com/software/gnupro/technical/gnupro_gdb.html Well, the marketing is fortunately not my job, but there is still a GnuPro product which is worked on regulary. Cygwin based toolchains are a part of it. 3) If Red Hat isn't updating any product that uses Cygwin to provide a product on Windows, then why are we holding onto this idea that we must continue to support something that was once sold? 4) If Red Hat is updating GNUPro, but doing a piss-poor job of telling people about it, then what are we? Red Hat's underground GNUPro development team? I guess I can let this go uncommented. I have no idea how the marketing in relation to GnuPro works. That's not my business, so I can't tell anything about it. The layout of the Cygwin distro is not exactly something important to the way GnuPro works, however. Tcl/Tk is shipped with the Cygwin based GnuPro toolchains, so where it is in the distro is free for discussion. But, apart from GnuPro, I don't think it's such a good idea to move the Windows-based Tcl/Tk DLLs out of /usr/bin without having a clear idea how the replacement should work for the Windows-based apps like Insight. Even better, I don't think the DLLs should be moved somewhere else at all. The POSIX-based DLLs should follow the Cygwin naming convention anyway, so they would have to be named cygtcl8.4.dll/cygtk8.4.dll (or whatever the version number is right now). They don't collide with the Win-based ones, so what? As for the other stuff (includes, libs, /usr/share/tk8.4, etc), I think this would be ok to be moved to /opt or /usr/lib/win or something. However, how to handle the tcltk package and as a result, the GDB package, is up to Chris, he's the maintainer after all, not I or Red Hat. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xrdb needs cpp, but i do not need gcc
On Sep 22 12:06, Corinna Vinschen wrote: On Sep 22 09:23, Karl-Olov Serrander wrote: Seems that xrdb uses cpp when processing .Xdefaults, but cpp is only included in gcc package. So xorg should depend on gcc but why not make cpp a separate package since gcc is a very large package ? I have already asked this in cygwin.xfree without any answers. Any comments ? Wrong mailing list. Redirected to cygwin-xfree. Please follow up there. Ouch, sorry. I didn't read your mail completely, obviously. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Apologies over using Subject line for 'reference'
On Sep 19 09:25, John Ormerod wrote: This might be off-subject, but I think has a general reference. I've used forums (or fora) and newsgroups for years, but I've never come across this format before. I couldn't find any guidance on how to use it, so it's all been guesswork - my first attempt had a subject something like Testing as I was unsure about the use of ' at dot com' rather than [EMAIL PROTECTED] for example. You should consider to use a real mail client like mutt or Thunderbird instead of a browser. This is a mailing list, not a web forum or a newsgroup, despite the fact that it's possible to read and write this mailing list via gmane. See http://cygwin.com/lists.html for more information about the available lists. Please don't reply to this mail since that's going off-topic pretty quickly. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
New Cygwin/X maintainer
May I introduce... Alan Hourihane has now officially taken over the job as our new Cygwin/X maintainer. We just have to put his access permissions to sourceware into place, but otherwise, that's it. Congratulations and a *big* thank you for taking over, Alan! 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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Spam: XFree86 maintainer
On Aug 23 09:19, Alan Hourihane wrote: On Mon, 2005-08-22 at 13:33 +0200, Corinna Vinschen wrote: On Aug 22 12:09, ?yvind Harboe wrote: I miss Alexander :-) Any word on a new cygwin-xfree maintainer? Unfortunately not. Is anybody willing to step up, perhaps somebody who already looked into the xfree sources more than once? If no one steps up for the job, then I'll volunteer. But my time is limited, so I won't be able to make releases at the frequency Alexander did. Thanks for the offer! It's worth a couple of gold starts. We'll just wait for cgf to wake up now... ;-) 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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Spam: XFree86 maintainer
On Aug 22 12:09, ?yvind Harboe wrote: I miss Alexander :-) Any word on a new cygwin-xfree maintainer? Unfortunately not. Is anybody willing to step up, perhaps somebody who already looked into the xfree sources more than once? 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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Is this SPAM!?
On Aug 15 11:19, Soong, SylokeJ wrote: How is it that is spam could get through cygwin-xfree-owner?? #:- (Grumpingly-Annoyedticon) And you're helping it to spread by FULL QUOTING IT. Congratulation! NEVER reply to spam which got through the filter. And don't reply to this mail. http://cygwin.com/acronyms/#PCYMTNQREAIYR http://cygwin.com/acronyms/#TOFU 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://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Base-files 3.4-1: Problems for users with Non-Admin. priv
On May 16 15:02, Alexander Gottwald wrote: Corinna Vinschen wrote: The t bit is absolutely correct to be set for /tmp. Why is that a problem for X? X should remove the X0 file when exiting, so that shouldn't be an issue. Alexander, is there a problem to remove the Xnum file on exit? This is standard behaviour for instance on Linux as well. If the xserver is shutdown normally the file is removed but if it's killed or exits unexpectedly, the file remains. This is not a problem on linux since the xserver has root privileges by default and can force the removal. Oh, this problem exists on Linux, too, sort of. Xvnc does not forcefully remove the file but instead it starts with the next free display number. We are not alone :-) I've changed the source to create the .X11-unix directory without the sticky flag. Removeing the directory should recreate it with the correct flags. Ok, thank you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Dresden 1945
On May 15 09:55, Christopher Mark Conn wrote: [EMAIL PROTECTED] writes: Lese selbst: http://www.kommunisten-online.de/blackchanel/dresden3.htm Is there some kind of spam filter on this list? I'm not sure what these articles are saying but I doubt it has anything to do with cygwin/x! If there wouldn't be a spam filer on this list you would see a lot more of this crap. Trust me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
[Fwd: configuring X, backspace, ....]
Wrong mailing list, redirected to cygwin-xfree. Corinna - Forwarded message from Christopher Graham Fenton - Date: Mon, 13 Dec 2004 11:30:32 +0100 From: Christopher Graham Fenton Subject: configuring X, backspace, To: Problem: backspace, cntrl-Z, cntrl-D, Norwegian characters. Weirdness. starting cygwin bash shell we have: backspace, cntrl-Z, cntrl-D but no Norwegian characters. yet if I start python or jython interactively we have Norwegian characters !!! However when I start X then xterm nothing works: No Norwegian characters, no cntrl-Z or cntrl-D (can't stop jython interperter), backspace is /b(8) syntax error, Attempted solutions. I generated the appropriate key mappings with xkeycaps but xmodmap Xmodmap.no does nothing Other solutions: Tell my boss to shove it and let some other poor sap develop for Windows :) Additional info Windows XP service pack 2 X started with X :0 export DISPLAY=:0 pekwm.exe # a small windows manager also in /etc/profile I change my $HOME directory to /home/Chris from the 'Documents and Settings' ... Anyone has similar problems, Chris - End forwarded message -
Re: problem with tty size in xterm
Wrong mailing list. Redirected to cygwin-xfree AT cygwin DOT com. On Sep 15 15:21, Thomas Wolff wrote: When an xterm is started that has about as many rows as fit on the screen, it may get positioned so that its bottom is beyond the screen bottom. In this case, the tty gets the wrong information about the window size. For example, the following windows shortcut on a 1024x768 screen resolution: D:\cygwin\usr\X11R6\bin\run.exe D:\cygwin\bin\xterm.exe -display localhost:0 -ls -u8 -fn 10x20 -fw -misc-fixed-medium-r-normal-ko-20-200-75-75-c-200-iso10646-1 -geo 80x36 makes the tty pretend to have 35 rows. With -geo 80x33 it works. After a window resize, it also always works. More symptoms: Actually the problem does not seem to depend on screen vs. window size but rather on the actual initial position of the window: Using the working setup (-geo 80x33) and starting a number of windows, which get positioned a little bit lower every time, the problem eventually shows up again On the other hand, on a 1600x1200 screen resolution, the problem may also occurs, even if the window is fully visible. Thomas Wolff -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
On Apr 3 22:26, Corinna Vinschen wrote: On Mar 30 09:30, Dr. Volker Zell wrote: I just tried your fix which seems to be in the 20040329 snapshot. But now /usr/sbin/cygserver doesn't start anymore. I installed it as a service with cygrunsrv. The same happens for my other cygwin service /sbin/init which also refuses to start. In the process list I could see 4 !! /bin/cygrunsrv processes so. Reverting to 1.5.9 and all is fine. Please try the 20040403 snapshot. It contains a fix for the shmat problem which shold allow the bigfont extension to work. Corinna P.S: And somehow I'd wish you'd use a more space-saving and more concise quoting style... Ping? Did you test it? Does no feedback mean that it now works? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: SHM extension fails to start
On Apr 8 17:30, Charles L. Werner wrote: I tried the suggested command from the Cygwin bash command line and the SHM extension still fails: I tried to find documentation on cygserver, but all there is dead links in the cygwin users guide. I assume the CYGWIN environment variable is being set by suggested command. There is no info for this option in the users guide for the CYGWIN I'll upload the missing html file in a minute. In the meantime you can find the same documentation in /usr/share/doc/Cygwin/cygserver.README on your local hard disk. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: Shouldn't we put [cygwin] or [CygXwin] here depending on the question?
On Apr 2 13:51, Michel Bardiaux wrote: Christopher Faylor wrote: That's a shame, but please don't ask us *US* ? I am not at all sure the majority of the members agree with the peremptory refusal expressed by a very few. Well, us in that case is the royal us. Subject tagging won't happen, so there's no gain in discussing that further. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
On Mar 26 19:24, Corinna Vinschen wrote: On Mar 26 11:18, Harold L Hunt II wrote: Corinna Vinschen wrote: keen to debug it. From what I can tell, the shmctl call works fine. After that call, the XFreeFont() function accesses a piece of data, 512 bytes before the address of the buffer used as third argument to shmctl(). This address (buffer - 512) results in the SEGV. [...] I'll have to see if I can reproduce this and maybe make a debug compile (takes about 2 hours, ugh). Thanks you. Just a correction: I misinterpreted the address by 1 hex digit. The address is 32 bytes before the buffer, not 512 bytes, sorry. I've build my own debug version of the X stuff today and I tracked the SEGV down. It's an unfortunate combination of two bugs in the SHM implementation: - shmat() returns NULL on error instead of (void *)-1. - shmat() only operates on shared memory segments of which the shmid has been retrieved using shmget() by the application itself. I was absolutely sure that only the key argument to shmget() is a valid interprocess exchange value for identifying shared memory segments. I wasn't aware that the shmid itself could be exchanged. For today, I only fixed the first bug. This fixes the SEGV in uxterm and friends, but a fix for the second bug is necessary to get a working Bigfont extension. I hope to get this done next week. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
On Mar 25 19:12, Dr. Volker Zell wrote: Ok here my debug attempts. Following is the output of /var/log/cygserver.log when starting xfontsel. After the -- snip -- you'll find the lines which showed up when xfontsel crashed. For this run I started the XWin server without the env variable XF86BIGFONT_DISABLE. Doesn't seem very useful so. Nope, the output of cygserver doesn't indicate anything. And the normal log output is missing since it's still gone to the event log. Btw., you can start cygserver under administrator account in a console. That's sufficient from the user rights perspective and you can easily redirect the log which goes to stderr then by default. Attaching to program `/usr/X11R6/bin/xfontsel.exe', process 1624 Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Program received signal SIGSEGV, Segmentation fault. Well... that's even less helpful with no debug symbols in the binary. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
On Mar 25 13:38, Harold L Hunt II wrote: Volker, Using the Cygwin Way-Back Machine (http://cygwin.get-software.com/release/XFree86/XFree86-xserv/) I have retrieved a copy of XFree86-xserv-4.3.0-55 which is immediately prior to the change from cygserver to cygipc. I would like you to test this version and verify whether you can or cannot reproduce the problem with cygipc. It is always possible that this is just a bug in the big font extension that we have not noticed before. To retrieve the -55 version, point setup.exe to: http://www.egr.msu.edu/~huntharo/cygwin_old/ That's a good idea, thank you. Other than that, I'm not at all familar with that stuff. How can I set up a minimal test system, so that it uses the bigfont extension and, especially, IPC? Yesterday I just started cygserver, XWin and uxterm, and it doesn't use IPC by default, apparently. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
On Mar 26 09:23, Harold L Hunt II wrote: Corinna Vinschen wrote: Other than that, I'm not at all familar with that stuff. How can I set up a minimal test system, so that it uses the bigfont extension and, especially, IPC? Yesterday I just started cygserver, XWin and uxterm, and it doesn't use IPC by default, apparently. As long as you have cygserver started and CYGWIN=server defined in a way Ouch. I started XWin from Windows Explorer, not thinking about setting CYGWIN=server at all. I've build my own xterm to have a debug version. Unfortunately, it doesn't happen in xterm, but in cygX11-6.dll, in function XFreeFont(), right after shmctl(id, IPC_STAT, buf) has been called. I don't have a debug version of cygX11-6 and I'm also not exactly keen to debug it. From what I can tell, the shmctl call works fine. After that call, the XFreeFont() function accesses a piece of data, 512 bytes before the address of the buffer used as third argument to shmctl(). This address (buffer - 512) results in the SEGV. Could you have another look into this? Actually I don't see anything wrong with the semctl call, it even checks the buffer pointer for being accessible. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
On Mar 26 11:18, Harold L Hunt II wrote: Corinna Vinschen wrote: keen to debug it. From what I can tell, the shmctl call works fine. After that call, the XFreeFont() function accesses a piece of data, 512 bytes before the address of the buffer used as third argument to shmctl(). This address (buffer - 512) results in the SEGV. [...] I'll have to see if I can reproduce this and maybe make a debug compile (takes about 2 hours, ugh). Thanks you. Just a correction: I misinterpreted the address by 1 hex digit. The address is 32 bytes before the buffer, not 512 bytes, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: About box
On Mar 26 11:12, Harold L Hunt II wrote: Yes, it seems inconsistent to me. Cygwin/X is different than a port of package foo to Cygwin: Cygwin/X is an integral piece of Cygwin and runs *only* on Cygwin; it is much more important than a port. I've moved the link to the Cygwin/X page up to be the second link in the left menu bar. This way, Cygwin/X got a sufficiently prominent place in the menu and both pages have a more similar menu layout. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
[Fwd: ForwardX11Trusted]
FYI: - Forwarded message from Colin Watson - Date: Tue, 9 Mar 2004 15:44:20 + From: Colin Watson Subject: ForwardX11Trusted To: openssh-unix-dev PLAM mindrot DONG org Since packaging OpenSSH 3.8p1 for Debian, I've got a flood of bug reports and confusion about the new untrusted X client configuration. At least part of this seems to be the short (2 minutes!) timeout on the cookie, so that if you're impatient like me and open a connection to a machine that takes a little while to do the key exchange, go off and do something in another window in the meantime, and then come back when it's finished, you may well find that the untrusted cookie's expired in the meantime. This seems a bit excessive. Would anyone think I was crazy for defaulting to ForwardX11Trusted in our OpenSSH package for a while until this becomes more mature? At least then we don't regress. ___ openssh-unix-dev mailing list - End forwarded message - So, other OSes have problems with ForwardX11Trusted as well :-| Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: OpenSSH configuration and many recent problems
On Mar 8 14:21, Harold L Hunt II wrote: Corinna Vinschen wrote: Especially I don't see why this setting should have another default on Cygwin as on any other OS. There's no difference between Cygwin and other OSes which justifies this measure, right? The only difference I can think of is that none of the other ssh implementations (that I know of) on our platform, such as PuTTY and SSH Secure Shell, enable this feature by default (or even have this feature). I'm more concerned about differences between OpenSSH installation on different OSes, not about other SSH implementations, actually. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: OpenSSH configuration and many recent problems
On Mar 8 14:17, Alexander Gottwald wrote: On Mon, 8 Mar 2004 [EMAIL PROTECTED] wrote: Hi all, just wanted you to know, that OpenSSH 3.8 configuration seems to be the reason for some of the recent problems presented here (e.g. AltGr not working, emacs crash). I've had those problems, too. Takuma Murakami suggested that I checked my OpenSSH configuration. When I added ForwardX11Trusted yes to /etc/ssh_config, all my problems went away. This is a very big problem. We get about 2 bugreports per day on the cygwin-xfree mailing list. What about making the X11ForwardTrusted default on cygwin? I'm not actually keen to change another default setting of OpenSSH to an unsafe setting on Cygwin by default. It's bad enough to set StrictModes to no by default and I already have stomach pain due to that. Especially I don't see why this setting should have another default on Cygwin as on any other OS. There's no difference between Cygwin and other OSes which justifies this measure, right? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: importlibraries names
On Tue, Aug 26, 2003 at 03:44:02PM +0200, Gerrit P. Haase wrote: Hallo, the importlibraries are named libxyz.dll.a (or the symlinks to the actual libraries are). This is not a problem for the linker which will pick them up when -lxyz is specified. But I have some configuration scripts which are looking for libX11.a in the libdir which is pretty usual. Would it be a problem to create the symlinks to be libxyz.a instead of libxyz.dll.a in future releases or use the same names of the importlibraries as it was before, without version included? No. There are two types of import libs: libfoo.dll.a which results in linking against the apropriate DLL and libfoo.a which is the static lib. This scheme has been settled already lng ago and is obeyed by binutils. If the configuration script gets this wrong, the configuration script should be fixed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: posted: X4W: Limited Cygwin on CD-ROM
On Mon, Aug 11, 2003 at 09:40:06PM -, M.Vaseer wrote: Title: X4W: Limited Cygwin on CD-ROM Url:http://www.vaseer.net/~portal/my- work/projects/x4w/x4w.html Type: Software Author: M. Vaseer Email: x4w at vaseer dot net Date: 2003-08-11 Text: A limited version of Cygwin/XFree86 project, which can either be installed on a harddrive or run directly from a CD-ROM drive with minimum installation. I saw on your web page that you just point to other web sites for the sources. To adhere to the GPL, it's not sufficient to point to the sources in question on other web sites. You must be able to provide the sources in the same way as you provided the binaries. You must either pack the sources which you used to create the CD content onto the CD itself, or you must provide them by another CD, or you might upload the sources to your web site and link to these sources. This has been discussed on the Cygwin mailing list in length and it's backed by the Red Hat lawyers. So I ask you to upload the sources to your site and provide them to potential users of your CD in one of the above ways. Other than that, I'm not keen to provide a pointer to potentially outdated Cygwin and XFree86 versions on the cygwin.com homepage. I'm especially sure that nobody on the cygwin and cygwin-xfree mailing lists will like the idea to support a foreign Cygwin installation. So, please mention on your site, that the Cygwin mailing lists will not be the right forum to ask questions related to your installation. I've Cc'd the cygwin and cygwin-xfree mailing lists to keep people informed. Please send all further inquiries to the [EMAIL PROTECTED] ML. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: multiwindow segmentation fault
On Wed, Jan 15, 2003 at 01:07:46PM +0100, Alexander Gottwald wrote: On Wed, 15 Jan 2003, J S wrote: Kensuke, I'm not an expert on gdb but managed to get the following debug info for you. Also in answer to Harold's question I only have one cygwin1.dll. Program received signal SIGSEGV, Segmentation fault. 0x77e8c40c in _libkernel32_a_iname () No. This is not the right point. If the segfault occurs in _libkernel32_a_iname you can continue debugging with c until another segfault occurs at another place. The information given by that backtrace is completely useless since XWin as well as the Cygwin DLL don't contain debugging symbols. The addresses have no meaning w/o that info. The only interesting fact in the backtrace is: #0 0x77e8c40c in _libkernel32_a_iname () #1 0x0001 in ?? () At this point, a function at address 1 (obviously a wrong pointer) is called #2 0x6103f35f in _libkernel32_a_iname () from *any* function in the Cygwin DLL #3 0x6103f38b in _libkernel32_a_iname () #4 0x6107b7df in _libkernel32_a_iname () #5 0x6107baba in _libkernel32_a_iname () #6 0x0043b838 in _size_of_stack_reserve__ () which has been called from *any* function in XWin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ITP]: Qt-2.3.1
On Thu, Jul 25, 2002 at 05:05:52AM -0700, Nicholas Wourms wrote: Harold et al., After a brief discussion this morning, Ralf has given me permission to package QT-2.3.1 and release it to the Cygwin community. I would like to have it under the XFree86 dir, since it is a fully native X library. This release has been throughly tested by us over on the KDE-Cygwin project, pretty much all the bugs have been stomped out. Note that QT does *not* require MIT-SHM [that is kde itself]. Furthermore, I fully intend and expect questions regarding Qt be redirected to the kde-cygwin mailinglist. We should probably update the mailing-lists page's policies to reflect this. My intention is not to inundate this list with Qt/Kde related issues. With the your's and the list's permission, I will package it up and provide the links ASAP. Are you sure that we don't get licensing issues here? AFAIK, Qt is (roughly) only free when running on a free OS. Basically we're still running on Windows... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [packages] gtk+, glib, imlib
On Fri, Jul 12, 2002 at 12:04:54PM +0200, Lapo Luchini wrote: Being interested in porting freeciv with gtk+ support... and gtk+ package being not available... I'm investigating it =) Harold states he has not enough time for it ( http://sources.redhat.com/ml/cygwin-xfree/2002-06/msg00302.html ). But has he a partial work or nothing? Steven has a fairly complete Gnome port on his page ( http://homepage.ntlworld.com/steven.obrien2/ ), which has nothing to do with Harold's work. It contains patches for many Gnome programs, including glib-1.2.10, gtk+-1.2.10 and imlib-1.9.14. I don't know about imlib but glib-1.2.10 and gtk+-1.2.10 compile OOTB. I built them to create a gvim locally. There was just one problem in glib/gstrfuncs.c. There's an extern declaration for strsignal() which collides with a Cygwin header. Just add a #ifndef __CYGWIN__ to the extern declaration and you're done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: setup.exe and inuse files for X
On Wed, May 01, 2002 at 04:58:36PM +1000, Robert Collins wrote: I think I've got a handle on this... looks like read only (-r--r--r--) files don't delete properly, so setup fails to overwrite them. Patches gratefully accepted, it's going in the TODO for now. I recall having sent a patch for this a few months ago to the cygwin-apps list... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: problem - system api on winnt
On Thu, Jan 17, 2002 at 05:21:58AM -0800, Brian Genisio wrote: Wrong Group. I have forwarded your question to [EMAIL PROTECTED] This group Unecessarily. He already cross posted to both groups :-( Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
