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

Re: wxt on mac: error report

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 30 July 2011, Mojca Miklavec wrote:
> On Sat, Jul 30, 2011 at 19:03, sfeam (Ethan Merritt) wrote:
> > On Saturday, 30 July 2011, Mojca Miklavec wrote:
> >> Hello,
> >>
> >> The new gnuplot sources at least compile out of the box with wxt
> >> (wxWidgets 2.9.2),
> >
> > To the best of my knowledge, no one has reported experience with
> > gnuplot + wxWidgets 2.9 on any platform.   Wouldn't it make more
> > sense for you to test first with 2.8, which we know works on
> > other platforms?
> 
> I'm still fighting with libraries. Since they are using Carbon
> (abandoned by Apple & unsupported in 64-bit), wxWidgets 2.8 on 64-bit
> macs are a pain. Moreover, using both wxt & x11 terminal
> simultaneously is not possible.
> 
> gcc  -g -O2  -arch i386 -o gnuplot_x11 gplt_x11.o gpexecute.o
> getcolor_x11.o -L/usr/X11/lib -R/usr/X11/lib -lX11  -liconv
> -L/opt/local/lib -lz -lpangocairo-1.0 -lcairo -lpangoft2-1.0
> -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
> -lgthread-2.0 -lglib-2.0 -lintl
> ld: warning: ignoring file getcolor_x11.o, file was built for
> unsupported file format which is not the architecture being linked
> (i386)
> Undefined symbols for architecture i386:
>   "_quantize_gray", referenced from:
>       _PaletteSetColor in gplt_x11.o
>   "_rgb1_from_gray", referenced from:
>       _main in gplt_x11.o
> ld: symbol(s) not found for architecture i386
> collect2: ld returned 1 exit status
> make[3]: *** [gnuplot_x11] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

getcolor needs to be built twice, once for inclusion in gnuplot proper
and once for inclusion in gnuplot_x11.   From the error messages you
show, it looks to me that one of the two versions either was not built
at all or was built in the wrong order.
 
> But I would strongly suggest to try to make gnuplot work with
> wxWidgets 2.9. 

From the wxWidgets web site:
    wxWidgets 2.9.2 Released 2011-07-05
   "While this is still officially a development release because 
    some API details are still not frozen, we believe that 2.9.2 
    can be used in production environment, especially for the new 
    projects for which (small) changes in behaviour since 2.8 are 
    not a problem. Give it a try and let us know what do you think!"

There is also a Change Log with a fairly long list of things that
need to be changed in the calling program to switch from 2.8 to 2.9
(actually it says 3.0, which is kind of confusing).

So I think 2.9 is not yet ready for prime time, and trying to 
debug a 2.9 installation when you don't even have 2.8 working
sounds like a difficult task.

I will be interested in adapting gnuplot for use with wxWidgets 2.9
when it appears as a production release in linux distros, but not
before.  If someone else wants to play around with 2.9 in its current
state and report back with patches or warnings about unresolved
problems, that's great.  But I wouldn't expect the 2.8->2.9
transition to work seamlessly based on the notes on their web site. 

At the least, I gather that all the wxT(text) macros have to be
replaced by something else.  Also NULL strings are no longer legal
(not sure if the current code uses that anywhere). 

			Ethan

> The version 2.8 will be probably be useless on Macs
> before the next stable version of wxWidgets is released.
> 
> (I'm now trying to build qt4-mac from MacPorts to test configuration,
> but as I already figured out, the terminal doesn't work at the moment
> and it is unlikely that using another qt library would change that.)
> 
> Mojca

Re: wxt on mac: error report

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

On Sat, Jul 30, 2011 at 19:03, sfeam (Ethan Merritt) wrote:
> On Saturday, 30 July 2011, Mojca Miklavec wrote:
>> Hello,
>>
>> The new gnuplot sources at least compile out of the box with wxt
>> (wxWidgets 2.9.2),
>
> To the best of my knowledge, no one has reported experience with
> gnuplot + wxWidgets 2.9 on any platform.   Wouldn't it make more
> sense for you to test first with 2.8, which we know works on
> other platforms?

I'm still fighting with libraries. Since they are using Carbon
(abandoned by Apple & unsupported in 64-bit), wxWidgets 2.8 on 64-bit
macs are a pain. Moreover, using both wxt & x11 terminal
simultaneously is not possible.

gcc  -g -O2  -arch i386 -o gnuplot_x11 gplt_x11.o gpexecute.o
getcolor_x11.o -L/usr/X11/lib -R/usr/X11/lib -lX11  -liconv
-L/opt/local/lib -lz -lpangocairo-1.0 -lcairo -lpangoft2-1.0
-lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lglib-2.0 -lintl
ld: warning: ignoring file getcolor_x11.o, file was built for
unsupported file format which is not the architecture being linked
(i386)
Undefined symbols for architecture i386:
  "_quantize_gray", referenced from:
      _PaletteSetColor in gplt_x11.o
  "_rgb1_from_gray", referenced from:
      _main in gplt_x11.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make[3]: *** [gnuplot_x11] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

After disabling x11 terminal, I have built it successfully on a remote
machine, but since I have no GUI access, I won't be able to test it
for the next couple of days.

On the local machine I apparently screwed something up and I still
don't know how to fix it.

But I would strongly suggest to try to make gnuplot work with
wxWidgets 2.9. The version 2.8 will be probably be useless on Macs
before the next stable version of wxWidgets is released.

(I'm now trying to build qt4-mac from MacPorts to test configuration,
but as I already figured out, the terminal doesn't work at the moment
and it is unlikely that using another qt library would change that.)

Mojca

Re: wxt on mac: error report

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 30 July 2011, Mojca Miklavec wrote:
> Hello,
> 
> The new gnuplot sources at least compile out of the box with wxt
> (wxWidgets 2.9.2), 

To the best of my knowledge, no one has reported experience with
gnuplot + wxWidgets 2.9 on any platform.   Wouldn't it make more
sense for you to test first with 2.8, which we know works on 
other platforms?

	Ethan



