gnuplot-beta — Developers and beta testers of new gnuplot code

Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

On Friday, 14 July, 2017 07:36:26 Tatsuro MATSUOKA wrote:
> > 6) Any other known issues?
> >
> >     Ethan
> >
> This is not an issue but documentation problem for source distribution.
> In source distribution, there is a file named "INSTALL".
> It is well written but some parts are obsoleted or inadequate.
> 
> e.g.
> 
> 1. 
> Unix, configure
> ---------------
>     
> TERMLIBS="-lX11" ./configure
> is required for wxwidgets but is not described
> 
> 2.
> MS-Windows
> ----------
> 
> There's no installer for gnuplot, so if you want a desktop link,
> program manager group or an association of *.plt or *.gpl files to
> wgnuplot, you'll have to do all that yourself.
> 
> The gnuplot for windows has installer now.
> 
> 
> *********************
> There are much points which are not up-to-date.

Good point.
The FAQ, the man page, and the LaTeX tutorial are even more out of date.
Contributions are welcome for all of these.

The same is true for the web site.
The front page is not bad, but the linked pages are getting stale.


> Is it better open a bug ticket for "INSTALL" being up-to-date?

A bug ticket is less useful than a patch containing new text.
Or contribute new text by posting it here on the mailing list.

	Ethan



> Tatsuro

Re: 5.2 rc2 tarball now available

[Tatsuro M. <tma...@ya...>]

> 6) Any other known issues?
>
>     Ethan
>
This is not an issue but documentation problem for source distribution.
In source distribution, there is a file named "INSTALL".
It is well written but some parts are obsoleted or inadequate.

e.g.

1. 
Unix, configure
---------------
    
TERMLIBS="-lX11" ./configure
is required for wxwidgets but is not described

2.
MS-Windows
----------

There's no installer for gnuplot, so if you want a desktop link,
program manager group or an association of *.plt or *.gpl files to
wgnuplot, you'll have to do all that yourself.

The gnuplot for windows has installer now.


*********************
There are much points which are not up-to-date.
Is it better open a bug ticket for "INSTALL" being up-to-date?

Tatsuro

Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

On Tuesday, 04 July, 2017 17:26:11 Petr Mikulik wrote:
>  	Hello,
> 
> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) - 
> linking fails.
> 
> It is this problem:
>      https://sourceforge.net/p/gnuplot/support-requests/196/
> 
> The workaround
>      configure --with-X11
> described above does not help, while
>      TERMLIBS="-lX11" ./configure
> let me gnuplot compile.
> 
> Can this be fixed?
> 
> ***
> 
> Further, I can see that
>  	set term qt; test
> does not pass the test of character width (testing rectangle is too narrow), 
> while x11 and wxt pass well.
> 
> ***
> 
> Those two dummy terminals show 90123456789 instead of 0123...90123...9 in the 
> character width test:
>  	set term dumb; test
>  	set term caca; test
> 
> ***
> 
> Is caca still experimental?
> It's just fun, but it's nice, mouseable and it seems to work, so I propose to 
> have it not experimental.
> 
> ***
> 
> Greetings,
>    Petr

Updates:

1) Auto-detection of a wxt on linux requirement for 
	TERMLIBS="-lX11" ./configure

No solution.  The weak point is the wxgtk3 library.
It has several runtime glitches in addition to this configuration issue.  
I do not expect a fix for 5.2  This is a real problem but I don't see
anything we can do about it other than to recommend against using wxgtk
versions higher than 2.8

2) Qt text boxes

I have modified the "test" command to show both the true bounding box
as used by the current terminal (shaded rectangle) and the generic
estimated bounding box used by the core program to reserve space for
text in a plot layout.  It seems some Qt versions report an inaccurate
bounding box width for some fonts (e.g. Qt 5.6.2 + DejaVu Sans).
Nevertheless the terminal's internal bounding box is always more accurate
than the generic estimated box.

