Menu
▾
▴
Re: building with AquaTerm
|
From: Mojca M. <moj...@gm...> - 2011-07-06 21:20:22
|
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 <moj...@gm...> 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 > |