> however when I try to plot something, here is what
> I get:
> 
> Terminal type set to 'wxt'
> gnuplot> plot sin(x)
> 2011-07-30 12:18:28.561 gnuplot[24578:2a03] *** Assertion failure in
> -[NSToolbar _forceInsertItem:atIndex:],
> /SourceCache/AppKit/AppKit-1138/Toolbar.subproj/NSToolbar.m:1309
> 2011-07-30 12:18:28.562 gnuplot[24578:2a03] An uncaught exception was raised
> 2011-07-30 12:18:28.574 gnuplot[24578:2a03] Invalid parameter not
> satisfying: index>=0 && index<=[self _numberOfItems]
> 2011-07-30 12:18:28.645 gnuplot[24578:2a03] (
> 	0   CoreFoundation                      0x00007fff93730986
> __exceptionPreprocess + 198
> 	1   libobjc.A.dylib                     0x00007fff93a0fd5e
> objc_exception_throw + 43
> 	2   CoreFoundation                      0x00007fff937307ba
> +[NSException raise:format:arguments:] + 106
> 	3   Foundation                          0x00007fff8d5c114f
> -[NSAssertionHandler
> handleFailureInMethod:object:file:lineNumber:description:] + 169
> 	4   AppKit                              0x00007fff8abb384f
> -[NSToolbar _forceInsertItem:atIndex:] + 163
> 	5   AppKit                              0x00007fff8abb3626
> -[NSToolbar _insertItem:atIndex:notifyDelegate:notifyView:notifyFamilyAndUpdateDefaults:]
> + 121
> 	6   AppKit                              0x00007fff8abb3361
> -[NSToolbar _insertNewItemWithItemIdentifier:atIndex:propertyListRepresentation:notifyFlags:]
> + 118
> 	7   libwx_osx_cocoau_core-2.9.2.0.0.dylib 0x000000010302c086
> _ZN9wxToolBar7RealizeEv + 1824
> 	8   gnuplot                             0x00000001025c7e81
> _ZN8wxtFrameC2ERK8wxStringi + 1759
> 	9   gnuplot                             0x00000001025be6bb
> _ZN6wxtApp14OnCreateWindowER14wxCommandEvent + 41
> 	10  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b85ef
> _ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent
> + 93
> 	11  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba32a
> _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler + 320
> 	12  libwx_baseu-2.9.2.0.0.dylib         0x00000001036bb132
> _ZN12wxEvtHandler16TryBeforeAndHereER7wxEvent + 92
> 	13  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba3ac
> _ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent + 30
> 	14  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b9a6d
> _ZN12wxEvtHandler12ProcessEventER7wxEvent + 159
> 	15  gnuplot                             0x00000001025c346d wxt_init + 781
> 	16  gnuplot                             0x00000001025ae61f
> term_initialise + 271
> 	17  gnuplot                             0x0000000102513090 do_plot + 592
> 	18  gnuplot                             0x000000010253d760 eval_plots + 26976
> 	19  gnuplot                             0x00000001024e9aff do_line + 783
> 	20  gnuplot                             0x00000001024eaa01 com_line + 81
> 	21  gnuplot                             0x00000001025335f5 main + 1285
> 	22  gnuplot                             0x00000001024de864 start + 52
> 	23  ???                                 0x0000000000000001 0x0 + 1
> )
> 2011-07-30 12:18:28.646 gnuplot[24578:2a03] *** Terminating app due to
> uncaught exception 'NSInternalInconsistencyException', reason:
> 'Invalid parameter not satisfying: index>=0 && index<=[self
> _numberOfItems]'
> *** First throw call stack:
> (
> 	0   CoreFoundation                      0x00007fff93730986
> __exceptionPreprocess + 198
> 	1   libobjc.A.dylib                     0x00007fff93a0fd5e
> objc_exception_throw + 43
> 	2   CoreFoundation                      0x00007fff937307ba
> +[NSException raise:format:arguments:] + 106
> 	3   Foundation                          0x00007fff8d5c114f
> -[NSAssertionHandler
> handleFailureInMethod:object:file:lineNumber:description:] + 169
> 	4   AppKit                              0x00007fff8abb384f
> -[NSToolbar _forceInsertItem:atIndex:] + 163
> 	5   AppKit                              0x00007fff8abb3626
> -[NSToolbar _insertItem:atIndex:notifyDelegate:notifyView:notifyFamilyAndUpdateDefaults:]
> + 121
> 	6   AppKit                              0x00007fff8abb3361
> -[NSToolbar _insertNewItemWithItemIdentifier:atIndex:propertyListRepresentation:notifyFlags:]
> + 118
> 	7   libwx_osx_cocoau_core-2.9.2.0.0.dylib 0x000000010302c086
> _ZN9wxToolBar7RealizeEv + 1824
> 	8   gnuplot                             0x00000001025c7e81
> _ZN8wxtFrameC2ERK8wxStringi + 1759
> 	9   gnuplot                             0x00000001025be6bb
> _ZN6wxtApp14OnCreateWindowER14wxCommandEvent + 41
> 	10  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b85ef
> _ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent
> + 93
> 	11  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba32a
> _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler + 320
> 	12  libwx_baseu-2.9.2.0.0.dylib         0x00000001036bb132
> _ZN12wxEvtHandler16TryBeforeAndHereER7wxEvent + 92
> 	13  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba3ac
> _ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent + 30
> 	14  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b9a6d
> _ZN12wxEvtHandler12ProcessEventER7wxEvent + 159
> 	15  gnuplot                             0x00000001025c346d wxt_init + 781
> 	16  gnuplot                             0x00000001025ae61f
> term_initialise + 271
> 	17  gnuplot                             0x0000000102513090 do_plot + 592
> 	18  gnuplot                             0x000000010253d760 eval_plots + 26976
> 	19  gnuplot                             0x00000001024e9aff do_line + 783
> 	20  gnuplot                             0x00000001024eaa01 com_line + 81
> 	21  gnuplot                             0x00000001025335f5 main + 1285
> 	22  gnuplot                             0x00000001024de864 start + 52
> 	23  ???                                 0x0000000000000001 0x0 + 1
> )
> terminate called throwing an exceptionAbort trap: 6
> 
> 
> It might be a bug in wxWidgets, but I have no idea what to do.
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

