gnuplot development

On Wednesday, March 09, 2011 07:12:54 am Mojca Miklavec wrote:
> What happens?
> --------------------
> If I don't install AquaTerm manually, the version provided by MacPorts
> doesn't suffice to compile gnuplot with aquaterm terminal which is
> probably a flaw in gnuplot configuration. Priority number one would be
> to fix that one.

This is not very helpful as a bug report.
What do you mean "doesn't suffice"?
The output from the configure script should indicate what piece
has not been found.  It could be a problem with PATH, or with the
location of a header file, or with something else entirely like a 
required support library that the configure script doesn't allow for.

> All the other libraries (pango, cairo, pdflib, gd, freetype, ...) are
> easily found from MacPorts. Here is what config.log has to say about
> pdf or gd for example:
> 
>     configure:9085: found /opt/local/bin/pdflib-config

That means pdflib comes with a path configuration file.
The configure script executes that file in order to find the
correct -I and -L directories and also a list of required libraries.
So one fix would be for the MacPorts version of aquaterm to also have 
a path configuration file.   

There is a separate, but very similar, mechanism called pkgconfig.
pkgconfig is (at least on linux) how the configuration for cairo
and freetype is found.
So if aquaterm had a *.pc file for pkgconfig, that would also work.

On Wed, Mar 9, 2011 at 19:24, Ethan A Merritt
<sfeam@...> wrote:
> On Wednesday, March 09, 2011 07:12:54 am Mojca Miklavec wrote:
>> What happens?
>> --------------------
>> If I don't install AquaTerm manually, the version provided by MacPorts
>> doesn't suffice to compile gnuplot with aquaterm terminal which is
>> probably a flaw in gnuplot configuration. Priority number one would be
>> to fix that one.
>
> This is not very helpful as a bug report.
> What do you mean "doesn't suffice"?

I wrote down most details, but I my explanation wasn't too clear.

If I use
    CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
--disable-wxwidgets
then it works, but it would be much better if it wasn't required to
manually set flags. (I didn't even come to the idea to do that until
now.)

There is
    /opt/local/lib/libaquaterm.dylib
but the folder /opt/local/ is not searched by default (without
-L/opt/local/lib), so -laquaterm fails. The same is true for headers.
There is
     /opt/local/include/aquaterm/aquaterm.h
but it is not found without -I/opt/local/include/ either.

> The output from the configure script should indicate what piece
> has not been found.

That is the output:

   configure:6792: checking for aqtInit in -laquaterm
   configure:6817: gcc -o conftest -g -O2   conftest.c -laquaterm -lobjc  >&5
   ld: library not found for -laquaterm

Compare the options with:

   configure:8736: gcc -o conftest -g -O2  -I/opt/local/include
-L/opt/local/lib conftest.c -lgd   >&5

If the test for aquaterm would have been performed with the same
options (-I/opt/local/include -L/opt/local/lib), it wouldn't fail
either, but now that these options are missing, it doesn't find
AquaTerm.


> It could be a problem with PATH, or with the
> location of a header file, or with something else entirely like a
> required support library that the configure script doesn't allow for.

It's a problem of missing -I and -L switches to search for header and
library files.

>> All the other libraries (pango, cairo, pdflib, gd, freetype, ...) are
>> easily found from MacPorts. Here is what config.log has to say about
>> pdf or gd for example:
>>
>>     configure:9085: found /opt/local/bin/pdflib-config
>
> That means pdflib comes with a path configuration file.
> The configure script executes that file in order to find the
> correct -I and -L directories and also a list of required libraries.
> So one fix would be for the MacPorts version of aquaterm to also have
> a path configuration file.
>
> There is a separate, but very similar, mechanism called pkgconfig.
> pkgconfig is (at least on linux) how the configuration for cairo
> and freetype is found.
> So if aquaterm had a *.pc file for pkgconfig, that would also work.

So all that's needed is to ask the maintainer of MacPorts package to
add a file aquaterm.pc? That is probably easier and shorter than
writing aquaterm-config script. Are you ready to fix gnuplot
configuration if that gets done? (That is: if aquaterm.pc exists,
respect its flags; if it doesn't, just try the old test to see if
-laquaterm works at all.)

The fix that should be applied right away (without waiting for
MacPorts developer) is not to print out "yes" in
    aqua terminal (MacOS X): yes
unconditionally on any given mac, but to report what configure script
has found (most probably that is ac_cv_lib_aquaterm_aqtInit). And
maybe print out the warning at the end of configure script when both
x11 and aquaterm are missing (or for the more general case: if unknown
terminal will be set as the default one).

Mojca

Mojca Miklavec wrote:
> On Wed, Mar 9, 2011 at 19:24, Ethan A Merritt
> <sfeam@...> wrote:
> > On Wednesday, March 09, 2011 07:12:54 am Mojca Miklavec wrote:
> >> What happens?
> >> --------------------
> >> If I don't install AquaTerm manually, the version provided by MacPorts
> >> doesn't suffice to compile gnuplot with aquaterm terminal which is
> >> probably a flaw in gnuplot configuration. Priority number one would be
> >> to fix that one.
> >
> > This is not very helpful as a bug report.
> > What do you mean "doesn't suffice"?
> 
> I wrote down most details, but I my explanation wasn't too clear.
> 
> If I use
>     CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
> --disable-wxwidgets
> then it works, but it would be much better if it wasn't required to
> manually set flags. (I didn't even come to the idea to do that until
> now.)

Your original post continued:
 "My next question would be how to set which aquaterm to use
  (in case there are multiple versions installed)"
One answer to that question is exactly what you have shown --
set the paths so that they are appropriate for the version of
aquaterm that you want to use.

> There is
>     /opt/local/lib/libaquaterm.dylib
> but the folder /opt/local/ is not searched by default (without
> -L/opt/local/lib), so -laquaterm fails. The same is true for headers.
> There is
>      /opt/local/include/aquaterm/aquaterm.h
> but it is not found without -I/opt/local/include/ either.