Dan Sebald has pointed out that the Qt terminal and the cairo terminals
differ in whether they increase the lower bound of the bounding box to
allow for font descenders.   This is probably fixable but I consider it a
minor issue.  

3) caca terminal still EXPERIMENTAL?

I have libcaca 0.99 beta18.  The gnuplot caca terminal reports:
set term caca driver list
    x11 gl slang ncurses raw null

For me the x11 and gl options are usable although the x11 font handling
has artifacts.  slang and ncurses spew garbage.  raw and null cause
segfaults.  Most of the time changing a caca option causes gnuplot to exit.
So yes, I think we need to warn that the caca terminal is still EXPERIMENTAL.

4) autoconfigure/compile on SunOS

Minor issues only.  The demo for building and linking plugins does
not autoconfigure correction but can be built manually following instructions
in the plugin demo Makefile.
See also various notes attached to Bug #1821

5) Unwanted inclusion of Type 3 fonts in cairo pdf output

The is Bug #1868.  No fix known.   Not a release-blocker.
It would be great if someone would pursue this with the cairographics
project maintainers.

6) Any other known issues?

	Ethan

Re: AW: Is minimal required platform Windows 7 only for the 5.3 or later for gnuplot for windows?

[Allin C. <cot...@wf...>]

On Tue, 11 Jul 2017, Tatsuro MATSUOKA wrote:

> Thanks for the reply.
> I understand the situation.
>
> I really appreciate your successive efforts specially on gnuplot 
> for windows.

Me too, Bastian has done a very nice job.

But your "support for XP" question is similar to one I asked a while 
back about support for mingw ("plain old" minGW as opposed to 
MingGW-w64). It may well be time to drop support for old 
Windows-related software, but I think this should be made clear in 
the ChangeLog and among the "config" files in the source tree. You 
cannot compile current gnuplot for Windows using plain old minGW any 
more, though the presence of files such as config.mgw suggests 
otherwise.

Allin Cottrell

> ----- Original Message -----
>> From: Bastian Märkisch
>> To: 'Tatsuro MATSUOKA' ; gnuplot-beta
>> Cc:
>> Date: 2017/7/10, Mon 16:08
>> Subject: AW: Is minimal required platform Windows 7 only for the 5.3 or later for gnuplot for windows?
>>
>> For 5.2 this hasn't changed in syscfg.h. If the Direct2D windows terminal
>> backend is included in the build, the executable will only run on Vista SP2
>> with platform upgrade or later, though.  Moreover there could be
>> restrictions implied by the libraries and compiler chain used, in particular
>> Qt.
>>
>>   Bastian
>>
>>>  -----Ursprüngliche Nachricht-----
>>>  Von: Tatsuro MATSUOKA [mailto:tma...@ya...]
>>>  Gesendet: Sonntag, 9. Juli 2017 23:30
>>>  An: gnu...@li...; bma...@we...
>>>  Betreff: Is minimal required platform Windows 7 only for the 5.3 or later
>> for
>>>  gnuplot for windows?
>>>
>>>  I saw the below in the ChangeLog in cvs branch source
>>>
>>>  2017-07-07  Bastian Maerkisch  <bma...@we...>
>>>          <snip>
>>>      * src/syscfg.h:  Minimum required API version is Windows 7 by
>>>      default.  Vista and XP are end-of-service.
>>>
>>>
>>>  For gnuplot 5.2.x, is minimal required platform windows XP?
>>>
>>>  Tatsuro

Re: AW: Is minimal required platform Windows 7 only for the 5.3 or later for gnuplot for windows?

[Tatsuro M. <tma...@ya...>]

Hello

Thanks for the reply.
I understand the situation.

I really appreciate your successive efforts specially on gnuplot for windows.

Tatsuro