wxt on mac: error report

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

Hello,

The new gnuplot sources at least compile out of the box with wxt
(wxWidgets 2.9.2), however when I try to plot something, here is what
I get:

Terminal type set to 'wxt'
gnuplot> plot sin(x)
2011-07-30 12:18:28.561 gnuplot[24578:2a03] *** Assertion failure in
-[NSToolbar _forceInsertItem:atIndex:],
/SourceCache/AppKit/AppKit-1138/Toolbar.subproj/NSToolbar.m:1309
2011-07-30 12:18:28.562 gnuplot[24578:2a03] An uncaught exception was raised
2011-07-30 12:18:28.574 gnuplot[24578:2a03] Invalid parameter not
satisfying: index>=0 && index<=[self _numberOfItems]
2011-07-30 12:18:28.645 gnuplot[24578:2a03] (
	0   CoreFoundation                      0x00007fff93730986
__exceptionPreprocess + 198
	1   libobjc.A.dylib                     0x00007fff93a0fd5e
objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff937307ba
+[NSException raise:format:arguments:] + 106
	3   Foundation                          0x00007fff8d5c114f
-[NSAssertionHandler
handleFailureInMethod:object:file:lineNumber:description:] + 169
	4   AppKit                              0x00007fff8abb384f
-[NSToolbar _forceInsertItem:atIndex:] + 163
	5   AppKit                              0x00007fff8abb3626
-[NSToolbar _insertItem:atIndex:notifyDelegate:notifyView:notifyFamilyAndUpdateDefaults:]
+ 121
	6   AppKit                              0x00007fff8abb3361
-[NSToolbar _insertNewItemWithItemIdentifier:atIndex:propertyListRepresentation:notifyFlags:]
+ 118
	7   libwx_osx_cocoau_core-2.9.2.0.0.dylib 0x000000010302c086
_ZN9wxToolBar7RealizeEv + 1824
	8   gnuplot                             0x00000001025c7e81
_ZN8wxtFrameC2ERK8wxStringi + 1759
	9   gnuplot                             0x00000001025be6bb
_ZN6wxtApp14OnCreateWindowER14wxCommandEvent + 41
	10  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b85ef
_ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent
+ 93
	11  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba32a
_ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler + 320
	12  libwx_baseu-2.9.2.0.0.dylib         0x00000001036bb132
_ZN12wxEvtHandler16TryBeforeAndHereER7wxEvent + 92
	13  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba3ac
_ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent + 30
	14  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b9a6d
_ZN12wxEvtHandler12ProcessEventER7wxEvent + 159
	15  gnuplot                             0x00000001025c346d wxt_init + 781
	16  gnuplot                             0x00000001025ae61f
term_initialise + 271
	17  gnuplot                             0x0000000102513090 do_plot + 592
	18  gnuplot                             0x000000010253d760 eval_plots + 26976
	19  gnuplot                             0x00000001024e9aff do_line + 783
	20  gnuplot                             0x00000001024eaa01 com_line + 81
	21  gnuplot                             0x00000001025335f5 main + 1285
	22  gnuplot                             0x00000001024de864 start + 52
	23  ???                                 0x0000000000000001 0x0 + 1
)
2011-07-30 12:18:28.646 gnuplot[24578:2a03] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason:
'Invalid parameter not satisfying: index>=0 && index<=[self
_numberOfItems]'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff93730986
__exceptionPreprocess + 198
	1   libobjc.A.dylib                     0x00007fff93a0fd5e
objc_exception_throw + 43
	2   CoreFoundation                      0x00007fff937307ba
+[NSException raise:format:arguments:] + 106
	3   Foundation                          0x00007fff8d5c114f
-[NSAssertionHandler
handleFailureInMethod:object:file:lineNumber:description:] + 169
	4   AppKit                              0x00007fff8abb384f
-[NSToolbar _forceInsertItem:atIndex:] + 163
	5   AppKit                              0x00007fff8abb3626
-[NSToolbar _insertItem:atIndex:notifyDelegate:notifyView:notifyFamilyAndUpdateDefaults:]
+ 121
	6   AppKit                              0x00007fff8abb3361
-[NSToolbar _insertNewItemWithItemIdentifier:atIndex:propertyListRepresentation:notifyFlags:]
+ 118
	7   libwx_osx_cocoau_core-2.9.2.0.0.dylib 0x000000010302c086
_ZN9wxToolBar7RealizeEv + 1824
	8   gnuplot                             0x00000001025c7e81
_ZN8wxtFrameC2ERK8wxStringi + 1759
	9   gnuplot                             0x00000001025be6bb
_ZN6wxtApp14OnCreateWindowER14wxCommandEvent + 41
	10  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b85ef
_ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent
+ 93
	11  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba32a
_ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler + 320
	12  libwx_baseu-2.9.2.0.0.dylib         0x00000001036bb132
_ZN12wxEvtHandler16TryBeforeAndHereER7wxEvent + 92
	13  libwx_baseu-2.9.2.0.0.dylib         0x00000001036ba3ac
_ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent + 30
	14  libwx_baseu-2.9.2.0.0.dylib         0x00000001036b9a6d
_ZN12wxEvtHandler12ProcessEventER7wxEvent + 159
	15  gnuplot                             0x00000001025c346d wxt_init + 781
	16  gnuplot                             0x00000001025ae61f
term_initialise + 271
	17  gnuplot                             0x0000000102513090 do_plot + 592
	18  gnuplot                             0x000000010253d760 eval_plots + 26976
	19  gnuplot                             0x00000001024e9aff do_line + 783
	20  gnuplot                             0x00000001024eaa01 com_line + 81
	21  gnuplot                             0x00000001025335f5 main + 1285
	22  gnuplot                             0x00000001024de864 start + 52
	23  ???                                 0x0000000000000001 0x0 + 1
)
terminate called throwing an exceptionAbort trap: 6


It might be a bug in wxWidgets, but I have no idea what to do.

Mojca

Re: Any chance to fix gnuplot on mac?

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

2011/7/24 Mojca Miklavec wrote:
>
>>> And what about Qt?
>
> Sadly I cannot test it if it works yet. I get
>    Terminal type set to 'qt'
> but I was building on a remote machine and I have no GUI access to it.

