Post by Ethan A Merritt via gnuplot-betaPost by Daniel J Sebald[snip]
Post by sfeam via gnuplot-betaPost by Daniel J SebaldPost by Petr MikulikI think that ./configure is the place for tests of compile conditions.
There can be some simple case testing whether "-lX11" is needed or not.
Is such a workaround possible?
The necessary tests are already present. The hunks of code that matter
#if defined(WX_NEEDS_XINITTHREADS) && defined(X11)
#include <X11/Xlib.h> /* Magic fix for linking against wxgtk3.0 */
#endif
and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the
configure process.
We only want to include library -lX11 for the building of wx_gui.cpp,
Makefile:LIBRARIES_FOR_X = -lX11
The included libraries for wx_gui.cpp are gotten from the wx-config
command as discussed earlier, and it shows up as
Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread
-lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0
-lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0
-lwx_baseu_net-3.0 -lwx_baseu-3.0 -lpangocairo-1.0 -lpango-1.0 -lcairo
-lgobject-2.0 -lglib-2.0
So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if
XInitThreads() is used in the wx_gui code. If X11 is not present,
LIBRARIES_FOR_X should be empty.
I've attached a six-line patch to the original bug report associated
https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch
Unfortunately that doesn't work.
As it shows in the original bug report, wxgtk stupidly insists on the
XInitThreads business *even if the program doesn't use X11*.
So making gnuplot's configuration rely on LIBRARIES_FOR_X doesn't
resolve the original problem. It just moves the failure from compile-time
./configure --without-x --without-gd --with-wx
Your patch allows it to compile without complaint, but then you get
a run-time failure instead because wxgtk aborts when it finds that
XInitThreads was not called.
This is actually worse than the compile-time failure because at that
point it's too late to fix the problem.
Hence the warning in the Release Notes.
I see your point. However, the user is requesting no X11, the
consequence of which is a crash. We could drop the "&& defined(X11)" in
which case configuration will succeed but compilation then fail. That's
probably no better, so in addition to that we could place an error in
configure.ac when wx_needs_xinitthreads is "yes" and X11 is not present.
It isn't the wxgtk library that wants X11, it's gnuplot's use of
XInitThreads() that requires X11. wxgtk configure can't anticipate our
use of an X function.
No! no! no!
You've got this exactly backwards.
The _only_ reason gnuplot calls XInitThreads is because otherwise
wxgtk aborts. The call was inserted in gnuplot to work around
precisely this wxgtk bug. Gnuplot itself makes no other calls into
the X11 library.
IMHO this is clearly a wxgtk library bug, introduced in version 2.9.
If it really wants a call to XInitThreads, let it make that call
itself rather than issuing a useless error message and aborting.
I'm afraid the reliability of the wxgtk library dropped significantly
after version 2.8. See for example Allin Cotrell's problem from
earlier today. My recommendation is that if you can link gnuplot
against wxgtk 2.8 rather than 2.9 or 3.0 you should do so.
Things may have simply changed with gtk 3.0 such that it isn't as
forgiving in some respects, I don't know. Security issues, etc. I
haven't looked at any of WX or GTK code, but I suspect that WX is going
a posix route and just doesn't concern itself with the X-windows levels.
I'm guessing that because the notes of wxThread state:
http://docs.wxwidgets.org/trunk/classwx_thread.html
"There are two types of threads in wxWidgets: detached and joinable,
modeled after the POSIX thread API."
I'm holding off on the conclusion that GTK overlooked using
XInitThreads() somewhere because it could be gnuplot's fault for doing
graphics in a secondary thread. Maybe the secondary thread is sending
some graphics X code through the system that shouldn't be present.
That's speculation; but here is what the wxThread documentation says:
http://docs.wxwidgets.org/trunk/classwx_thread.html
"
wxWidgets Calls in Secondary Threads
All threads other than the "main application thread" (the one running
wxApp::OnInit() or the one your main function runs in, for example) are
considered "secondary threads".
GUI calls, such as those to a wxWindow or wxBitmap are explicitly not
safe at all in secondary threads and could end your application
prematurely. This is due to several reasons, including the underlying
native API and the fact that wxThread does not run a GUI event loop
similar to other APIs as MFC.
A workaround for some wxWidgets ports is calling wxMutexGUIEnter()
before any GUI calls and then calling wxMutexGUILeave() afterwords.
However, the recommended way is to simply process the GUI calls in the
main thread through an event that is posted by wxQueueEvent(). This does
not imply that calls to these classes are thread-safe, however, as most
wxWidgets classes are not thread-safe, including wxString.
"
The second paragraph above could be very relevant (Qt has this same
restriction). This is what I'm trying to figure out: Is wx_gui doing
graphics in the secondary thread? The third paragraph too might be
important, as I see the following in the custom wxtThread::Entry() function:
/* Workaround for a deadlock when the main thread will Wait() for this one.
* This issue comes from the fact that our gui main loop is not in the
* main thread as wxWidgets was written for. */
wxt_MutexGuiLeave();
I activated FPRINTF() in wxt_gui.cpp to see at what point the process
exits prematurely:
Terminal type is now 'wxt'
Options are '0 enhanced'
gnuplot> plot sin(x)
Init
First Init
OnInit
OnInit finished
First Init2
opening a new plot window
secondary thread entry
wxtApp::OnCreateWindow
wxtFrame constructor
wxtFrame constructor 2
frame OnSize
panel constructor
panel constructor4
wxt_cairo_create_context
panel constructor5
panel constructor6
wxtFrame constructor 3
frame OnSize
panel OnSize 640 384 7680.000000 7680.000000
wxt_cairo_create_context
wxt_cairo_refresh called before window exists
new plot window opened
Init finished
Graphics xmax 12800 ymax 7680 v_char 339 h_char 160
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.
gnuplot: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion
`!xcb_xlib_unknown_req_in_deq' failed.
Aborted
It looks like "new plot window opened" might be the source, i.e.,
wxWindow. Recall there is lag in processing X so it isn't necessarily
the last commands that are the source.
Again, it takes a little while to digest thread code, but inside
wxtThread::Entry() is the following:
/* gui loop */
wxTheApp->OnRun();
/* Workaround for a deadlock when the main thread will Wait() for this one.
* This issue comes from the fact that our gui main loop is not in the
* main thread as wxWidgets was written for. */
wxt_MutexGuiLeave();
Is this "gui loop" indicating that the GUI is in fact being run in the
secondary thread? Or is it just launching something from the secondary
thread? I'm starting to get the feeling this might explain why I often
see the WXT terminal plot windows not close when I exit gnuplot. (It's
time consuming to close all windows individually.)
So, what I'm going on at this point is:
1) It looks like the graphics may be running in a secondary thread.
2) wxWidgets documentation states "GUI calls are explicitly not safe at
all in secondary threads and could end your application prematurely."
The contra-positive logic doesn't necessarily conclude that the source
of the problem therefore lies in gnuplot. Plus it is a lot of work to
test the theory that rearranging wx_gui so that GUI manipulation is only
done in the main thread. So, for me it's inconclusive from my
understanding just who's responsible for the need for XInitThreads().
Dan