----- Original Message -----
> From: Bastian Märkisch 
> To: 'Tatsuro MATSUOKA' ; gnuplot-beta
> Cc: 
> Date: 2017/7/10, Mon 16:08
> Subject: AW: Is minimal required platform Windows 7 only for the 5.3 or later for gnuplot for windows?
> 
> For 5.2 this hasn't changed in syscfg.h. If the Direct2D windows terminal
> backend is included in the build, the executable will only run on Vista SP2
> with platform upgrade or later, though.  Moreover there could be
> restrictions implied by the libraries and compiler chain used, in particular
> Qt.
> 
>   Bastian
> 
>>  -----Ursprüngliche Nachricht-----
>>  Von: Tatsuro MATSUOKA [mailto:tma...@ya...]
>>  Gesendet: Sonntag, 9. Juli 2017 23:30
>>  An: gnu...@li...; bma...@we...
>>  Betreff: Is minimal required platform Windows 7 only for the 5.3 or later
> for
>>  gnuplot for windows?
>> 
>>  I saw the below in the ChangeLog in cvs branch source
>> 
>>  2017-07-07  Bastian Maerkisch  <bma...@we...>
>>          <snip>
>>      * src/syscfg.h:  Minimum required API version is Windows 7 by
>>      default.  Vista and XP are end-of-service.
>> 
>> 
>>  For gnuplot 5.2.x, is minimal required platform windows XP?
>> 
>>  Tatsuro
>> 
>> 
> ----------------------------------------------------------------------------
> --
>>  Check out the vibrant tech community on one of the world's most
>>  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>  _______________________________________________
>>  gnuplot-beta mailing list
>>  gnu...@li...
>>  Membership management via:
>>  https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

AW: Is minimal required platform Windows 7 only for the 5.3 or later for gnuplot for windows?

[Bastian M. <bma...@we...>]

For 5.2 this hasn't changed in syscfg.h. If the Direct2D windows terminal
backend is included in the build, the executable will only run on Vista SP2
with platform upgrade or later, though.  Moreover there could be
restrictions implied by the libraries and compiler chain used, in particular
Qt.

  Bastian

> -----Ursprüngliche Nachricht-----
> Von: Tatsuro MATSUOKA [mailto:tma...@ya...]
> Gesendet: Sonntag, 9. Juli 2017 23:30
> An: gnu...@li...; bma...@we...
> Betreff: Is minimal required platform Windows 7 only for the 5.3 or later
for
> gnuplot for windows?
> 
> I saw the below in the ChangeLog in cvs branch source
> 
> 2017-07-07  Bastian Maerkisch  <bma...@we...>
>         <snip>
>     * src/syscfg.h:  Minimum required API version is Windows 7 by
>     default.  Vista and XP are end-of-service.
> 
> 
> For gnuplot 5.2.x, is minimal required platform windows XP?
> 
> Tatsuro
> 
>
----------------------------------------------------------------------------
--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Is minimal required platform Windows 7 only for the 5.3 or later for gnuplot for windows?

[Tatsuro M. <tma...@ya...>]

I saw the below in the ChangeLog in cvs branch source

2017-07-07  Bastian Maerkisch  <bma...@we...>
        <snip> 
    * src/syscfg.h:  Minimum required API version is Windows 7 by
    default.  Vista and XP are end-of-service.


For gnuplot 5.2.x, is minimal required platform windows XP?

Tatsuro

Building gnuplot5.2rc2 on linux mint mate

[Jim M. <jm...@ro...>]

I've tested release candidate 2 on systems running linux mint 17, 17.2, 
17.3, and 18.2.  I was able to install and use the qt and tikz terminals 
on all systems.

Linux Mint Mate 18.2 was newly installed, and I attempted to find a 
minimal set of extra dependencies.  I installed the following:

mc and emacs with the Package Manager, for my convenience
subset of texlive 2017 (for testing tikz)
gpp and g++ with Package Manager, needed for build
qt5-default, libqt5svg5-dev,qttools5-dev,qttools-dev-tools,liblua5.2,lua5.2

I was then able to build and install gnuplot starting with ./configure 
--with-qt  --with-lua