I finally came back to my computer where I compiled gnuplot with Qt
support last week.

When I run gnuplot and try to plot something, it opens a new window
which doesn't respond (one can only force-quit).

In contrast to wxWidgets it doesn't even plot anything.

In the meantime it seems that pango, cairo and wxWidgets 2.9.2 have
been repaired in MacPorts somehow. I will now try to build wxWidgets
and see how that works.

Mojca

Re: [OctDev] help on Octave / gnuplot

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

On Wed, Jul 27, 2011 at 18:23, Daniel J Sebald wrote:
>
> Someone submitted a question to OctDev list that seems like it should
> fall under gnuplot--something about incompatibility in a "dylib"
> library.  The text is here:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=704575DE-4EDB-4C4A-9FF2-D9C599BA3B71%40gmail.com&forum_name=octave-dev
>
> Any OS X gnuplot users have an idea on this one?  Perhaps it isn't even
> a gnuplot issue, but simply that "dylib" is accessing a font library
> that is older than "dylib" is looking for.

This is not strictly a gnuplot issue.

Someone from Octave community is compiling gnuplot binary that
statically links against some libraries (which should be fine) and
dynamically against system libraries. The problem may appear if
gnuplot has been compiled on a newer system (with newer libraries)
than that user is using. (But the problem may just as well appear if
user has newer system.)

This is a problem of gnuplot community only to the extent that gnuplot
community doesn't provide any Mac binaries at all (else Octave could
have simply taken that - hopefully working - binary).

Mojca

Re: [OctDev] help on Octave / gnuplot

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

Someone submitted a question to OctDev list that seems like it should 
fall under gnuplot--something about incompatibility in a "dylib" 
library.  The text is here:

http://sourceforge.net/mailarchive/forum.php?thread_name=704575DE-4EDB-4C4A-9FF2-D9C599BA3B71%40gmail.com&forum_name=octave-dev

Any OS X gnuplot users have an idea on this one?  Perhaps it isn't even 
a gnuplot issue, but simply that "dylib" is accessing a font library 
that is older than "dylib" is looking for.

Dan

Re: Any chance to fix gnuplot on mac?

[Lutz M. <lut...@gm...>]

