On 2011-01-04 22:03-0800 David MacMahon wrote: > Hi, Alan and Arjen, > > Thanks for your detailed replies. I think the basic answer is that the tkwin > driver (and corresponding cmake modules?) are not compatible with Snow > Leopard's Tk. Here's why I say that... > > It turns out that cmake was finding the right X11, Tcl, and Tk include paths. > The reason why XOpenDisplay was not declared (leading to the "warming: > converting int to pointer without a cast") is that the > /usr/include/X11/XLib.h file was not being used because the Tk include > directory "/System/Library/Frameworks/Tk.framework/Headers" contains its own > "X11/Xlib.h" file which was found first and does not declare XOpenDisplay. > The fact that Apple's Tk doesn't declare XOpenDisplay in its X11/Xlib.h makes > sense since Tk on Mac is not based on X11, but the fact that it provides its > own X11/Xlib.h file in the first place was a surprise to me. Go figure. > > I then tried adding -DMAC_TCL to the command line as Arjen suggested. That > failed with a missing header <tkInt.h>. I found it in <tk-private/tkInt.h>, > so I changed the #include in tckin.c. It got a little farther but then it > complained about a missing tkUnixPort.h file, which I don't have anywhere on > my system. > > At that point I concluded that I can live without the tkwin driver. If that > changes, I'll be happy to look into this situation further, but for now I > have more pressing (at least to me) plplot-related things to work on.
I think that is a good decision. You gave it a good try, but the tkwin "driver" is an exotic beast that doesn't buy you much functionality so it is not worth any more effort. As a general rule for systems like Mac OS X with a lot of different inconsistent choices for header directories and libraries, my understanding (I have little practical experience with this myself because I use a generally consistent Linux system) is if you are really having trouble getting PLplot to find a consistent set of header files or libraries for some package, then it is well worth your while to look at your CMakeCache.txt file (which contains all the CMake cached variables that will be used the next time cmake is fired up) to look for location inconsistencies. Then override those inconsistent cached variables with the corresponding -D cmake options to set those cached variables in a consistent way. Such options always override cached find results and fresh find attempts will just not occur if the equivalent cache variable is set via CMakeCache.txt or an overriding -D option. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