/usr/lib/x86_64-linux-gnu/pkgconfig contained
lua-5.2.pc -> lua5.2.pc and lua52.pc -> lua5.2.pc
It was not necessary to add a link to lua.pc as stated in INSTALL.

Jim

Re: WXT window 'persist'

[<pl...@pi...>]

On 07/07/17 00:32, Daniel J Sebald wrote:
> On 07/06/2017 06:15 PM, Daniel J Sebald wrote:
>>> No, on the closing of the plot window at exit.  It is still persistent
>>> after exit.  I'll look into the code around "Checking window 0" if there
>>> might be something else at play.
>>
>> OK, this one was O.E.  I looked in the window's configuration dialog and
>> saw that there is a "persist" variable active.  I must have set that a
>> long time ago not realizing it is remembered between sessions, not
>> present-session-only.
> 
> There is a minor issue, which is that 'persist' and other wxConfig 
> settings are stored at wxt-window exit, rather than at the point of "OK" 
> or "Apply".  Say for example:
> 
> 1) Run 'gnuplot' and generate a WXT terminal window.  Exit when 
> 'persist' is active, the window stays on screen.
> 
> 2) Run 'gnuplot' again, generate a WXT plot and turn off 'persist'. Exit 
> and the most recent plot window closes, but the older plot is still 
> persistent, that's fine.
> 
> 3) But now close that older plot window and 'persist' is turned back on 
> the next time gnuplot is run.
> 
> Rare circumstances, and probably not worth a bug fix.
> 
> Dan
> 
> ----------

Why is persist being stored anywhere?  Surlely this is just flag to 
gnuplot for whether to close the plot window on the way out.

How is this a wxt config option which needs to be stored anywhere. It 
seems like faulty logic to me.

Peter.

WXT single thread configuration

[Daniel J S. <dan...@ie...>]

On 07/06/2017 05:19 PM, Daniel J Sebald wrote:
> On 07/06/2017 05:03 PM, Ethan A Merritt wrote:
>> On Thursday, 06 July, 2017 16:27:00 Daniel J Sebald wrote:
>>
>>> 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
>>
>>
>> So do all the errors go away if you do
>>
>>    ./configure --with-wx-single-threaded
>>
>> (still omitting the call to XInitThreads and not linking to -lX11).
>
> Yes, on the crash (plot is successful):

However, wx-single-threaded doesn't work for multiple windows for me. 
The first plot is fine.  But then

raise window
gnuplot> set term wxt 1
wxt_reset
wxt_reset ends

Terminal type is now 'wxt'
Options are '1 enhanced'
gnuplot> plot sin(x)
[repeated about 300 times or more]
Init
opening a new plot window
wxtApp::OnCreateWindow
wxtFrame constructor
wxtFrame constructor 2
frame OnSize
Init
opening a new plot window
wxtApp::OnCreateWindow
wxtFrame constructor
wxtFrame constructor 2
frame OnSize
Init
opening a new plot window
Segmentation fault

Maybe a stack overflow is the segfault.  Why it keeps opening new 
windows (that don't appear visually), I don't know.

Dan

Re: Fwd: Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

On 07/06/2017 05:19 PM, Daniel J Sebald wrote:
> On 07/06/2017 05:03 PM, Ethan A Merritt wrote:
[snip]
>> So do all the errors go away if you do
>>
>>    ./configure --with-wx-single-threaded
>>
>> (still omitting the call to XInitThreads and not linking to -lX11).
[snip]
> No, on the closing of the plot window at exit.  It is still persistent
> after exit.  I'll look into the code around "Checking window 0" if there
> might be something else at play.

OK, this one was O.E.  I looked in the window's configuration dialog and 
saw that there is a "persist" variable active.  I must have set that a 
long time ago not realizing it is remembered between sessions, not 
present-session-only.

Dan

WXT window 'persist'

[Daniel J S. <dan...@ie...>]

On 07/06/2017 06:15 PM, Daniel J Sebald wrote:
>> No, on the closing of the plot window at exit.  It is still persistent
>> after exit.  I'll look into the code around "Checking window 0" if there
>> might be something else at play.
>
> OK, this one was O.E.  I looked in the window's configuration dialog and
> saw that there is a "persist" variable active.  I must have set that a
> long time ago not realizing it is remembered between sessions, not
> present-session-only.

There is a minor issue, which is that 'persist' and other wxConfig 
settings are stored at wxt-window exit, rather than at the point of "OK" 
or "Apply".  Say for example:

1) Run 'gnuplot' and generate a WXT terminal window.  Exit when 
'persist' is active, the window stays on screen.

