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
|