I would think that if you are relying on MacPorts for your software
installations, and if MacPorts keeps its libraries and header files in  
/opt/local,   then /opt/local should already be in your default paths.
In particular /opt/local/lib had better be in your library path because
otherwise even if you configure and build the program successfully
it will fail to run because it can't find the support libraries.

Is this really a problem specific to gnuplot and/or aquaterm, 
or is it just a normal system configuration issue?
I would have thought setting up the correct paths for /opt/local
would be part of installing MacPorts.
[goes to look via Google...]
.. and indeed it is.
The instructions are in section 2.6 of the MacPorts Guide
    http://guide.macports.org/

		Ethan

2011/3/9 Hans-Bernhard Bröker wrote:
> On 09.03.2011 19:59, Mojca Miklavec wrote:
>
>> If I use
>>     CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>> --disable-wxwidgets
>
> A side note: for quite some time this hasn't been the recommended way of
> setting flags.  That had better be
>
>  ./configure CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib
> --disable-wxwidgets
>
> i.e. with the flags initializations as arguments to ./configure, rather than
> environment variables.

Thanks for the hint. I will remember it (I was trying to use that on
several other programs and many don't favour it).

>> then it works, but it would be much better if it wasn't required to
>> manually set flags.
>
> It's up to _you_ to choose.  You can
>
> a) make sure libraries are only in places where the compiler already looks
> by default.  This is what places like /usr/local are for, and how systems
> like MacPorts supposedly work.

I would like to avoid that. *everything else* works without having to
install it separately but aquaterm.

Here are the instructions:
    http://slashusr.wordpress.com/2010/01/17/gnuplot-with-aquaterm-on-osx-snow-leopard/
But please note that it get *way* more ugly than that

Here is where all the fun begins. I *have to* install AquaTerm to
/usr/local/..., but then gnuplot will nevertheless use the version
from /opt/local/... Worse. Gnuplot will link against
/opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
and when running gnuplot, it will open /Applications/AquaTerm.app
(instead of /Applications/MacPorts/AquaTerm.app) which links against
/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm. So it will
use to possibly completely different and incompatible libraries.

And unless both the version under /opt and the "system-wide" versions
are *exactly* the same, nothing will work at all. (It simply hangs
forever.)

> b) change your compiler's configuration so the places you keep libraries get
> added to the list of places the compiler looks in (C_INCLUDE_PATH,
> D_LIBRARY_PATH or whatever), or

Thanks. This seems to make most sense, but I would still prefer if it
would work out of the box. I have found:
       C_INCLUDE_PATH
       CPLUS_INCLUDE_PATH
       OBJC_INCLUDE_PATH
       LIBRARY_PATH
But I need to check how this inferferes with other switches like
MACOSX_DEPLOYMENT_TARGET which has its own idea about default paths to
search for. I didn't test it yet.

> c) go the hard way: explicitly add those directories to the CFLAGS etc.
> every time you ./configure or otherwise build a program.

That is tedious. I find it nasty enough that I have to keep disabling
xwidgets to aviod problems. And it is even less obvious for users with
very little experience in compiling. (Those who have to compile
gnuplot on mac for one reason or the other.)

> You really have to make up your mind: either you work _with_ systems like
> MacPorts, Find or whatever, or against them.

I'm not sure that I understood this sentence (what exactly it means in
this particular context).
What do you refer to with "work _with_ system like MacPorts"?

>> It's a problem of missing -I and -L switches to search for header and
>> library files.
>
> Or it's a problem of having put libraries in a place where the compiler
> never knew to look.

But then why do all the other libraries work? Or better: why do all
the other libraries get included even when I don't want them to be
included at all (wxterminal being the most obvious one which forces me
to use --disable-wxwidgets every time when I want to build gnuplot)?

Whenever I want to "get rid" of libraries that gnuplot or any other
program would take from MacPorts, I have to explicitely exclude
macports from PATH. AquaTerm is the only exception to the rule.

Mojca

On 09.03.2011 22:48, Mojca Miklavec wrote:
> 2011/3/9 Hans-Bernhard Bröker wrote:

> Here is where all the fun begins. I *have to* install AquaTerm to
> /usr/local/...,

Says who?  Why?

> What do you refer to with "work _with_ system like MacPorts"?

Respect the choices they made.  Put stuff where they expect it (and, 
more importantly, configured their compiler to look).  Make up your mind 
whether your newly built gnuplot is to become a part
of yoru MacPorts world, or live outside it.

> But then why do all the other libraries work? Or better: why do all
> the other libraries get included even when I don't want them to be
> included at all

Because configure can't read your mind, so it has no way of knowing what 
you want if you don't tell it.

> Whenever I want to "get rid" of libraries that gnuplot or any other
> program would take from MacPorts, I have to explicitely exclude
> macports from PATH.

Which es exactly the kind of "working against" MacPorts that I referred 
to earlier.  If you don't want to use your MacPorts, why did you install 
them in the first place?

2011/3/10 Hans-Bernhard Bröker wrote:
> On 09.03.2011 22:48, Mojca Miklavec wrote:
>>
>> 2011/3/9 Hans-Bernhard Bröker wrote:
>
>> Here is where all the fun begins. I *have to* install AquaTerm to
>> /usr/local/...,
>
> Says who?  Why?

If I want to choose the option "a)" (make sure libraries are only in
places where the compiler already looks by default).

>> What do you refer to with "work _with_ system like MacPorts"?
>
> Respect the choices they made.  Put stuff where they expect it (and, more
> importantly, configured their compiler to look).  Make up your mind whether
> your newly built gnuplot is to become a part
> of yoru MacPorts world, or live outside it.

I forgot to say: I want my gnuplot to live *outside* of MacPorts.
MacPorts already comes with gnuplot, but that one doesn't satisfy my
needs, so I need a "personal" one that I link from $HOME/bin/gnuplot
that is in my PATH.

