This is the mail archive of the
cygwin-xfree
mailing list for the Cygwin XFree86 project.
Re: Cannot run Qt5 applications.
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: cygwin-xfree at cygwin dot com
- Date: Tue, 03 Mar 2015 14:48:58 +0000
- Subject: Re: Cannot run Qt5 applications.
- Authentication-results: sourceware.org; auth=none
- References: <54D2A922 dot 3060507 at tiscali dot co dot uk> <54D2CA12 dot 5080701 at dronecode dot org dot uk> <54DE4334 dot 9060101 at dronecode dot org dot uk> <1425339264 dot 7292 dot 8 dot camel at cygwin dot com> <20150303090407 dot GA31622 at calimero dot vinschen dot de>
- Reply-to: cygwin-xfree at cygwin dot com
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 +0000, 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/