On Sun, Jul 24, 2011 at 12:16 AM, Mojca Miklavec
<moj...@gm...> wrote:
> On Sun, Jul 24, 2011 at 05:05, Ethan Merritt <merritt@u.washington.edu> wrote:
>> On Saturday, 23 July 2011, Mojca Miklavec wrote:
>>> Just replace "-laquaterm" with "-framework AquaTerm". Everywhere.
>>> (Some users argued that one should better use "-Wl,-framework
>>> -Wl,AquaTerm".
>>
>> It appears a grand total of one place, in m4/apple.m4
>> So OK, I've changed this one place and commited it to CVS.
>> Could you please confirm that it works from a fresh check-out?
>
> Thank you very much. But this wasn't quite enough and there are still
> a few problems. (It still works with the old setup, but not yet on the
> new one ...)

I haven't had a chance to try Ethan's change yet, but I believe that
the predefined AC_CHECK_LIB macro that is used in m4/apple.m4
generates the test in ./configure that attempts to link against the
aquaterm dynamic library. To replace that by a test that links against
the aquaterm framework, one would have to write a new macro (let's
call it AC_CHECK_FRAMEWORK), which could probably be based on the
predefined AC_CHECK_LIB macro. The other thread already mentions two
possible solutions found on the web, another might be this one:

http://trac.imagemagick.org/browser/ImageMagick/trunk/m4/framework.m4

This one seems to be very similar to the AC_CHECK_LIB macro that ships
with autoconf:

http://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/libs.m4

Hope this helps,

  Lutz

Re: wxt terminal does not work on the recent cvs

[Ethan M. <merritt@u.washington.edu>]

On Sunday, 24 July 2011, Tatsuro MATSUOKA wrote:
> Hello
> On the cvs source 2011-07-23, wxt terminal does not work on the windows build.
>  As shown attachment file, the graph window fall into no response.
> 
>  I have confirmed this bug appear after the change,
>  #***********
>  2011-07-23 Adam Strzelecki <on...@us...>

> I have registered this on the bug tracker.
> BUG #3376861
> 
> Regards
> 
> Tatsuro

Thank you for testing, and for the report.

I see two possible errors in yesterday's patch.
I have tried to repair them in today's CVS.
Please let me know if there is still a problem.

	Ethan 

wxt terminal does not work on the recent cvs

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

Hello
On the cvs source 2011-07-23, wxt terminal does not work on the windows build.
 As shown attachment file, the graph window fall into no response.

 I have confirmed this bug appear after the change,
 #***********
 2011-07-23 Adam Strzelecki <on...@us...>

 * src/wxterminal/wxt_gui.cpp src/wxterminal/wxt_gui.h m4/apple.m4:
 OSX support for wxt terminal. For OSX, switch to using single-threaded
 hybrid GUI & console event loop at wxt_waitforinput().
 Add -framework ApplicationServices to the apple-specific
 configuration flags.
 #**************
 The above changes have side effect for windows build.

I have registered this on the bug tracker.
BUG #3376861

Regards

Tatsuro

enable/disable vs. with/without

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

Dear list,

I have a question (or suggestion, but not sure what would be the best
way). It is very low on priority list, but I would like to hear some
opinion about it.

Whenever I want to turn on or off some terminal, I always have problem
figuring out what switch is needed.

For example, qt needs --enable-qt, enabling/disabling x11 requires
--with-x/--without-x, wxt requires
--enable-wxwidgets/--disable-wxwidgets, ...

Would it be possible to have some consistent naming like:
    --enable-wxt
    --enable-x11
    --disable-aqua
or --(enable|disable)-term-<name> or --with[out]-term-<name>

with proper terminal names as opposed to some string that one need to
be checked help every single time. These could simply be symlinks, but
would be much easier to remember. And then maybe also something like
    --with-default-term=<name>

Thank you,
    Mojca

Re: Any chance to fix gnuplot on mac?

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

On Sun, Jul 24, 2011 at 12:10, Mojca Miklavec wrote:
>
> wxt:
> - Once I'm back home I will try to test with 2.8.

Or not. The port "cairo +universal" seems to be broken, so I cannot
build wxwidgets on Lion at all at the moment. Not that this has
anything to do with gnuplot, but it will take time until building
xwidgets is resolved in macports.

http://trac.macports.org/ticket/30135
http://trac.macports.org/ticket/29842

citing:
>>>>>
The problem as I understood it is that some of the cctools (e.g. lipo,
libtool) don't understand LLVM bitcode. Specifically, they don't know
how to determine the architecture of a bitcode file.

So lipo, and anything that uses it to read/write fat Mach-O and
archive files, are all useless right now for dealing with LLVM bitcode
objects, as well as archives composed entirely of bitcode objects.
Same for libtool. I filed radar 9087924 for this; so far, I haven't
gotten a response.

Mojca

Re: Any chance to fix gnuplot on mac?

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

I ran out of time (will be back in August), so here is a quick summary:

AquaTerm:
- needs another patch to check if aquaterm can be built at all
- needs a few more tweaks to replace -laquaterm with -framework
AquaTerm in ./configure

Qt:
- building worked for me after patching Makefile
- I will test if plotting works when I'm back home
- I will test if building works with Qt installed by MacPorts
- one needs to make sure that even if pkg-config doesn't return
anything about Qt, the libraries can still be included with proper
flags and that moc, uic, ... are taken from PATH

wxt:
- Thanks a lot for applying the patches. That makes testing zillions
of times easier.
- Version 2.9 doesn't compile with MacPorts. I'm waiting for
developers to reply, but it would be great if gnuplot supported
2.9(.2)
    http://trac.macports.org/ticket/30340
- Once I'm back home I will try to test with 2.8.
- Once I'm back home I hope that the patch for MacPorts will be ready,
so that I will be able to try with 2.9 as well.
- I would strongly suggest to concentrate to make sure that 2.9 will
work since 2.8 uses outdated/abandoned technology that will 90% stop
working when Mac OS X 10.8 comes out (or whatever the next version
will be called; maybe iOS XI :) - that might be in year and a half or
two years at most.

Mojca

Re: Any chance to fix gnuplot on mac?

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

On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote:
>
> Have you tried this recently submitted patch?
>  #3358726 wxt (wxWidgets) Mac support patch
>  "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac"
>  https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055
> If somebody confirms that it works, I'd be happy to apply it to CVS immediately.
> I already checked that it doesn't harm wxt support on linux.

I cannot test because wxWidgets-devel port from MacPorts is broken and
I'm not eager to compile wxWidgets by hand.

The reason why I try to use wxWigdets-devel is because that one
contains version 2.9.2 as opposed to 2.8.something and that one has
considerably better (but mainly different) support for Mac and if
anything it makes sense to test with the latest version. 2.9.2 was
released in beginning of July.

Mojca

Re: Any chance to fix gnuplot on mac?

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

2011/7/24 Jérôme Lodewyck wrote:
> Le samedi 23 juillet 2011, Mojca Miklavec a écrit :
>> And what about Qt?
>>
>> Last time when I tried it (after patching some flags) it was stuck at
>>
>> ./configure --enable-qt
>>
>>  qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h:
>>  No such file or directory
>>
>> I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot
>> and that it was referenced from the file mentioned above.
>>
>> I'm willing to help to sort out the missing flags, but I cannot help
>> if files are missing.

First of all, here is what I did:

export QT_CFLAGS="-I/Library/Frameworks/QtCore.framework/Headers
-I/Library/Frameworks/QtGui.framework/Headers
-I/Library/Frameworks/QtNetwork.framework/Headers
-I/Library/Frameworks/QtSvg.framework/Headers"

export QT_LIBS="-F/Library/Frameworks -framework QtCore -framework
QtGui -framework QtNetwork -framework QtSvg"

./configure --enable-qt


> ui_QtGnuplotSettings.h is not missing. It should be generated by the build
> system from the file QtGnuplotSettings.ui, using the uic program. The command
> for the generation of this file is located at lines 107 and 141 in
> gnuplot/src/Makefile.am
> I am no Apple expert, so I cannot say what goes wrong with the generation of
> this file in mac os. A workaround would be to manually generate this file :
>
>        cd gnuplot/src/qtterminal
>        uic -o ui_QtGnuplotSettings QtGnuplotSettings.ui

I had to use
    uic -o ui_QtGnuplotSettings.h QtGnuplotSettings.ui

(I had to add ".h")


> the same goes for moc_* files.

I didn't know what exactly I had to do with moc_ files. After some
inspection I realized that I had the following line in Makefile:
    MOC =
so after configuring I edited it manually to read
    MOC = moc
and then the build went through and qt terminal is available.

Sadly I cannot test it if it works yet. I get
    Terminal type set to 'qt'
but I was building on a remote machine and I have no GUI access to it.

I will retry on the local machine once I remember what exactly I have
to install (if that is SDK or just libraries). But the SDK is 1 GB and
it will take time before I can download it from my current location.

In the meantime I can still help figuring out what to do with uic/moc
& how to recognize Qt libaries (QT_CFLAGS, QT_LIBS) without having to
specify them manually.

Mojca

Re: Any chance to fix gnuplot on mac?

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

On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote:
> On Saturday, 23 July 2011, Mojca Miklavec wrote:
>> So basically dummy is the only terminal on Mac that works reliably.
>
> That is simply not true.  x11 works fine.
> Some [many?] Mac users are prejudiced against x11, but there's not much
> we can do about that.

There is one thing that gnuplot could do for those who prefer x11:

- enable building gnuplot without aquaterm (I wasn't able to figure
out if that was possible at all; to disable X11 one simply uses
"--without-x" which I often did)

- add some configure-time option to set x11 (or any other terminal) as
the default one

Mojca


Unrelated: is this important in any way?

test -z "allterm.h " || rm -f allterm.h
test -d htmldocs && rm -rf htmldocs
make[1]: [clean-generic] Error 1 (ignored)
rm -f *.o core *.core

Re: Any chance to fix gnuplot on mac?

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

On Sun, Jul 24, 2011 at 05:05, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Saturday, 23 July 2011, Mojca Miklavec wrote:
>> On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote:
>> > On Saturday, 23 July 2011, Mojca Miklavec wrote:
>> >> So basically dummy is the only terminal on Mac that works reliably.
>> >
>> > That is simply not true.  x11 works fine.
>> > Some [many?] Mac users are prejudiced against x11, but there's not much
>> > we can do about that.
>>
>> I never said that gnuplot could do anything about that. Apple has no
>> interest in fixing or improving X any further from current situation.
>> They want to push Cocoa to developers.
>>
>> >> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt?
>> >
>> > Is AquaTerm 1.<latest> now at a state where it supports mousing?
>>
>> No.
>>
>> > If not, then I think it's a waste of time compared to sorting out
>> > wxt or canvas.
>>
>> Canvas might work as it is already, but one needs to open web browser
>> separately.
>>
>> wxt needs quite some coding to start working. (It would be nice to
>> sort it out, but that *really* takes an apple specialist.)
>>
>> > Have you tried this recently submitted patch?
>> >  #3358726 wxt (wxWidgets) Mac support patch
>> >  "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac"
>> >  https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055
>> > If somebody confirms that it works, I'd be happy to apply it to CVS immediately.
>> > I already checked that it doesn't harm wxt support on linux.
>>
>> No, I didn't know about that patch. Thank you for this pointer. But
>> I'm now working on Lion. I first need to check if I can get xwidgets
>> to compile at all.
>>
>> And what about Qt?
>>
>> Last time when I tried it (after patching some flags) it was stuck at
>>
>> ./configure --enable-qt
>>
>>  qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h:
>>  No such file or directory
>>
>> I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot
>> and that it was referenced from the file mentioned above.
>>
>> I'm willing to help to sort out the missing flags, but I cannot help
>> if files are missing.
>>
>> > In any event, I'd be happy to take patch[es] that come with a note
>> > "apply this and aquaterm will work out of the box on OSX 10.whatever".
>>
>> Just replace "-laquaterm" with "-framework AquaTerm". Everywhere.
>> (Some users argued that one should better use "-Wl,-framework
>> -Wl,AquaTerm".
>
> It appears a grand total of one place, in m4/apple.m4
> So OK, I've changed this one place and commited it to CVS.
> Could you please confirm that it works from a fresh check-out?

Thank you very much. But this wasn't quite enough and there are still
a few problems. (It still works with the old setup, but not yet on the
new one ...)

checking for aqtInit in -laquaterm... no

The configure script now looks as below and only applies "-framework
AquaTerm" if it confirms that -laquaterm switch works. In other words:
if -laquaterm works, then it compiles gnuplot with -Wl,-framework
-Wl,AquaTerm:

gcc -g -O2 -ObjC -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
-L/opt/local/lib -o doc2gih doc2gih.o termdoc.o -Wl,-framework
-Wl,AquaTerm  -framework Foundation -L/opt/local/lib -lz
-lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype
-lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0
-lintl


_ACEOF
if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
  $EGREP "yes" >/dev/null 2>&1; then :
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
$as_echo "yes" >&6; }
     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for aqtInit in
-laquaterm" >&5
$as_echo_n "checking for aqtInit in -laquaterm... " >&6; }
if ${ac_cv_lib_aquaterm_aqtInit+:} false; then :
  $as_echo_n "(cached) " >&6
