Hi Alan > > 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. I think that's case. Mabye gcc is smart enough, since it issues only lots of warnings, but I wouldn't have a good feeling, that this will work :) > > 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. I hope all FindXXX.cmake scripts always look in CMAKE_LIBRARY_PATH first, before trying the standard paths, or? Than I would just need to set them to /opt/local/lib which is were all macports libraries are. I would also need to set CMAKE_INCLUDE_PATH to /opt/local/include, so that the correct headers are used as well. I can test that on Thursday, until then I have no access to a Mac OS X machine. > > 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. In any case I think if you mix the macports gd library with the wxwidgets library provided by apple, that this won't work (for the static case). Either one must compile wxwidgets on its own, using the macports libraries (wxWidgets uses them if it can find png and jpeg libraries, or turn png/jpeg support off) or use the macports wxwidgets library.
Thanks for the reminder about CMAKE_LIBRARY_PATH. Regards, Werner > > 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