2) Run 'gnuplot' again, generate a WXT plot and turn off 'persist'. 
Exit and the most recent plot window closes, but the older plot is still 
persistent, that's fine.

3) But now close that older plot window and 'persist' is turned back on 
the next time gnuplot is run.

Rare circumstances, and probably not worth a bug fix.

Dan

Re: Fwd: Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

On 07/06/2017 05:03 PM, Ethan A Merritt wrote:
> On Thursday, 06 July, 2017 16:27:00 Daniel J Sebald wrote:
>
>> 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
>
>
> So do all the errors go away if you do
>
>    ./configure --with-wx-single-threaded
>
> (still omitting the call to XInitThreads and not linking to -lX11).

Yes, on the crash (plot is successful):

gnuplot> set term wxt

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
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
raise window
frame OnSize
Graphics xmax 12800 ymax 7680 v_char 339 h_char 160
raise window
gnuplot> exit
wxt_atexit: handling "persist" setting
	Checking window 0 :  shown
parent process: exiting, child process has PID 6255
wxt_cleanup: start
wxtApp::OnExit
child process: running
child process: restarting its event loop
panel destructor
wxt_cleanup: finished
wxt_reset

No, on the closing of the plot window at exit.  It is still persistent 
after exit.  I'll look into the code around "Checking window 0" if there 
might be something else at play.

Dan

Re: Fwd: Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

On Thursday, 06 July, 2017 16:27:00 Daniel J Sebald wrote:

> 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


So do all the errors go away if you do

   ./configure --with-wx-single-threaded

(still omitting the call to XInitThreads and not linking to -lX11).

	Ethan

Re: Fwd: Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

On 07/06/2017 02:28 PM, Ethan A Merritt wrote:
> 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.

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

Re: Fwd: Re: 5.2 rc2 tarball now available

[Allin C. <cot...@wf...>]

On Thu, 6 Jul 2017, Ethan A Merritt wrote:

> I agree it is stupid that wxgtk does not perform its own initialization.
> But it doesn't.

Granted. However, the problem I've encountered lately is at the 
other end, wxt_atexit(), and specifically the call

thread->Wait()

in wxt_gui.cpp. This (but just sometimes, so maybe a race 
condition?) provokes in wxgtk 3 an assertion failure:

"./src/unix/threadpsx.cpp(1480): assert "This() != this" failed in 
Wait(): a thread can't wait for itself"

Is there perhaps a way to guard against that? I'm blissfully 
ignorant of C++ "this" shenanigans, but maybe something vaguely 
resembling

if (thread != this) // or This() ??
   thread->Wait();

Allin Cottrell

Re: Fwd: Re: 5.2 rc2 tarball now available

[Allin C. <cot...@wf...>]

On Thu, 6 Jul 2017, Ethan A Merritt wrote:

