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