else
  ac_check_lib_save_LIBS=$LIBS
LIBS="-laquaterm -lobjc $LIBS"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char aqtInit ();
int
main ()
{
return aqtInit ();
  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_link "$LINENO"; then :
  ac_cv_lib_aquaterm_aqtInit=yes
else
  ac_cv_lib_aquaterm_aqtInit=no
fi
rm -f core conftest.err conftest.$ac_objext \
    conftest$ac_exeext conftest.$ac_ext
LIBS=$ac_check_lib_save_LIBS
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ac_cv_lib_aquaterm_aqtInit" >&5
$as_echo "$ac_cv_lib_aquaterm_aqtInit" >&6; }
if test "x$ac_cv_lib_aquaterm_aqtInit" = xyes; then :
   LIBS="-Wl,-framework -Wl,AquaTerm $LIBS -framework Foundation"
       CFLAGS="$CFLAGS -ObjC"

$as_echo "#define HAVE_LIBAQUATERM 1" >>confdefs.h

> (I have a bad feeling that this may break previously-working
>  setups that were indeed really using a dylib rather than a
>  framework.  But I guess someone will speak up, if so.)

Even in previously-working setups:
- libaquaterm.dylib is just a symlink to AquaTerm file in Framework
- it didn't work with libaquaterm in /opt/local/lib without extra
flags (it still doesn't since it dosen't apply the extra flag)
- it was checking if aquaterm is installed on system dir and then used
the one from MacPorts


Also, Lutz Maibaum sent another patch which I thing should be applied:

>>>>>>>>>>
Could you try this one-line change in configure.in, run the prepare
script, and then try to configure?

 1357c1357
 < if test "$is_apple" = yes; then
 ---
 > if test "$ac_cv_lib_aquaterm_aqtInit" = yes; then
<<<<<<<<<<

It doesn't really make any difference to the binary, but at least it
properly reports whether the terminal will be used.

Mojca

Re: Any chance to fix gnuplot on mac?

[Jérôme L. <lod...@us...>]

Le samedi 23 juillet 2011, Mojca Miklavec a écrit :
> And what about Qt?
> 
> Last time when I tried it (after patching some flags) it was stuck at
> 
> ./configure --enable-qt
> 
>  qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h:
>  No such file or directory
> 
> I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot
> and that it was referenced from the file mentioned above.
> 
> I'm willing to help to sort out the missing flags, but I cannot help
> if files are missing.

ui_QtGnuplotSettings.h is not missing. It should be generated by the build 
system from the file QtGnuplotSettings.ui, using the uic program. The command 
for the generation of this file is located at lines 107 and 141 in 
gnuplot/src/Makefile.am
I am no Apple expert, so I cannot say what goes wrong with the generation of 
this file in mac os. A workaround would be to manually generate this file :

	cd gnuplot/src/qtterminal
	uic -o ui_QtGnuplotSettings QtGnuplotSettings.ui

