[Freewx-maint] Bug#750045: gnuplot: no longer works: assert "m_window" failed in DoGetSize()

sfeam sfeam at users.sourceforge.net
Sun Jun 1 17:43:50 UTC 2014

On Sunday, 01 June 2014 07:05:41 PM Anton Gladky wrote:
> Hi Olly,
> 2014-06-01 12:57 GMT+02:00 Olly Betts <olly at survex.com>:
> > Overall sorting out such issues is better, but if you want a quick fix
> > you can just turn off WXDEBUG mode by passing -DNDEBUG when you compile
> > your app.  Then these cases should be handled much as they were by
> > default in wx 2.8.
> Thanks for an explanation. Unfortunately the proposed fix does not
> work and gnuplot
> crashes. How long are you planning to keep wx 2.8 in archive?
> gnuplot is a critical package with popcon > 70k. We cannot keep it broken
> for a long time. I hope upstream will help us to fix it but I if we do
> not solve the
> problem within the next few days I would switch gnuplot back to wx 2.8.

Hi.  I'm a lead developer for gnuplot.

Unfortunately this issue appeared just at the time we were putting out
a release candidate for a major version upgrade to gnuplot 5.0.
I don't think it is realistic for us to promise support for 
wxwidgets3.0 any time soon since the amount of revision required is
unknown at this point.   I have added a warning in the Release Notes.


Would it be an acceptable option for Debian to provide a default
build that uses Qt5 (or Qt4 for that matter) libraries rather than
wxWidgets?  We spent a lot of effort over the last year or so 
polishing gnuplot's qt terminal and infrastructure, to the point
where it is now faster and more performant than wxt.  
If your default gnuplot package doesn't require wxWidgets at all,
then the wx version becomes moot.

For the gnuplot version 5.0 release candidate this corresponds to
build options

  ./configure --disable-wxt  --with-qt=qt5

(or --with-qt=qt4).

	Ethan Merritt (sfeam)

More information about the Freewx-maint mailing list