On 2008-02-04 10:20+0100 Werner Smekal wrote: > Hi Ty, > > you can get rid of the tk warnings by gettting rid of the tk driver, > which you don't need anyway by setting the cmake option - > DENABLE_tk=OFF and -DENABLE-tcl=OFF. The other warnings you get are > since there is a mixup between the png/jpeg libraries installed by > macport to /opt/local/ and the ones provided by the wxWidgets library. > I actually have similar problems and need to find a way how I tell > cmake which library/headers it should use. In the shared case this is > not a problem, since the wxWidgets library knows which dylib to use, > but if you link all together many symbols are twice in the linked > object.
Hi Werner: I follow the above argument this far. If you turn dynamic drivers off (which is a necessary side effect of the -DBUILD_SHARED_LIBS=OFF option or which you can specify independently for the shared libraries case by using the -DENABLE_DYNDRIVERS=OFF option), then instead of being used as independent plug-ins all driver code becomes part of our core library. In that all-in-one case, you have the wxwidgets driver code using the wxwidgets library and the gd driver using the gd library, i.e., our core library links to both the wxwidgets and gd libraries, but NOT directly to the jpeg or png libraries since our device drivers do not refer to jpeg or png symbols. So this is classical hierarchical linking with libplplot linking to wxwidgets which in turn links to the jpeg and png libraries and similarly with libplplot linking to libgd which in turn links to the jpeg and png libraries. If those two libraries link to two separate versions of the jpeg and png libraries, that should not be an issue for a really smart library linking and run-time linking environment, but I am not sure whether Mac OS X (or any other platform) is that smart or not. In any case, how libgd and libwxwidgets are linked is completely outside of our build system's control and something that the Mac OS X user may have to deal with independently by reinstalling one or both of those libraries. Note, another complicating factor is our FindGD.cmake module finds jpeg and png library information just in case the platform's linking and run-time environment is too dumb to even support hierarchical linking. However, the CMake modules to find the jpeg and png libraries are completely independent of each other and also of our own FindGD.cmake so it's quite possible that FindGD.cmake is finding an inconsistent set of jpeg and png libraries. To change that behaviour set the environment variable CMAKE_LIBRARY_PATH (see our wiki for more information on this variable) to the appropriate path for the png and jpeg libraries needed by libgd. Werner, does that change solve the issue? If not, then perhaps libwxwidgets and libgd as currently installed on your system are linked to different jpeg and png libraries, and you may have to reinstall one or both of them to use consistent jpeg and png libraries if the Mac OS X linker and run-time loader is not smart enough to handle that situation. 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 __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