However I find it perfectly fine if that personal copy of gnuplot uses
libraries like pdflib, cairo etc. from MacPorts. In fact, most of the
time I prefer if it uses them since it is way too painful to install
some of these libraries (and they keep crashing if I try).

>> But then why do all the other libraries work? Or better: why do all
>> the other libraries get included even when I don't want them to be
>> included at all
>
> Because configure can't read your mind, so it has no way of knowing what you
> want if you don't tell it.

So how can I for example:
- Tell gnuplot's configure script to use the version of aquaterm from
/usr and not the one from /opt (when I have macports in path)?
- Use UTF-8 input on Mac asssuming that I entirely remove MacPorts
from my system? (utf8.dem works fine, but no non-ascii characters are
accepted on input and I cannot use left alt as "alt-gr"; I just
realized that now.)

I know that configure can't read my mind, but:
- when I have aquaterm under both /usr and /opt, it uses the version from /opt
- when I have aquaterm only under /opt, it doesn't compile aquaterm
support at all (even though it could easily use the version from /opt)

I don't explicitely set anything to compile other libraries. They all
work out of the box. I honestly don't understand what is wrong with my
attempt to compile AquaTerm out-of-the-box as well.

>> Whenever I want to "get rid" of libraries that gnuplot or any other
>> program would take from MacPorts, I have to explicitely exclude
>> macports from PATH.
>
> Which es exactly the kind of "working against" MacPorts that I referred to
> earlier.

What exactly is "working against" here? If I remove MacPorts from
PATH? (If I do that *everything* works as expected.)

> If you don't want to use your MacPorts, why did you install them
> in the first place?

Let's say that I want to build a standalone Gnuplot.app that any user
could copy from my homepage and it would then work out of the box. I
need MacPorts most of the time, but if I leave MacPorts in PATH when I
compile gnuplot, other users won't be able to use the binary that I
compile due to dependencies on libraries provided by MacPorts. Please
don't tell me that I need to buy a new machine without MacPorts just
for the sake of compiling gnuplot that will be usable on other
machines?

Mojca

On Wednesday, March 09, 2011 03:41:47 pm Mojca Miklavec wrote:

> So how can I for example:
> - Tell gnuplot's configure script to use the version of aquaterm from
> /usr and not the one from /opt (when I have macports in path)?

If the one in MacPorts doesn't work, why not just replace it altogether?
Anyhow, we're past this issue now, right?  You need to set the environmental
variables appropriately before running configure.

> - Use UTF-8 input on Mac asssuming that I entirely remove MacPorts
> from my system? (utf8.dem works fine, but no non-ascii characters are
> accepted on input and I cannot use left alt as "alt-gr"; I just
> realized that now.)

Aha.  If you had explained that to start with it would have saved time.

What you describe is a symptom of linking to the fake readline supplied
as part of OSX.  It is really a wrapper for the BSD libedit library,
which cannot handle UTF-8 input.   To fix this you need to install and
link to a copy of the real gnu libreadline.   Or if you like, you could
use gnuplot's built-in readline.  That is less capable in some other areas,
but it has no trouble handling UTF-8.

This is explained in the current release and installation notes for
gnuplot.

 
> > If you don't want to use your MacPorts, why did you install them
> > in the first place?
> 
> Let's say that I want to build a standalone Gnuplot.app that any user
> could copy from my homepage and it would then work out of the box.

I don't think that is possible, or at least if it is possible than I don't 
know how to do it.  It would have to be statically linked, and even then
I don't think that would solve your aquaterm issues.


> I
> need MacPorts most of the time, but if I leave MacPorts in PATH when I
> compile gnuplot, other users won't be able to use the binary that I
> compile due to dependencies on libraries provided by MacPorts. Please
> don't tell me that I need to buy a new machine without MacPorts just
> for the sake of compiling gnuplot that will be usable on other
> machines?

The shared libraries present when you run a program must be the same
(or at least API compatible with) with libraries used to link the program.
That requirement is true for gnuplot, or aquaterm, or MacPorts, just as
it is for all other programs and shared libraries.

2011/3/10 Ethan A Merritt <sfeam@...>:
> Anyhow, we're past this issue now, right?

Not really. I would like to have aquaterm.pc or aquaterm-config or
something similar (anything that is easy enough to implement) that
would discover and include aquaterm automatically.



The rest of text was just trying to answer the "who needs that" and
"why did you install macports" part that I would prefer not to touch.

My main question is whether any of the gnuplot developers would be
willing to fix the configure script to allow building gnuplot with
MacPorts-only version of AquaTerm if aquaterm gets fixed (and what
would be the best way to fix aquaterm).

Mojca

On 10.03.2011 00:41, Mojca Miklavec wrote:
> 2011/3/10 Hans-Bernhard Bröker wrote:
>> On 09.03.2011 22:48, Mojca Miklavec wrote:
>>> 2011/3/9 Hans-Bernhard Bröker wrote:

>>> Here is where all the fun begins. I *have to* install AquaTerm to
>>> /usr/local/...,

>> Says who?  Why?

> If I want to choose the option "a)" (make sure libraries are only in
> places where the compiler already looks by default).

But it seems we've already established that /usr/local is not in your 
compiler's default search paths, either, haven't we?

> I forgot to say: I want my gnuplot to live *outside* of MacPorts.

Then you can _not_ use anything from MacPorts.  None of the libraries, 
none of the headers, possibly not even the compiler.

> However I find it perfectly fine if that personal copy of gnuplot uses
> libraries like pdflib, cairo etc. from MacPorts.

Now you're contradicting yourself.

Just because a program sits in your $HOME/bin doesn't mean it's outside 
of MacPorts.  MacPorts isn't just a directory --- it's a system of 
libraries, environment settings and configuration items that all work 
together.  Any executable built using the libraries from the MacPorts 
system is, for better or for worse, a MacPorts binary.  Even if it sits 
outside MacPorts' directories.

