On 2009-03-03 12:49-0000 Andrew Ross wrote: > On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote: >> [...]In sum, my advice [to Thomas was] to stick with CMake (since we should >> be able to give >> you some help in that case, and CMake skill with a normal build environment >> and also a cross-build environment is worth developing in its own right), >> and take it one step at a time. Do the simplest cross-build first with no >> dependencies. Once that works, start adding dependencies to your cross-build >> in small steps until you achieve the cross-build that you desire. > > Thomas, > > I've now done the necessary changes to plplot to allow a cmake > cross-compilation of at least the basic library. See the plplot wiki > http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page > for instructions. I have cross-compiled for mingw32 under linux. Note that I > have not tested the resulting binaries, but the compilation progresses > cleanly. It would be good if you (and others) could try this approach. The > only change required was to pick up build-time executables from a native > build rather than the cross-compiled build. PLplot uses these in several > places to generate data / source code for the build.
Andrew, I really appreciate you working out the initial cross-build issues. That proof of concept for the simple case encourages me to think that CMake is up to the full cross-build job for all aspects of PLplot where the appropriate non-native libraries are available. I have thought of some issues for the get-drv-info case. How does a Linux-built get-drv-info executable work at all for a shared object (cross-)built for Windows with MinGW? (Apparently it worked for you, but I don't understand why.) Also, looking forward to the more complicated case where the driver has dependencies, how does a native built get-drv-info using the native libraries libltdl and libdl check the linking of the non-native device driver plug-ins against non-native libraries? Unless I missed something, that is going to be a showstopper for that method. In case I am right, one way out of the mess is to build get-drv-info on the non-native platform and also run it (say via ssh) on the non-native platform with the non-native libraries. If you think that is a good alternative, then we could revert all your build-time executable changes (in particular restoring the LOCATION method, see further comment below), and run the cross-built build executables in the non-native environment instead. However, if it turns out that you really do need build-time executables built natively, then I understand why you have to refer to the executable by some alternative means for the cross-build case, but I would like to see the LOCATION method restored for ordinary non-cross build case. That is essential for Windows (where you have an executable suffix to keep track of and I think there were other issues as well), and the LOCATION method just makes life easier all around for dealing with dependencies, for example. > > The current stumbling block for the cairo drivers is that they use > pkg-config to get the correct paths and libraries to link in. This won't > work on a cross-compiled environment unless you provide suitable pkg-config > files from a cross-compiled version of cairo. This should be possible > though. Yes. This may already be covered in the CMake cross-build wiki, but instead of setting PKG_CONFIG_PATH (which always sets the native pkg-config default path in addition to the non-native one you set), you should set PKG_CONFIG_LIBDIR (which sets only the non-native path that you specify and which excludes the native pkg-config path). 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 __________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