the same goes for moc_* files.

If you can sort out these build system issues, I believe that the Qt terminal 
should work on Mac os without code changes.

Jérôme

Re: Any chance to fix gnuplot on mac?

[Ethan M. <merritt@u.washington.edu>]

On Saturday, 23 July 2011, Mojca Miklavec wrote:
> On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote:
> > On Saturday, 23 July 2011, Mojca Miklavec wrote:
> >> So basically dummy is the only terminal on Mac that works reliably.
> >
> > That is simply not true.  x11 works fine.
> > Some [many?] Mac users are prejudiced against x11, but there's not much
> > we can do about that.
> 
> I never said that gnuplot could do anything about that. Apple has no
> interest in fixing or improving X any further from current situation.
> They want to push Cocoa to developers.
> 
> >> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt?
> >
> > Is AquaTerm 1.<latest> now at a state where it supports mousing?
> 
> No.
> 
> > If not, then I think it's a waste of time compared to sorting out
> > wxt or canvas.
> 
> Canvas might work as it is already, but one needs to open web browser
> separately.
> 
> wxt needs quite some coding to start working. (It would be nice to
> sort it out, but that *really* takes an apple specialist.)
> 
> > Have you tried this recently submitted patch?
> >  #3358726 wxt (wxWidgets) Mac support patch
> >  "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac"
> >  https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055
> > If somebody confirms that it works, I'd be happy to apply it to CVS immediately.
> > I already checked that it doesn't harm wxt support on linux.
> 
> No, I didn't know about that patch. Thank you for this pointer. But
> I'm now working on Lion. I first need to check if I can get xwidgets
> to compile at all.
> 
> And what about Qt?
> 
> Last time when I tried it (after patching some flags) it was stuck at
> 
> ./configure --enable-qt
> 
>  qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h:
>  No such file or directory
> 
> I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot
> and that it was referenced from the file mentioned above.
> 
> I'm willing to help to sort out the missing flags, but I cannot help
> if files are missing.
> 
> > In any event, I'd be happy to take patch[es] that come with a note
> > "apply this and aquaterm will work out of the box on OSX 10.whatever".
> 
> Just replace "-laquaterm" with "-framework AquaTerm". Everywhere.
> (Some users argued that one should better use "-Wl,-framework
> -Wl,AquaTerm".

It appears a grand total of one place, in m4/apple.m4
So OK, I've changed this one place and commited it to CVS.
Could you please confirm that it works from a fresh check-out?

(I have a bad feeling that this may break previously-working
 setups that were indeed really using a dylib rather than a
 framework.  But I guess someone will speak up, if so.)

	Ethan


> I can confirm that it works both ways and that some
> other projects use it as well, but I don't know why this is better. It
> probably really is, but I don't know why.)
> 
> From man page:
>        -Wl,option
>            Pass option as an option to the linker.  If option contains commas,
>            it is split into multiple options at the commas.
> 
> MacPorts will have to apply an additional parameter
> "-F/opt/local/Library/Frameworks" to LDFLAGS (but I'm not sure where
> this can best be done; it can also be done in the same line as
> ./configure, but that can be sorted out by maports developers; they
> already have to add -L/opt/local/lib anyway).
> 
> Mojca
> 

Re: Any chance to fix gnuplot on mac?

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

On Sat, Jul 23, 2011 at 19:51, Ethan Merritt wrote:
> On Saturday, 23 July 2011, Mojca Miklavec wrote:
>> So basically dummy is the only terminal on Mac that works reliably.
>
> That is simply not true.  x11 works fine.
> Some [many?] Mac users are prejudiced against x11, but there's not much
> we can do about that.

I never said that gnuplot could do anything about that. Apple has no
interest in fixing or improving X any further from current situation.
They want to push Cocoa to developers.

>> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt?
>
> Is AquaTerm 1.<latest> now at a state where it supports mousing?

No.

> If not, then I think it's a waste of time compared to sorting out
> wxt or canvas.

Canvas might work as it is already, but one needs to open web browser
separately.

wxt needs quite some coding to start working. (It would be nice to
sort it out, but that *really* takes an apple specialist.)

> Have you tried this recently submitted patch?
>  #3358726 wxt (wxWidgets) Mac support patch
>  "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac"
>  https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055
> If somebody confirms that it works, I'd be happy to apply it to CVS immediately.
> I already checked that it doesn't harm wxt support on linux.

No, I didn't know about that patch. Thank you for this pointer. But
I'm now working on Lion. I first need to check if I can get xwidgets
to compile at all.

And what about Qt?

Last time when I tried it (after patching some flags) it was stuck at

./configure --enable-qt

 qtterminal/QtGnuplotWidget.cpp:280:34: error: ui_QtGnuplotSettings.h:
 No such file or directory

I can only confirm that ui_QtGnuplotSettings.h was missing in gnuplot
and that it was referenced from the file mentioned above.

I'm willing to help to sort out the missing flags, but I cannot help
if files are missing.

> In any event, I'd be happy to take patch[es] that come with a note
> "apply this and aquaterm will work out of the box on OSX 10.whatever".

Just replace "-laquaterm" with "-framework AquaTerm". Everywhere.
(Some users argued that one should better use "-Wl,-framework
-Wl,AquaTerm". I can confirm that it works both ways and that some
other projects use it as well, but I don't know why this is better. It
probably really is, but I don't know why.)

>From man page:
       -Wl,option
           Pass option as an option to the linker.  If option contains commas,
           it is split into multiple options at the commas.

MacPorts will have to apply an additional parameter
"-F/opt/local/Library/Frameworks" to LDFLAGS (but I'm not sure where
this can best be done; it can also be done in the same line as
./configure, but that can be sorted out by maports developers; they
already have to add -L/opt/local/lib anyway).

Mojca

Re: Any chance to fix gnuplot on mac?

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

2011/7/23 Hans-Bernhard Bröker wrote:
> On 23.07.2011 15:26, Mojca Miklavec wrote:
>>
>> The situation of GUI support on Mac is as follows:
>> - x11 is horrible (not because of x11 itself, but because of system
>> integration of X11 in mac)
>
> The way it looks, Aquaterm feels much the same.  It's system integration
> that sucks there.

AquaTerm may lack some features like mousing events, but the terminal
still works perfectly fine.

>> Can someone *PLEASE* fix at least AquaTerm. if nobody cares about qt and
>> wxt?
>
> I think we have established quite convincingly that you're looking in the
> wrong place for people who might be able to do that.  Fixing this needs
> expertise that quite apparently nobody on this mailing list has. We may be
> able to help with the autoconf internals, but that's about it.

I'm asking *exactly* about the autoconf help. I can tell you exactly
how gcc call has to be made and I can tell you exactly how ./conigure
script needs to look like, but:
- I cannot make any commits to repository
- I don't know how to write input for ./prepare script (for autotools)

> That whole -framwork concept is an Apple-ism that exists nowhere else.

Well, yes. But you could say the same for windows. (I'm sorry for a
bit of sarcasm and a not-exactly-true-statement - but the whole
autotools horror also only exists on gnu platforms :) :) :)

