I'm slowly getting back to some plplot development. Since my last involvement with plplot, I have received a new computer with Mac OS X 10.6.5 (aka Snow Leopard) and a 64 bit processor (Intel Core i5). I noticed a few issues when building plplot on this new system. I'm documenting them all here for posterity, though I have a few questions mixed in. Apologies in advance for the lengthiness.
= freetype I think freetype is only for older plplot devices like the gd driver, but I'm not sure. Please correct me if I'm wrong, but as I recall, freetype is not used by the xwin driver, which I think is Hershey fonts only. In any event, I installed freetype using MacPorts so it lives under /opt/local rather than /usr/local so the FindFreetype.cmake module didn't find it. If this ends up being an issue, it is easy to solve through cmake command line options or adding suitable paths to FindFreetype.cmake. = wxwidgets Snow Leopard includes wxwidgets 2.8, which links to Apple's 32-bit-only Carbon framework rather than the 64-bit-capable Cocoa framework. Therefore anything, such as plplot, that links to the wxwidgets libraries on Snow Leopard must also be 32 bit. So apparently one must choose between 64-bit plplot without wxwidgets or 32-bit plplot with wxwidgets. wxwidgets 2.9 on Mac OS X links to the Cocoa framework so that would work with 64-bit plplot (assuming that plplot is compatible with wxwidgets 2.9). I found this out fairly late in the build when the link failed. I think the cmake tests could be updated to detect the architecture difference and disable the wxwidgets stuff if it is found to be incompatible. I chose to build plplot using the i386 architecture rather than the x86_64 architecture by running... cmake -DCMAKE_OSX_ARCHITECTURES:STRING=i386 .. This enabled the "-arch i386" compiler flag, which means that I have to use one of Apple's gcc versions since the gcc versions I installed via MacPorts seem to croak on this option. This has the side effect of eliminating Fortran since (AFAIK) Apple doesn't provide a Fortran compiler. Maybe I could use Apple's gcc and MacPorts gfortran, but I don't really need Fortran support, so I've not investigated that hybrid configuration. = qhull In the output of the above cmake command, I noticed that HAVE_QHULL is now OFF. This is because I had installed it via MacPorts as a "non-universal" binary so it had only x86_64 support in it. I reinstalled it as a universal binary. = octave I installed Octave 3.2.4 via MacPorts. The MacPorts octave "portfile" does not build or provide a way to build a universal binary, so my octave in x86_64 only so I can't use it and wxwidgets. = pthread Does anyone know if the comments in cmake/modules/xwin.cmake about pthread on Mac OS X 10.4 and 10.5 are still relevant for 10.6? I'd be happy to try this out if someone can let me know what to look for in terms of working vs not working. = agg HAVE_AGG is blank (i.e. neither ON nor OFF) even though I have it installed. It seems like this is only used by wxwidgets with freetype, but since I don't have freetype enabled (see above) it makes sense that this would be blank. It does get me wondering more about the wxwindows and freetype stuff. What is the status of the wxwidgets driver and bindings? They defaulted to ON which leads on to think they are not deprecated. If I eliminate the wxwidgets stuff I think I would be able to switch back to an x86_64 build, but I kind of like the concept of plplot inside a wxwidgets application. = cairo I also discovered that I needed to re-install cairo as a universal binary. Again, this happened part way through the build. Does cmake not try to link against libraries that it finds or does it not use the same flags (e.g. -arch i386) used to build plplot? It seems like cmake should have been able to tell me that my x86_64 cairo installation was not usable with the CMAKE_OSX_ARCHITECTURE setting I used, but I only found out part way through the build. = aquaterm I was unable to build the aquaterm driver. The output of cmake included "-- Found AQT: /opt/local/include/AquaTerm/AQTAdapter.h", but when I run "make VERBOSE=1" I get... cd /Users/davidm/local/src/plplot/tmp/drivers && /opt/local/bin/gcc -Daqt_EXPORTS -DHAVE_CONFIG_H -arch i386 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fPIC -I/Users/davidm/local/src/plplot/include -I/Users/davidm/local/src/plplot/lib/qsastime -I/Users/davidm/local/src/plplot/lib/nistcd -I/Users/davidm/local/src/plplot/tmp -I/Users/davidm/local/src/plplot/tmp/include -ObjC -DUSINGDLL -o CMakeFiles/aqt.dir/aqt.c.o -c /Users/davidm/local/src/plplot/drivers/aqt.c /Users/davidm/local/src/plplot/drivers/aqt.c:33:32: error: AquaTerm/AQTAdapter.h: No such file or directory Why is there no "-I/opt/local/include" on the gcc command line given that cmake found the required header file "/opt/local/include/AquaTerm/AQTAdapter.h"? FWIW, the directory is really named "/opt/local/include/aquaterm", but the filesystem here is case-insensitive (the Mac default and recommended). Thanks, Dave ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
