[ANNOUNCEMENT] cygwin-xfree list deprecation
Dear Internet, It no longer makes much sense to have a separate list for Cygwin X related traffic, so the cygwin-xfree list is now officially deprecated. Reasons for this decision include: - the level of traffic on the cygwin-xfree list is low - splitting the traffic in this way currently serves no useful purpose - the distinction between what is and is not an X issue is artificial, vague, and often ignored The cygwin-xfree list will continue to operate, but I suggest and encourage you to use the main cygwin list for all your cygwin X server and X application related questions, bug reports, moans, gripes, whines and patches ;-). The Cygwin X website and documentation will be updated to point to the main cygwin list. Mail delivery for the cygwin-xfree list may be turned off at some future date, but even if that happens, the list archives will continue to be available. Live Long and Prosper, Jon -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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/
[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 03/03/2015 09:04, Corinna Vinschen wrote: 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)? I think it was a BSD-ism to raise SIGSYS if shared memory is not available due to policy. Historically, there must have been some OS which did this, because there is code to detect this situation in the X server [1] [1] http://cgit.freedesktop.org/xorg/xserver/tree/Xext/shm.c#n167 Looking at [2],[3] it seems perhaps this was added in Cygwin because some FreeBSD test code was used? [2] https://cygwin.com/ml/cygwin-cvs/2003-q4/msg00130.html [3] https://cygwin.com/ml/cygwin-cvs/2003-q4/msg00128.html I'd kind of assumed that modern BSDs behave in the same way, but that doesn't actually seem likely. I have absolutely no problem with changing this to return ENOSPC (there is a limit of 0 SHM identifiers, and we have reached it), or whatever is appropriate in this state. 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. I'll also note that checking once at startup, as the X server does, is not enough. If the cygserver is stopped, it will die with an unexpected SIGSYS when a client tried to use shared memory. Of course, it would be nice if Qt5 used POSIX shared memory objects instead, but that's asked too much, probably. Unfortunately, it has to use whatever the X server's MIT-SHM extension uses... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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 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
