Re: 5.0-rc3 on OpenBSD 5.6: mostly ok, but a few glitches

[Mojca M. <moj...@gm...>]

> Unfortunately wxt 3.0 does not work with gnuplot.
> (I'm sure they would claim that is better said "gnuplot does not
> work with wxt 3.0" ;-)
>
> No fix is known and I am not aware of anyone working on it.
> It may not be fixable in general, although a couple of people have reported
> that
>         ./configure   --with-wx-single-threaded
> allows it to run correctly even though it prints alarming error messages.
> For me that configuration option doesn't make any apparent difference.
>
> This problem has already hit gnuplot packaging on both OSX and Debian,
> both of which have switched to the newer wxt and not made adequate provision
> for programs that require the older version 2.8.  Sad, really.
> The only work-around I can recommend at this point is to use the qt terminal
> instead.

Just to make it clear:

- gnuplot + wxWidgets 3.0 works fine for me on OS X; it has worked ok
for a long time already, so saying that "wxt 3.0 doesn't work with
gnuplot" is not entirely correct. There might be problems on linux,
but it has worked fine on OS X long before anyone tested it on linux.
(There might be special cases that fail to work, but in general it
works.)

- I believe there are still issues with gnuplot + Qt 5 on OS X, but I
don't remember the details (I don't use Qt 5 on regular basis yet).

- wxWidgets 2.8 cannot be compiled for x86_64-darwin and it cannot be
compiled on OS X 10.7 or later; Apple dropped a library that wxWidgets
relied on and wxWidgets developers are not interested in fixing
version 2.8. But if someone would compile gnuplot against wxWidgets
2.8 on Mac OS X 10.6 for i386, that version would work. A number of
applications are distributed that way, but gnuplot is a bit difficult
to distribute in a binary form on Mac. (The problem is that someone
would need to invest a non-trivial amount of work to make gnuplot
Mac-friendly as a standalone app. I tend to believe that most mac
users "compile" gnuplot from source via their package managers.)

Specifically about:

> both of which have switched to the newer wxt and not made adequate provision
> for programs that require the older version 2.8.  Sad, really.

OS X didn't "switch" to anything, OS X doesn't ship with any version
of wxWidgets. wxWidgets 2.8 depended on an ancient library that was
abandoned by Apple at some point. That's the whole story. (Besides
wxWidgets lacking sufficient developers to keep up with changes in OS
X.)

The "sad" part would be gnuplot not being fixed to start working with
wxWidgets 3.0 properly. (I don't have problems with 3.0 though.)

Nobody will convince Apple to rewrite parts of Carbon to start working
with x86_64. And nobody will convince the wxWidgets developers to port
wxWidgets 2.8 to Cocoa. The only proper and future-proof solution
would be to have fully working support for wxWidgets 3.0 (and
wxWidgets 3.1/3.2) in gnuplot.

Another very nice thing that would often help alleviate these kind of
issues would be to start distributing gnuplot for Mac in a binary
form. But that requires extra work.

One can in principle compile gnuplot against wxGTK 2.8 on Mac. But
that's not something that users would want to use.

Mojca