On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote: > 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.
Thinking about it, get-drv-info is only extracting symbols for the installed drivers which are in the source code anyway. There is no reason we couldn't have some alternative way of doing this using cmake or some scripting which would not rely on compiling an executable. This would be more portable for cross-compiling. I think the reason it might have worked in my case (I haven't checked) is that both platforms were using elf format object code. No guarantees in general though. Andrew ------------------------------------------------------------------------------ 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