> On Thursday, 06 July, 2017 15:13:44 Allin Cottrell wrote:
>> On Thu, 6 Jul 2017, Daniel J Sebald wrote:
>>
>>> 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.  wx_gui shouldn't be using
>>> XInitThreads().
>>
>> I'd just like to underscore Daniel's last point here. Surely it's a
>> dangerous hack for the gnuplot code to call XInitThreads() "on
>> behalf of" wxWidgets (in wxt_gui.h). I suspect this may be related
>> to the segfault I reported earlier today.
>>
>> <danger-will-robinson>
>> #if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
>> defined(X11)
>>  	/* Magic fix needed by wxgtk3.0 */
>>          wxtApp() : wxApp() { XInitThreads(); }
>> #endif
>> </danger-will-robinson>
>
> [shrug]
> I agree it is stupid that wxgtk does not perform its own initialization.
> But it doesn't.
>
> I refer you to the output from wxgtk if this call is omitted:
>
> Call stack:
> [00] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
> [01] wxClientDCImpl::DoGetSize(int*, int*) const
> [02] wxBufferedDC::UnMask()
> [03] ~wxDC                                      /usr/include/wx-3.0/wx/dc.h:789
> [04] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
> [05] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
> [06] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
> [07] wxEvtHandler::TryHereOnly(wxEvent&)
> [08] wxEvtHandler::ProcessEventLocally(wxEvent&)
> [09] wxEvtHandler::ProcessEvent(wxEvent&)
> [10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
> [11] 0x7f22e8025ee1
> [12] g_closure_invoke
> [13] 0x7f22e6af0aad
> [14] g_signal_emit_valist
> [15] g_signal_emit
> [16] gtk_widget_size_allocate
> [17] 0x7f22e8024ff3
> [18] g_closure_invoke
> [19] 0x7f22e6af02c7
> [20] g_signal_emit_valist
> [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.
>
> I can suggest only 3 other options:
>
> 1) Link against wxgtk 2.8 rather than anything newer.
>   These problems only began after libgtk was substantially revised
>   in version 2.9
>
> 2) Try ./configure   --with-wx-single-threaded
>   This never did much for me, but other people have reported better luck
>
> 3) Give up on the wxt terminal and use qt instead

Fair enough. I'll try building against wxgtk 2.8.

Allin Cottrell

Re: Fwd: Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

On Thursday, 06 July, 2017 15:13:44 Allin Cottrell wrote:
> On Thu, 6 Jul 2017, Daniel J Sebald wrote:
> 
> > 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.  wx_gui shouldn't be using 
> > XInitThreads().
> 
> I'd just like to underscore Daniel's last point here. Surely it's a 
> dangerous hack for the gnuplot code to call XInitThreads() "on 
> behalf of" wxWidgets (in wxt_gui.h). I suspect this may be related 
> to the segfault I reported earlier today.
> 
> <danger-will-robinson>
> #if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) && 
> defined(X11)
>  	/* Magic fix needed by wxgtk3.0 */
>          wxtApp() : wxApp() { XInitThreads(); }
> #endif
> </danger-will-robinson>

[shrug]
I agree it is stupid that wxgtk does not perform its own initialization.
But it doesn't.

I refer you to the output from wxgtk if this call is omitted:

Call stack:
[00] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
[01] wxClientDCImpl::DoGetSize(int*, int*) const
[02] wxBufferedDC::UnMask()                  
[03] ~wxDC                                      /usr/include/wx-3.0/wx/dc.h:789
[04] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[05] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[06] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[07] wxEvtHandler::TryHereOnly(wxEvent&)     
[08] wxEvtHandler::ProcessEventLocally(wxEvent&)
[09] wxEvtHandler::ProcessEvent(wxEvent&)    
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] 0x7f22e8025ee1
[12] g_closure_invoke                        
[13] 0x7f22e6af0aad
[14] g_signal_emit_valist                    
[15] g_signal_emit                           
[16] gtk_widget_size_allocate                
[17] 0x7f22e8024ff3
[18] g_closure_invoke                        
[19] 0x7f22e6af02c7
[20] g_signal_emit_valist                    
[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.

I can suggest only 3 other options:

1) Link against wxgtk 2.8 rather than anything newer.
   These problems only began after libgtk was substantially revised
   in version 2.9