> So how can I for example:
> - Tell gnuplot's configure script to use the version of aquaterm from
> /usr and not the one from /opt (when I have macports in path)?

By making sure /opt appears before /usr on all your header and library 
searches (this is where an explicit -I/-L flag passed to ./configure 
might behave different from a change to environment variables: 
explicitly given directories are searched before default places), and by 
making sure you don't pull in the MacPorts version through some indirect 
connection, e.g. another library taken from MacPorts, which includes 
references to their aquaterm library.

> I know that configure can't read my mind, but:
> - when I have aquaterm under both /usr and /opt, it uses the version from /opt

That could mean your include and library search paths are the wrong way 
round.

> - when I have aquaterm only under /opt, it doesn't compile aquaterm
> support at all (even though it could easily use the version from /opt)

Then you have to dig deeper to find out why it doesn't accept that version.

Hello,

Just to clarify: the author (Per Persson) wants to remove the library
libaquaterm.dylib, so gnuplot will have to use -framework AquaTerm (as
opposed to -laquaterm) from now on. This makes quite some points from
discussion obsolete since the location of Framework is determined with
switch -F, not -L any more which makes the location of AquaTerm better
configurable.

New release is planned before end of March, so it would be great if
this gets fixed in gnuplot's cvs as soon as possible. (One has to
replace all occurences of "-laquaterm" with "-framework AquaTerm".)

(No need to comment on the rest.)

2011/3/10 Hans-Bernhard Bröker wrote:
> On 10.03.2011 00:41, Mojca Miklavec wrote:
>> 2011/3/10 Hans-Bernhard Bröker wrote:
>>> On 09.03.2011 22:48, Mojca Miklavec wrote:
>>>> 2011/3/9 Hans-Bernhard Bröker wrote:
>
>>>> Here is where all the fun begins. I *have to* install AquaTerm to
>>>> /usr/local/...,
>
>>> Says who?  Why?
>
>> If I want to choose the option "a)" (make sure libraries are only in
>> places where the compiler already looks by default).
>
> But it seems we've already established that /usr/local is not in your
> compiler's default search paths, either, haven't we?

/usr/local/lib is. /opt/local/lib isn't.

>> I forgot to say: I want my gnuplot to live *outside* of MacPorts.
>
> Then you can _not_ use anything from MacPorts.  None of the libraries,
> none of the headers, possibly not even the compiler.

I was not sure what inside/outside meant. Well - yes, I want to use
MacPorts' libraries, but the binary will be at some other location.

>> - when I have aquaterm under both /usr and /opt, it uses the version from /opt
>
> That could mean your include and library search paths are the wrong way
> round.

Actually the test for AquaTerm is performed without any flags first,
but pdflib & other libraries append -L/opt/local/lib to
compiler/linker options, so that AquaTerm will come from
/opt/local/lib at the end as well. Anyway, with -framework there is
some more freedom.

>> - when I have aquaterm only under /opt, it doesn't compile aquaterm
>> support at all (even though it could easily use the version from /opt)
>
> Then you have to dig deeper to find out why it doesn't accept that version.

I know why it doesn't. Because it doesn't know about existance of /opt
during configuration step (unless I provide an explicit CFLAGS
switch). But other libraries add -L/opt/local/lib, so once gnuplot is
aware of aquaterm existence, it will take the one from /opt.

(But again - since the default flag has to change, this means a
different set of algorithm to find the right version of AquaTerm.)

Mojca

On Thu, 10 Mar 2011, Mojca Miklavec wrote:

> Just to clarify: the author (Per Persson) wants to remove the library
> libaquaterm.dylib, so gnuplot will have to use -framework AquaTerm (as
> opposed to -laquaterm) from now on. This makes quite some points from
> discussion obsolete since the location of Framework is determined with
> switch -F, not -L any more which makes the location of AquaTerm better
> configurable.
>
> New release is planned before end of March, so it would be great if
> this gets fixed in gnuplot's cvs as soon as possible. (One has to
> replace all occurences of "-laquaterm" with "-framework AquaTerm".)

Or rather, with

  "-Wl,-framework -Wl,AquaTerm"

You're not going to endear yourself to gnuplot developers by
describing this change as a "fix" (= remedy for something broken),
when in fact it's a backward-incompatible change to gnuplot
configuration dictated by a (prospective) change to the setup of a
third-party library.

Allin Cottrell

On Thursday, March 10, 2011, Allin Cottrell wrote:
> On Thu, 10 Mar 2011, Mojca Miklavec wrote:
> 
> > Just to clarify: the author (Per Persson) wants to remove the library
> > libaquaterm.dylib, so gnuplot will have to use -framework AquaTerm (as
> > opposed to -laquaterm) from now on. This makes quite some points from
> > discussion obsolete since the location of Framework is determined with
> > switch -F, not -L any more which makes the location of AquaTerm better
> > configurable.
> >
> > New release is planned before end of March, so it would be great if
> > this gets fixed in gnuplot's cvs as soon as possible. (One has to
> > replace all occurences of "-laquaterm" with "-framework AquaTerm".)
> 
> Or rather, with
> 
>   "-Wl,-framework -Wl,AquaTerm"

How confusing.  The existing command contains "-framework Foundation".
Are you saying that "-framework Foundation -framework AquaTerm" is wrong?

> You're not going to endear yourself to gnuplot developers by
> describing this change as a "fix" (= remedy for something broken),
> when in fact it's a backward-incompatible change to gnuplot
> configuration dictated by a (prospective) change to the setup of a
> third-party library.

Indeed. I was under the impression that aquaterm was currently not working,
and that this was a fix going forward.  Have I got that wrong?

If it breaks a currently-working configuration procedure, then no, 
we should not adopt this change.   

Can we just add back the symlinks that Per Persson for some reason
doesn't like?   The configure script could test for a missing 
symlink and create it if it's not there.

Or if the license permits, maybe we could rebuild AquaTerm as a shared
library ourselves and make a copy available for download with gnuplot?

