|
From: Ethan A M. <sf...@us...> - 2017-07-06 19:32:23
|
On Thursday, 06 July, 2017 13:59:04 Daniel J Sebald wrote: > On 07/06/2017 01:23 PM, sfeam wrote: > > On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote: > >> On 07/05/2017 05:08 PM, Petr Mikulik wrote: > [snip] > >>> I 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 > >> have pre-processor conditionals: > >> > >> #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, > >> and there is a convenient definition for that: > >> > >> 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 > >> with the inclusion of XInitThreads() here: > >> > >> 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 > > to run-time. You can test this by configuring like this: > > > > ./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. Ethan |