2) Try ./configure   --with-wx-single-threaded 
   This never did much for me, but other people have reported better luck

3) Give up on the wxt terminal and use qt instead

	Ethan

Re: Fwd: Re: 5.2 rc2 tarball now available

[Allin C. <cot...@wf...>]

On Thu, 6 Jul 2017, Daniel J Sebald wrote:

> 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.  wx_gui shouldn't be using 
> XInitThreads().

I'd just like to underscore Daniel's last point here. Surely it's a 
dangerous hack for the gnuplot code to call XInitThreads() "on 
behalf of" wxWidgets (in wxt_gui.h). I suspect this may be related 
to the segfault I reported earlier today.

<danger-will-robinson>
#if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) && 
defined(X11)
 	/* Magic fix needed by wxgtk3.0 */
         wxtApp() : wxApp() { XInitThreads(); }
#endif
</danger-will-robinson>

Allin Cottrell

Re: Fwd: Re: 5.2 rc2 tarball now available

[Ethan A M. <sf...@us...>]

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

Fwd: Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

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.


> NB: --without-gd is there because the gd configure tool actually gets this right
> and pulls in -lX11 if libgd wants it. If the wxgtk configure tool did the same
> we wouldn't have this problem.

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.  wx_gui shouldn't be using XInitThreads().  I 
suspect that something in the code outside the main thread is doing 
something graphics related, but that's much too complex to address in 
the near term.

Dan

Re: 5.2 rc2 tarball now available

[sfeam <sf...@us...>]

On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote:
> On 07/05/2017 05:08 PM, Petr Mikulik wrote:
> >>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
> >>>>>> Ubuntu) linking fails.
> >>>>>>
> >>>>>> It is this problem:
> >>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
> >>>>>>
> >>>>>> The workaround
> >>>>>>      configure --with-X11
> >>>>>> described above does not help, while
> >>>>>>      TERMLIBS="-lX11" ./configure
> >>>>>> let me gnuplot compile.
> >>>>>>
> >>>>>> Can this be fixed?
> >>>>>
> >>>>>   No.  It is a bug in the configuration files distributed for
> >>>>> libwxgtk.
> >>>>
> >>>> Unfortunately it seems to be a wide-spread bug. It is quite
> >>>> embarassing that a
> >>>> compile needs googling to fix it locally.
> >>>>
> >>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
> >>>> "something"?
> >>>
> >>> That "something" is exactly the problem.   Only some versions of
> >>> wxWidgets need this, and only for some configurations.   The
> >>> wx-config tool is supposed to tell us what libraries are needed so
> >>> we can link them.  But it doesn't mention X11.    So how are we to know?
> >>
> >> Actually, I think this is gnuplot's responsibility.  If I do
> >
> >> Anyway, I think gnuplot configure is obligated to add -lX11, given the
> >> situation.
> >
> > 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.

	Ethan


NB: --without-gd is there because the gd configure tool actually gets this right 
and pulls in -lX11 if libgd wants it. If the wxgtk configure tool did the same 
we wouldn't have this problem.
 




> 
> Dan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

wxt thread-wait problem

[Allin C. <cot...@wf...>]

I'm running current CVS gnuplot on Arch linux, linked with wxgtk2 
3.0.3, and I'm seeing the program aborting on exit. Not on every 
invocation -- this mostly happens when I run a script which generates 
several plots, via separate calls to gnuplot, using the wxt terminal 
with the -persist command-line flag.

If instead I run the gnuplot 5.0.6 that's supplied with Arch (linked 
with the same wxWidgets library), the problem does not occur.

Here's an example of what I'm seeing on stderr using the CVS code;

The program 'gnuplot' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
   (Details: serial 519 error_code 8 request_code 130 minor_code 3)
   (Note to programmers: normally, X errors are reported 
asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() 
function.)
Gnuplot exiting abnormally. Trying to execute exit handlers anyway.
./src/unix/threadpsx.cpp(1480): assert "This() != this" failed in 
Wait(): a thread can't wait for itself [in thread 7f83ce033700]

