Patch request to qt 5.9.4
Mark Geisert
mark@maxrnd.com
Wed Mar 13 08:33:00 GMT 2019
On Wed, 13 Mar 2019, Tatsuro MATSUOKA wrote:
[...]
>>> I have prepared binaries:
>>> http://tmacchant3.starfree.jp/gnuplot/Eng/cyg_qt_test/
>>>
>>> test
>>> From gnplot prompt
>>>
>>> gnuplot> set terminal qt
>>> gnuplot> plot x
>>>
>>> Without Qt patch
>>>
>>> Could not connect to existing gnuplot_qt. Starting a new one.
>>>
>>> Warning: slow font initialization
>>>
>>>
>>>
>>> With Qt patchplot appears
[...]
> One note: for gnuplot.exe and gnuplot_qt.exe, debug symbols are not stripped and
> you can trace gdb but I did not know debug info for Qt.
I believe I've found the root cause of this issue of outbound connect on a
non-blocking socket not working under Cygwin.
It's in Qt's qlocalsocket_unix.cpp. On line 285 there's a call to
qt_safe_connect(). At this point the socket fd has already been set
non-blocking. Within qt_safe_connect() there's a call (eventually) to
Cygwin's connect(). That connect() is returning -1 with errno set to
EINPROGRESS.
Back in qlocalsocket_unix.cpp, line 287 does a 'switch(errno)' but doesn't
have a case for EINPROGRESS. That error condition reaches the 'default:'
case, returning without the connection being completed. I don't know why
there's no error report to the user.
Note that you don't want to quick-fix this by adding a 'case EINPROGRESS:'
that simply acts like the connection is completed. I think somebody who
knows Qt network internals will have to develop a real fix.
It seems nobody has run across a non-blocking connect() that doesn't
immediately complete connection.. but Posix mandates an EINPROGRESS error
in that situation so Cygwin appears to be doing the right thing.
..mark
-------------- next part --------------
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin
mailing list