I could wish that Per, or whatever OSX gurus we have on tap,
would work on cleaning up the wxt installation on OSX.  The wxt 
terminal has more features than Aquaterm, and has the virtue of being
cross-platform.  And it seems at least some people have gotten it to
work, so it's clearly not impossible.


	Ethan

On Fri, Mar 11, 2011 at 05:26, Ethan Merritt wrote:
> On Thursday, March 10, 2011, Allin Cottrell wrote:
>> On Thu, 10 Mar 2011, Mojca Miklavec wrote:
>>
>> Or rather, with
>>
>>   "-Wl,-framework -Wl,AquaTerm"
>
> How confusing.  The existing command contains "-framework Foundation".
> Are you saying that "-framework Foundation -framework AquaTerm" is wrong?

It is definitely not wrong.
(I admit that I don't know what exactly -WI does, but when I google
for it I see that some projects use it.)

>> You're not going to endear yourself to gnuplot developers by
>> describing this change as a "fix" (= remedy for something broken),
>> when in fact it's a backward-incompatible change to gnuplot
>> configuration dictated by a (prospective) change to the setup of a
>> third-party library.
>
> Indeed. I was under the impression that aquaterm was currently not working,
> and that this was a fix going forward.  Have I got that wrong?

The problem with AquaTerm is that it is currently only available as
32-bit library and thus doesn't work on 64-bit systems (it was
released before OS X 10.6 was available). However MacPorts contains a
64-bit version and there will be a new release of AquaTerm to fix this
situation.


What is not working at the moment is when user has a 64-bit version of
AquaTerm residing inside MacPorts, but gnuplot doesn't find it without
extra LDFLAGS. Using -framework won't help here either, but it will at
least select the systemwide aquaterm by default.

> If it breaks a currently-working configuration procedure, then no,
> we should not adopt this change.

It doesn't break it. The switch -framework AquaTerm already works with
the old version (so for a very long time). Symlink was provided in
past just for the sake of backward compatibility, but the "grace
period" has been long enough.

The only thing it might "break" is the need to provide an extra switch
    LDFLAGS="-F/opt/local/Library/Frameworks"