Call stack:
[00] wxOnAssert(char const*, int, char const*, char const*, wchar_t 
const*)
[01] wxThread::Wait(wxThreadWait)
[02] wxt_atexit() 
/home/cottrell/cfiles/gp-cvs/linux/src/../../gnuplot5/src/wxterminal/wxt_gui.cpp:4093
[03] gp_exit_cleanup 
/home/cottrell/cfiles/gp-cvs/linux/src/../../gnuplot5/src/stdfn.c:451
[04] 0x7f83da650298
[05] 0x7f83da6502ea
[06] 0x7f83dc5c5874
[07] _XError
[08] 0x7f83ded94617
[09] 0x7f83ded946d5
[10] _XReply
[11] XTranslateCoordinates
[12] 0x7f83dc5cca38
[13] gdk_window_get_origin
[14] wxWindow::DoClientToScreen(int*, int*) const
[15] 0x7f83de25fd06
[16] 0x7f83de262e10
[17] 0x7f83dc9487ac
[18] g_closure_invoke
[19] 0x7f83dd4ba4ee
[20] g_signal_emit_valist

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: 5.2 rc2 tarball now available

[Daniel J S. <dan...@ie...>]

On 07/05/2017 05:08 PM, Petr Mikulik wrote:
>>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some
>>>>>> Ubuntu) linking fails.
>>>>>>
>>>>>> It is this problem:
>>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>>>
>>>>>> The workaround
>>>>>>      configure --with-X11
>>>>>> described above does not help, while
>>>>>>      TERMLIBS="-lX11" ./configure
>>>>>> let me gnuplot compile.
>>>>>>
>>>>>> Can this be fixed?
>>>>>
>>>>>   No.  It is a bug in the configuration files distributed for
>>>>> libwxgtk.
>>>>
>>>> Unfortunately it seems to be a wide-spread bug. It is quite
>>>> embarassing that a
>>>> compile needs googling to fix it locally.
>>>>
>>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>>>> "something"?
>>>
>>> That "something" is exactly the problem.   Only some versions of
>>> wxWidgets need this, and only for some configurations.   The
>>> wx-config tool is supposed to tell us what libraries are needed so
>>> we can link them.  But it doesn't mention X11.    So how are we to know?
>>
>> Actually, I think this is gnuplot's responsibility.  If I do
>
>> Anyway, I think gnuplot configure is obligated to add -lX11, given the
>> situation.
>
> 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

Dan

Re: 5.2 rc2 tarball now available

[Petr M. <mi...@ph...>]

>>>>> I have troubles compiling rc2 on Linux (OpenSUSE 42.2, and some Ubuntu) 
>>>>> linking fails.
>>>>> 
>>>>> It is this problem:
>>>>>      https://sourceforge.net/p/gnuplot/support-requests/196/
>>>>> 
>>>>> The workaround
>>>>>      configure --with-X11
>>>>> described above does not help, while
>>>>>      TERMLIBS="-lX11" ./configure
>>>>> let me gnuplot compile.
>>>>> 
>>>>> Can this be fixed?
>>>>
>>>>   No.  It is a bug in the configuration files distributed for libwxgtk.
>>> 
>>> Unfortunately it seems to be a wide-spread bug. It is quite embarassing 
>>> that a
>>> compile needs googling to fix it locally.
>>> 
>>> Cannot "./configure" take care of this? I.e. add the "-lX11" flag if
>>> "something"?
>> 
>> That "something" is exactly the problem.   Only some versions of
>> wxWidgets need this, and only for some configurations.   The
>> wx-config tool is supposed to tell us what libraries are needed so
>> we can link them.  But it doesn't mention X11.    So how are we to know?
>
> Actually, I think this is gnuplot's responsibility.  If I do

>Anyway, I think gnuplot configure is obligated to add -lX11, given the 
>situation.

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?

---
Petr