> That,
> and the fact that Apple is the only platform this appears to ever break on,
> means it'll take an Apple specialist to find out what exactly goes wrong,

Apple specialists will be able to tell you how to fix xcode projects
or how to fix the command line that compiles gnuplot. Apple
specialists won't be able to tell you how to work with autotools.

The *only* thing that needs to be fixed is to replace
    -laquaterm
with
    -framework AquaTerm
in LDFLAGS in any given call (both to test for existence of aquaterm
and to actually build it).

> and possibly fix it.  You tried to find such specialists here a couple of
> times now, and came up empty.  I think you need to concentrate your search
> elsewhere.

Matlab?

Mojca

Re: Any chance to fix gnuplot on mac?

[Ethan M. <merritt@u.washington.edu>]

On Saturday, 23 July 2011, Mojca Miklavec wrote:
> So basically dummy is the only terminal on Mac that works reliably.

That is simply not true.  x11 works fine.  
Some [many?] Mac users are prejudiced against x11, but there's not much
we can do about that.
 
> Can someone PLEASE fix at least AquaTerm. if nobody cares about qt and wxt?

Is AquaTerm 1.<latest> now at a state where it supports mousing?
If not, then I think it's a waste of time compared to sorting out
wxt or canvas.

Have you tried this recently submitted patch?
  #3358726 wxt (wxWidgets) Mac support patch
  "(for both 4.4 stable & 4.5 CVS) let's wxt terminal work fine on Mac"
  https://sourceforge.net/tracker/?func=detail&atid=302055&aid=3358726&group_id=2055
If somebody confirms that it works, I'd be happy to apply it to CVS immediately.
I already checked that it doesn't harm wxt support on linux.

In any event, I'd be happy to take patch[es] that come with a note
"apply this and aquaterm will work out of the box on OSX 10.whatever".
But I'm not a Mac user, so I am dependent on contributions from
elsewhere.

The one pathway that I think I could manage on my own, if there is sufficient
interest, is to document use of gnuplot's canvas and/or svg terminals 
with safari as an interactive viewer.  Unless things have changed on the
aquaterm side, that actually gets you more supported features anyhow.

	Ethan

Re: Any chance to fix gnuplot on mac?

[Hans-Bernhard B. <HBB...@t-...>]

On 23.07.2011 15:26, Mojca Miklavec wrote:
> The situation of GUI support on Mac is as follows:
> - x11 is horrible (not because of x11 itself, but because of system
> integration of X11 in mac)

The way it looks, Aquaterm feels much the same.  It's system integration 
that sucks there.

> Can someone *PLEASE* fix at least AquaTerm. if nobody cares about qt and wxt?

I think we have established quite convincingly that you're looking in 
the wrong place for people who might be able to do that.  Fixing this 
needs expertise that quite apparently nobody on this mailing list has. 
We may be able to help with the autoconf internals, but that's about it.

That whole -framwork concept is an Apple-ism that exists nowhere else. 
That, and the fact that Apple is the only platform this appears to ever 
break on, means it'll take an Apple specialist to find out what exactly 
goes wrong, and possibly fix it.  You tried to find such specialists 
here a couple of times now, and came up empty.  I think you need to 
concentrate your search elsewhere.

Re: building with AquaTerm

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

On Sat, Jul 23, 2011 at 00:12, Lutz Maibaum wrote:
> On Jul 22, 2011, at 3:37 AM, Mojca Miklavec wrote:
>> On Fri, Jul 22, 2011 at 03:59, Lutz Maibaum wrote:
>>>> This would help in the case of macports. It doesn't help with aquaterm
>>>> 1.1.0 which doesn't install libaquaterm.dylib at all.
>>>
>>> It doesn't install a dynamic library at all, not even within the framework directory structure?
>>
>> Of course it installs it into the framework.
>
> Couldn't you then just add the proper location within the framework hierarchy to the LDFLAGS

Do you mean adding
-L/Library/Frameworks/AquaTerm.framework/Versions/Current or something
else?

First of all, that would not work since the file used there is called
AquaTerm as opposed to libaquaterm.dylib. Second of all that defeats
the whole purpose of using Mac-friendly solutions. That juts reverts
the author's attempt for better ("more native") integration of his
package into the system.

> (as a temporary workaround)?

As a temporary workaround I can do anything. I didn't ask because I
would be looking for help with compiling. I would like gnuplot
official source to be fixed in order to work out of the box.

I need to use my own fork of gnuplot anyway since ConTeXt will
apparently never be supported.

Mojca

Any chance to fix gnuplot on mac?

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

The situation of GUI support on Mac is as follows:
- x11 is horrible (not because of x11 itself, but because of system
integration of X11 in mac)
- wxt is broken (more or less by design - quite some code is missing
that would allow it to work; zero support)
- qt is broken (to start with, the flags to compile it are broken; and
if those are fixed manually, source files for gnuplot requested by
#include in gnuplot src are missing; no response from developers about
reports)
- aquaterm compilation is broken

So basically dummy is the only terminal on Mac that works reliably.

Can someone *PLEASE* fix at least AquaTerm. if nobody cares about qt and wxt?

Mojca