when compiling on MacPorts (or on Fink). (A "shortcut" for that might
be ./configure --with-aquaterm=/opt/local/Library/Frameworks, but I
don't have any strong opinion about that.)

> Can we just add back the symlinks that Per Persson for some reason
> doesn't like?   The configure script could test for a missing
> symlink and create it if it's not there.

But how would you test for a missing symlink? By first trying to use
"-framework AquaTerm" and if that works, create a symlink in working
directory (possibly pointing to the wrong framework) and then use
-laquaterm instead of the already working "-framework AquaTerm"?

> Or if the license permits, maybe we could rebuild AquaTerm as a shared
> library ourselves and make a copy available for download with gnuplot?

But what exactly is the point (apart from being an alternative for not
changing configuration script)? The new AquaTerm will contain a shared
library inside the framework (just as the old one does), it will only
miss a symlink.

> I could wish that Per, or whatever OSX gurus we have on tap,
> would work on cleaning up the wxt installation on OSX.  The wxt
> terminal has more features than Aquaterm, and has the virtue of being
> cross-platform.  And it seems at least some people have gotten it to
> work, so it's clearly not impossible.

I wish it was working as well, but apparently it needs some extra code
in gnuplot.

Mojca

2011/3/10 Mojca Miklavec <mojca.miklavec.lists@...>:

> I was not sure what inside/outside meant. Well - yes, I want to use
> MacPorts' libraries, but the binary will be at some other location.

Location doesn't matter, build a Mach-O binary against MacPorts'
libraries, move to a location of your choice and use 'otool -L' on it.
It'll refer to MacPorts' libraries and therefore it's "inside"
MacPorts.


-- 
Andrea

Dear list,

I would like to revive this thread. Gnuplot needs a fix to account for
the change in AquaTerm, that is, it needs to replace -laquaterm with
-framework Aquaterm (possibly with those intermediate flags suggested
by Allin C.).

Mojca


On Wed, Mar 9, 2011 at 16:12, Mojca Miklavec
<mojca.miklavec.lists@...> wrote:
> Dear list,
>
> I'm helping Per Persson test a new version of AquaTerm. I'm using Snow
> Leopard with 64-bit architecture. The old AquaTerm only ships 32-bit
> intel and ppc architectures, however a new version will come with
> support for x86_64 (the latest version in CVS/git supports it
> already).
>
> However there is still quite a list of issues, many of them with the
> common denominator being: as long as one has MacPorts (with gnuplot or
> aquaterm package) installed, the only way to get a working version of
> self-compiled gnuplot with aquaterm terminal is to:
> - have both manually installed AquaTerm and the one installed with MacPorts
> - both versions need to match exactly
>
> What happens?
> --------------------
> If I don't install AquaTerm manually, the version provided by MacPorts
> doesn't suffice to compile gnuplot with aquaterm terminal which is
> probably a flaw in gnuplot configuration. Priority number one would be
> to fix that one.
>
> However if I do install a different version of AquaTerm, gnuplot links to
>    /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
> which belongs to MacPorts, but it opens /Applications/AquaTerm.app
> which links to
>    /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
> and then nothing happens at all. Nothing gets drawn.
>
> I have a number of other requests, I will try to do my best to fix
> AquaTerm (I still lack knowledge), but one thing should be high on
> priority list: ability to build gnuplot with aquaterm terminal without
> having to manually install AquaTerm.app.
>
> What has to be done?
> --------------------
> AquaTerm installs four things: application, framework, symbolic links:
> - /Applications/AquaTerm.app
> - /Library/Frameworks/AquaTerm.framework
> - symlinks
>  /usr/local/include/aquaterm/AQTAdapter.h
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>  /usr/local/include/aquaterm/aquaterm.h
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>  /usr/local/lib/libaquaterm.dylib
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /usr/local/lib/libaquaterm.1.1.0.dylib
>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>
> Under MacPorts that is:
> - /Applications/MacPorts/AquaTerm.app
> - /opt/local/Library/Frameworks/AquaTerm.framework
> - symlinks
>  /opt/local/include/aquaterm/AQTAdapter.h
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>  /opt/local/include/aquaterm/aquaterm.h
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>  /opt/local/lib/libaquaterm.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /opt/local/lib/libaquaterm.1.0.1.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.1.0.1.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.dylib
>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>
> When I run ./configure without having my own version of AquaTerm
> (installed manually), I get
>    aqua terminal (MacOS X): yes
> but that is a lie. config.log says:
>
>    configure:6792: checking for aqtInit in -laquaterm
>    configure:6817: gcc -o conftest -g -O2   conftest.c -laquaterm -lobjc  >&5
>    ld: library not found for -laquaterm
>    ...
>    configure:14123: result:   aqua terminal (MacOS X): yes
>    ...
>    ac_cv_lib_aquaterm_aqtInit=no
>
> I think that the catch is having "-I/opt/local/include" present when
> trying to compile some test file. The question is: how should the
> configuration script know about that? After all one could have fink or
> homebrew or whatever other package manager installed and include path
> could be anyone.
>
> All the other libraries (pango, cairo, pdflib, gd, freetype, ...) are
> easily found from MacPorts. Here is what config.log has to say about
> pdf or gd for example:
>
>    configure:9085: found /opt/local/bin/pdflib-config
>    configure:9097: result: /opt/local/bin/pdflib-config
>    configure:9120: checking for PDF_get_majorversion in -lpdf
>    configure:9145: gcc -o conftest -g -O2  -I/opt/local/include
> -I/opt/local/include  -L/opt/local/lib -L/opt/local/lib
> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib conftest.c -lpdf
>>&5
>    configure:9145: $? = 0
>
>    configure:8659: checking for gdlib-config
>    configure:8677: found /opt/local/bin/gdlib-config
>    configure:8689: result: /opt/local/bin/gdlib-config
>    configure:8711: checking for gdImageCreateTrueColor in -lgd
>    configure:8736: gcc -o conftest -g -O2  -I/opt/local/include
> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
> conftest.c -lgd   >&5
>    configure:8736: $? = 0
>    configure:8745: result: yes
>    configure:8753: checking gd.h usability
>    configure:8753: gcc -c -g -O2  -I/opt/local/include conftest.c >&5
>    configure:8753: $? = 0
>    configure:8753: result: yes
>    configure:8753: checking gd.h presence
>    configure:8753: gcc -E  -I/opt/local/include conftest.c
>    configure:8753: $? = 0
>    configure:8753: result: yes
>    configure:8753: checking for gd.h
>    configure:8753: result: yes
>
> What do you suggest to do about AquaTerm (provided that we have
> freedom to change AquaTerm in the way that is needed to make gnuplot
> configuration work properly)? Can gnuplot configuration be fixed
> properly, so that gnuplot will find AquaTerm that is shipped with
> MacPorts? My next question would be how to set which aquaterm to use
> (in case there are multiple versions installed), but that's for later.
>
> Mojca
>

On Jul 6, 2011, at 2:20 PM, Mojca Miklavec wrote:
> I would like to revive this thread. Gnuplot needs a fix to account for
> the change in AquaTerm, that is, it needs to replace -laquaterm with
> -framework Aquaterm (possibly with those intermediate flags suggested
> by Allin C.).

I just tried building gnuplot 4.4.3 manually on a Mac that has aquaterm 1.0.1_5 installed through MacPorts. As you describe, the configure script fails to compile the little program that tests for a working aquaterm library:

configure:6004: checking for aqtInit in -laquaterm
configure:6029: gcc -o conftest -g -O2   -I/opt/local/include  conftest.c -laquaterm -lobjc  >&5
ld: library not found for -laquaterm
collect2: ld returned 1 exit status

Note that the configure script knew that it should look for header files in /opt/local/include. However, it did not add /opt/local/lib to the library path, which I believe would be sufficient to build gnuplot using the MacPorts aquaterm.

I am not sure why the configure script added /opt/local/include to the header path. It could be because prior to testing for aquaterm, it found my MacPorts installation of X:

configure:5097: checking for X
configure:5286: result: libraries /opt/local/lib, headers /opt/local/include

I do not know why the configure script would pick up the MacPorts include directory, but not the library directory. I am actually not sure if it should, since those are non-standard (at least on the OSX platform), and therefore should be given explicitly to the configure command. Could you try

  CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure

and see if this helps? Configured this way, gnuplot then builds fine on my machine, and seems to work with the aquaterm terminal.

Finally, it seems that the line

    aqua terminal (MacOS X): yes

in the configure summary is printed whenever the variable is_apple is set to yes. From the configure script:

    if test "x$ac_cv_lib_aquaterm_aqtInit" = x""yes; then :
        LIBS="-laquaterm $LIBS -framework Foundation"
        CFLAGS="$CFLAGS -ObjC"
        $as_echo "#define HAVE_LIBAQUATERM 1" >>confdefs.h
    fi
    is_apple=yes

Perhaps the last line should be inside the if clause?

Disclaimer: I know very little about autoconf, and even less about the intricacies of the Apple build system, so take all of this with a grain of salt.

Hope this helps,

  Lutz

> On Wed, Mar 9, 2011 at 16:12, Mojca Miklavec
> <mojca.miklavec.lists@...> wrote:
>> Dear list,
>> 
>> I'm helping Per Persson test a new version of AquaTerm. I'm using Snow
>> Leopard with 64-bit architecture. The old AquaTerm only ships 32-bit
>> intel and ppc architectures, however a new version will come with
>> support for x86_64 (the latest version in CVS/git supports it
>> already).
>> 
>> However there is still quite a list of issues, many of them with the
>> common denominator being: as long as one has MacPorts (with gnuplot or
>> aquaterm package) installed, the only way to get a working version of
>> self-compiled gnuplot with aquaterm terminal is to:
>> - have both manually installed AquaTerm and the one installed with MacPorts
>> - both versions need to match exactly
>> 
>> What happens?
>> --------------------
>> If I don't install AquaTerm manually, the version provided by MacPorts
>> doesn't suffice to compile gnuplot with aquaterm terminal which is
>> probably a flaw in gnuplot configuration. Priority number one would be
>> to fix that one.
>> 
>> However if I do install a different version of AquaTerm, gnuplot links to
>>    /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> which belongs to MacPorts, but it opens /Applications/AquaTerm.app
>> which links to
>>    /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> and then nothing happens at all. Nothing gets drawn.
>> 
>> I have a number of other requests, I will try to do my best to fix
>> AquaTerm (I still lack knowledge), but one thing should be high on
>> priority list: ability to build gnuplot with aquaterm terminal without
>> having to manually install AquaTerm.app.
>> 
>> What has to be done?
>> --------------------
>> AquaTerm installs four things: application, framework, symbolic links:
>> - /Applications/AquaTerm.app
>> - /Library/Frameworks/AquaTerm.framework
>> - symlinks
>>  /usr/local/include/aquaterm/AQTAdapter.h
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>>  /usr/local/include/aquaterm/aquaterm.h
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>>  /usr/local/lib/libaquaterm.dylib
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /usr/local/lib/libaquaterm.1.1.0.dylib
>>    -> /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> 
>> Under MacPorts that is:
>> - /Applications/MacPorts/AquaTerm.app
>> - /opt/local/Library/Frameworks/AquaTerm.framework
>> - symlinks
>>  /opt/local/include/aquaterm/AQTAdapter.h
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/AQTAdapter.h
>>  /opt/local/include/aquaterm/aquaterm.h
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/Headers/aquaterm.h
>>  /opt/local/lib/libaquaterm.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /opt/local/lib/libaquaterm.1.0.1.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.1.0.1.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>>  /opt/local/var/macports/software/aquaterm/1.0.1_5/opt/local/lib/libaquaterm.dylib
>>    -> /opt/local/Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm
>> 
>> When I run ./configure without having my own version of AquaTerm
>> (installed manually), I get
>>    aqua terminal (MacOS X): yes
>> but that is a lie. config.log says:
>> 
>>    configure:6792: checking for aqtInit in -laquaterm
>>    configure:6817: gcc -o conftest -g -O2   conftest.c -laquaterm -lobjc  >&5
>>    ld: library not found for -laquaterm
>>    ...
>>    configure:14123: result:   aqua terminal (MacOS X): yes
>>    ...
>>    ac_cv_lib_aquaterm_aqtInit=no
>> 
>> I think that the catch is having "-I/opt/local/include" present when
>> trying to compile some test file. The question is: how should the
>> configuration script know about that? After all one could have fink or
>> homebrew or whatever other package manager installed and include path
>> could be anyone.
>> 
>> All the other libraries (pango, cairo, pdflib, gd, freetype, ...) are
>> easily found from MacPorts. Here is what config.log has to say about
>> pdf or gd for example:
>> 
>>    configure:9085: found /opt/local/bin/pdflib-config
>>    configure:9097: result: /opt/local/bin/pdflib-config
>>    configure:9120: checking for PDF_get_majorversion in -lpdf
>>    configure:9145: gcc -o conftest -g -O2  -I/opt/local/include
>> -I/opt/local/include  -L/opt/local/lib -L/opt/local/lib
>> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib conftest.c -lpdf
>>> &5
>>    configure:9145: $? = 0
>> 
>>    configure:8659: checking for gdlib-config
>>    configure:8677: found /opt/local/bin/gdlib-config
>>    configure:8689: result: /opt/local/bin/gdlib-config
>>    configure:8711: checking for gdImageCreateTrueColor in -lgd
>>    configure:8736: gcc -o conftest -g -O2  -I/opt/local/include
>> -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
>> conftest.c -lgd   >&5
>>    configure:8736: $? = 0
>>    configure:8745: result: yes
>>    configure:8753: checking gd.h usability
>>    configure:8753: gcc -c -g -O2  -I/opt/local/include conftest.c >&5
>>    configure:8753: $? = 0
>>    configure:8753: result: yes
>>    configure:8753: checking gd.h presence
>>    configure:8753: gcc -E  -I/opt/local/include conftest.c
>>    configure:8753: $? = 0
>>    configure:8753: result: yes
>>    configure:8753: checking for gd.h
>>    configure:8753: result: yes
>> 
>> What do you suggest to do about AquaTerm (provided that we have
>> freedom to change AquaTerm in the way that is needed to make gnuplot
>> configuration work properly)? Can gnuplot configuration be fixed
>> properly, so that gnuplot will find AquaTerm that is shipped with
>> MacPorts? My next question would be how to set which aquaterm to use
>> (in case there are multiple versions installed), but that's for later.
>> 
>> Mojca
>> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

On Thu, Jul 7, 2011 at 00:44, Lutz Maibaum wrote:
> On Jul 6, 2011, at 2:20 PM, Mojca Miklavec wrote:
>> I would like to revive this thread. Gnuplot needs a fix to account for
>> the change in AquaTerm, that is, it needs to replace -laquaterm with
>> -framework Aquaterm (possibly with those intermediate flags suggested
>> by Allin C.).
>
> I just tried building gnuplot 4.4.3 manually on a Mac that has aquaterm 1.0.1_5 installed through MacPorts. As you describe, the configure script fails to compile the little program that tests for a working aquaterm library:

There are two separate problems. One is that gnuplot doesn't find
aquaterm in macport, but the second separate one is that gnuplot
doesn't find aquaterm 1.1.0 (installed directly, not via macports) at
all.

I was mostly talking about supporting 1.1.0. The issue with finding
aquaterm in macports is a different (even though related) issue. Also,
it is not very nice that configure script unconditionally reports that
it is going to build aquaterm and then doesn't do it.

> I do not know why the configure script would pick up the MacPorts include directory, but not the library directory. I am actually not sure if it should, since those are non-standard (at least on the OSX platform), and therefore should be given explicitly to the configure command. Could you try
>
>  CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>
> and see if this helps? Configured this way, gnuplot then builds fine on my machine, and seems to work with the aquaterm terminal.

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.

(This should be fixed before the next release.)

Mojca

On Jul 7, 2011, at 2:19 AM, Mojca Miklavec wrote:
> On Thu, Jul 7, 2011 at 00:44, Lutz Maibaum wrote:
>> On Jul 6, 2011, at 2:20 PM, Mojca Miklavec wrote:
>>> I would like to revive this thread. Gnuplot needs a fix to account for
>>> the change in AquaTerm, that is, it needs to replace -laquaterm with
>>> -framework Aquaterm (possibly with those intermediate flags suggested
>>> by Allin C.).
>> 
>> I just tried building gnuplot 4.4.3 manually on a Mac that has aquaterm 1.0.1_5 installed through MacPorts. As you describe, the configure script fails to compile the little program that tests for a working aquaterm library:
> 
> There are two separate problems. One is that gnuplot doesn't find
> aquaterm in macport, but the second separate one is that gnuplot
> doesn't find aquaterm 1.1.0 (installed directly, not via macports) at
> all.
> 
> I was mostly talking about supporting 1.1.0. The issue with finding
> aquaterm in macports is a different (even though related) issue. Also,
> it is not very nice that configure script unconditionally reports that
> it is going to build aquaterm and then doesn't do it.

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

This should take care of the incorrect configure summary.

>> I do not know why the configure script would pick up the MacPorts include directory, but not the library directory. I am actually not sure if it should, since those are non-standard (at least on the OSX platform), and therefore should be given explicitly to the configure command. Could you try
>> 
>>  CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib ./configure
>> 
>> and see if this helps? Configured this way, gnuplot then builds fine on my machine, and seems to work with the aquaterm terminal.
> 
> 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?

I do not know how one could modify the configure process to check for the presence of the aquaterm framework. For libraries there is a standard way to do so (the AC_CHECK_LIB macro, used in m4/apple.m4), but it's not clear to me if there is something similar for frameworks.

Hope this helps,

  Lutz

On Fri, Jul 22, 2011 at 03:59, Lutz Maibaum wrote:
>
> 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
>
> This should take care of the incorrect configure summary.

This does take care of configure summary (but I didn't even try since
it doesn't help me to include aquaterm), but it doesn't even try to
use "-framework AquaTerm", so it will fail to include AquaTerm after
all anyway.

>> 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.

> I do not know how one could modify the configure process to check for the presence of the aquaterm framework. For libraries there is a standard way to do so (the AC_CHECK_LIB macro, used in m4/apple.m4), but it's not clear to me if there is something similar for frameworks.

It would probably be easier to use cmake, but just to answer you. I
have no idea how autotools work. The configure script currently has

$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="-laquaterm $LIBS -framework Foundation"
       CFLAGS="$CFLAGS -ObjC"

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

fi

All you need to do is to replace every instance of -laquaterm with
-framework AquaTerm and check if that flag works ok. I have no idea
how to do that in auto tools.

(Off-topic: is anyone providing Qt support/fixing Qt bugs? I reported
twice the reasons why I cannot use it, but I didn't get any response.)

Mojca

This is a copy-paste from some random example that I found online:

if test "x$enable_opengl" != "xno" ; then
  if test "x$host_os_darwin" = "xyes" ; then
    AC_MSG_CHECKING([for OpenGL framework])
    wz_ac_check_opengl_save_LIBS=$LIBS
    LIBS="-framework OpenGL $LIBS"
      AC_LINK_IFELSE([main() { }],
      [GL_h=mac ; GLU_h=mac ; GL_lib=yes ; GLU_lib=yes ;
GLLIB="-framework OpenGL" ; GLULIB="" ; AC_MSG_RESULT([yes])],
      [LIBS=$wz_ac_check_opengl_save_LIBS ; AC_MSG_RESULT([no])])
  fi

If that is of any help.

Mojca

http://www.gnu-darwin.org/www001/src/ports/games/warzone2100/work/warzone2100-2.0.9/configure.ac

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 (as a temporary workaround)?

>> I do not know how one could modify the configure process to check for the presence of the aquaterm framework. For libraries there is a standard way to do so (the AC_CHECK_LIB macro, used in m4/apple.m4), but it's not clear to me if there is something similar for frameworks.
> 
> It would probably be easier to use cmake, but just to answer you. I
> have no idea how autotools work. The configure script currently has

[ SNIP ]

> All you need to do is to replace every instance of -laquaterm with
> -framework AquaTerm and check if that flag works ok.

As far as I know this part of the configure script is auto-generated from m4/apple.m4, which reads:

AC_DEFUN([GP_APPLE],
[AC_MSG_CHECKING(for Apple MacOS X)
AC_EGREP_CPP(yes,
[#if defined(__APPLE__) && defined(__MACH__)
  yes
#endif
], 
   [ AC_MSG_RESULT(yes)
     AC_CHECK_LIB(aquaterm, aqtInit, 
     [ LIBS="-laquaterm $LIBS -framework Foundation"
       CFLAGS="$CFLAGS -ObjC"
       AC_DEFINE(HAVE_LIBAQUATERM,1,
                 [Define to 1 if you're using the aquaterm library on Mac OS X])
     ],[], -lobjc)
     is_apple=yes
   ],
   AC_MSG_RESULT(no)
   is_apple=no)
])

The test for the aquaterm dynamic library is performed by AC_CHECK_LIB, and I don't think there is a similar predefined macro to test for frameworks. You posted one possible solution; another one is suggested in this thread:

http://lists.apple.com/archives/Unix-porting/2009/Jan/msg00025.html

  -- Lutz

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