From: Thomas S. <th...@ws...> - 2009-03-02 18:31:08
|
Correction, it works. I just had to properly set the hard coded data directory. Actual cross compile test comming soon... |
From: Thomas S. <th...@ws...> - 2009-03-02 19:22:58
|
I have no idea why this works, but it seems to! All I changed is the data dir. This is astonishing. Surely there must be some problems that show up later. I think I'm missing support for some major stuff - were does this nearest neighbors library come into the picture? Never the less, here is an example of a cross compiling a win32 C core library only with extcairo support. I'll try some more stuff and report back. Also to anyone every trying this the windows program dependency walker is invaluable in trying to figure out all the files you need to copy over. file required to run the example, "test1.exe": created by the makefile: csirocsa.dll plplot.dll test1.exe others: libcairo-2.dll libglib-2.0-0.dll libgmodule-2.0-0.dll libgobject-2.0-0.dll libpango-1.0-0.dll libpangocairo-1.0-0.dll libpangowin32-1.0-0.dll libpng12-0.dll zlib1.dll plstnd5.fnt plxtnd5.fnt ========= Makefile.win32 ================ #set CC to your compiler #do mkdir objwin32; mkdir win32 #set pkg-config path ie: PKG_CONFIG_PATH=/opt/crosscompilers/win32/mingw/lib/pkgconfig make -f Makefile.win32 CC = /opt/crosscompilers/win32/bin/i686-mingw32-gcc -g LIBS=`pkg-config --libs cairo pangocairo` CFLAGS = -I ./include `pkg-config --cflags cairo pangocairo glib-2.0` -DHAVE_CONFIG_H HEADERS = ./include/config.h ./include/plcore.h \ ./include/pldebug.h ./include/plDevs.h \ ./include/plplot.h ./include/plplotP.h \ ./include/plstrm.h ./include/pldll.h \ ./include/pdf.h ./include/disptab.h \ ./include/drivers.h ./include/metadefs.h \ ./lib/nn/nan.h ./include/plevent.h \ ./include/mt19937ar.h ./include/plhershey-unicode.h LIBOBJS = ./objwin32/cairo.o ./objwin32/null.o ./objwin32/plargs.o \ ./objwin32/plbox.o ./objwin32/plbuf.o ./objwin32/plcont.o \ ./objwin32/plcore.o ./objwin32/plctrl.o ./objwin32/plcvt.o \ ./objwin32/pldtik.o ./objwin32/plfill.o ./objwin32/plgridd.o \ ./objwin32/plhist.o ./objwin32/plimage.o ./objwin32/plline.o \ ./objwin32/plmap.o ./objwin32/plot3d.o ./objwin32/plpage.o \ ./objwin32/plsdef.o ./objwin32/plshade.o ./objwin32/plstdio.o \ ./objwin32/plstripc.o ./objwin32/plsym.o ./objwin32/pltick.o \ ./objwin32/plvect.o ./objwin32/plvpor.o ./objwin32/plwind.o \ ./objwin32/pdfutils.o ./objwin32/mt19937ar.o all: ./win32/plplot.dll ./win32/csirocsa.dll ./win32/test1.exe ./objwin32/csa.o : ./lib/csa/csa.c ./lib/csa/csa.h ./lib/csa/nan.h ./lib/csa/version.h $(CC) -fpic $(CFLAGS) -c ./lib/csa/csa.c -o ./objwin32/csa.o ./win32/csirocsa.dll : ./objwin32/csa.o $(CC) -shared -o ./win32/csirocsa.dll -Wl,--out-implib,./win32/csirocsa.dll.a ./win32/plplot.dll : $(LIBOBJS) ./win32/csirocsa.dll $(CC) -shared -o ./win32/plplot.dll $(LIBOBJS) -Wl,--out-implib,./win32/plplot.dll.a \ $(LIBS) ./win32/csirocsa.dll ./objwin32/mt19937ar.o : ./src/mt19937ar.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/mt19937ar.c -o ./objwin32/mt19937ar.o ./objwin32/cairo.o : ./drivers/cairo.c $(HEADERS) $(CC) $(CFLAGS) -c ./drivers/cairo.c -o ./objwin32/cairo.o ./objwin32/null.o : ./drivers/null.c $(HEADERS) $(CC) $(CFLAGS) -c ./drivers/null.c -o ./objwin32/null.o ./objwin32/plargs.o : ./src/plargs.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plargs.c -o ./objwin32/plargs.o ./objwin32/plbox.o : ./src/plbox.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plbox.c -o ./objwin32/plbox.o ./objwin32/plbuf.o : ./src/plbuf.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plbuf.c -o ./objwin32/plbuf.o ./objwin32/plcont.o : ./src/plcont.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plcont.c -o ./objwin32/plcont.o ./objwin32/plcore.o : ./src/plcore.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plcore.c -o ./objwin32/plcore.o ./objwin32/plctrl.o : ./src/plctrl.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plctrl.c -o ./objwin32/plctrl.o ./objwin32/plcvt.o : ./src/plcvt.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plcvt.c -o ./objwin32/plcvt.o ./objwin32/pldtik.o : ./src/pldtik.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/pldtik.c -o ./objwin32/pldtik.o ./objwin32/plfill.o : ./src/plfill.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plfill.c -o ./objwin32/plfill.o ./objwin32/plgridd.o : ./src/plgridd.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plgridd.c -o ./objwin32/plgridd.o ./objwin32/plhist.o : ./src/plhist.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plhist.c -o ./objwin32/plhist.o ./objwin32/plimage.o : ./src/plimage.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plimage.c -o ./objwin32/plimage.o ./objwin32/plline.o : ./src/plline.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plline.c -o ./objwin32/plline.o ./objwin32/plmap.o : ./src/plmap.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plmap.c -o ./objwin32/plmap.o ./objwin32/plot3d.o : ./src/plot3d.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plot3d.c -o ./objwin32/plot3d.o ./objwin32/plpage.o : ./src/plpage.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plpage.c -o ./objwin32/plpage.o ./objwin32/plsdef.o : ./src/plsdef.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plsdef.c -o ./objwin32/plsdef.o ./objwin32/plshade.o : ./src/plshade.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plshade.c -o ./objwin32/plshade.o ./objwin32/plstdio.o : ./src/plstdio.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plstdio.c -o ./objwin32/plstdio.o ./objwin32/plstripc.o : ./src/plstripc.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plstripc.c -o ./objwin32/plstripc.o ./objwin32/pltick.o : ./src/pltick.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/pltick.c -o ./objwin32/pltick.o ./objwin32/plvect.o : ./src/plvect.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plvect.c -o ./objwin32/plvect.o ./objwin32/plvpor.o : ./src/plvpor.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plvpor.c -o ./objwin32/plvpor.o ./objwin32/plwind.o : ./src/plwind.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plwind.c -o ./objwin32/plwind.o ./objwin32/plsym.o : ./src/plsym.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/plsym.c -o ./objwin32/plsym.o ./objwin32/pdfutils.o : ./src/pdfutils.c $(HEADERS) $(CC) $(CFLAGS) -c ./src/pdfutils.c -o ./objwin32/pdfutils.o ./win32/test1.exe : ./win32/plplot.dll $(CC) -I ./include `pkg-config --cflags cairo` test1.c ./win32/plplot.dll.a \ ./win32/csirocsa.dll.a `pkg-config --libs cairo` -o ./win32/test1.exe clean: rm -f ./objwin32/* rm -f ./win32/* Thomas Stover wrote: > Correction, it works. I just had to properly set the hard coded data > directory. Actual cross compile test comming soon... > |
From: Werner S. <sm...@ia...> - 2009-03-02 19:27:48
|
Hi Alan and Thomas, > > Once you get that first simple cross-build working properly, then I think > the next step is to figure out what to do with dynamic devices. That > does > work on MinGW so it should be straightforward to get it to work for a > Linux > cross-build for MinGW, but I am not familiar with the MinGW dynamic > device > details so someone else will have to help you there. This should work "out of the box" since on Windows there is no library provided at all by MinGW or Visual C++. I wrote replacement functions for the used libltdl (?) functions which are compiled and linked in if cmake has WIN32 set. So this should be no problem, but if dynamic drivers are enabled, get-drv-info.exe is run for every device during the compilation to create some files - this would already need Wine I think. I'm not sure if this "just works". Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Thomas S. <th...@ws...> - 2009-03-02 20:53:48
|
Is there an "official" precompiled release for win32 and/or win64? If that were the case I would just use that, and bring it into my cross environment. On the other hand, if the standard installation is for one is to build their own for maximum tool chain & platform compatibility, then cross compilation is more of valid concept. In my case plplot itself is one of many dependences. As with builds for embedded targets for instance, when creating home built dependencies is required or desired, configuring them for the minimal feature set needed is common. So from that perspective, a custom stripped down build of plplot without dynamic drivers that would likely only be deployed as a dependency of another project is not really a problem. Especially if that allows for larger goals to be achieved - in my case a linux hosted, multi targeted continuous integration environment. The cmake build system of course is still used for a native linux build. However I also target things like embedded arm linux environments with cross compilers, and so I might handle them the same way (I have to deal with things like problems from mixing object code from different gcc versions). With luck I'll get cmake cross builds working as well. In the mean time if someone wants, I can make a wiki page or something explaining how to do it this way. Hopefully I can at least get a "feature complete" version in action, even if it lacks all the drivers and bindings. Again I'm so thankful for plplot existing, and I look forward to contributing in some way. Werner Smekal wrote: > Hi Alan and Thomas, >> >> Once you get that first simple cross-build working properly, then I >> think >> the next step is to figure out what to do with dynamic devices. That >> does >> work on MinGW so it should be straightforward to get it to work for a >> Linux >> cross-build for MinGW, but I am not familiar with the MinGW dynamic >> device >> details so someone else will have to help you there. > This should work "out of the box" since on Windows there is no library > provided at all by MinGW or Visual C++. I wrote replacement functions > for the used libltdl (?) functions which are compiled and linked in if > cmake has WIN32 set. So this should be no problem, but if dynamic > drivers are enabled, get-drv-info.exe is run for every device during > the compilation to create some files - this would already need Wine I > think. I'm not sure if this "just works". > > Regards, > Werner > |
From: Alan W. I. <ir...@be...> - 2009-03-02 21:58:04
|
On 2009-03-02 14:57-0600 Thomas Stover wrote: > Is there an "official" precompiled release for win32 and/or win64? That has been discussed since it is fairly straightforward to do that with CMake, but it hasn't actually happened yet. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2009-03-03 06:52:26
|
Hi, On 02.03.2009, at 22:57, Alan W. Irwin wrote: > On 2009-03-02 14:57-0600 Thomas Stover wrote: > >> Is there an "official" precompiled release for win32 and/or win64? > > That has been discussed since it is fairly straightforward to do that > with CMake, but it hasn't actually happened yet. I'm actually working on that and have already written a script to automatically obtain and build some dependencies and then the PLplot library, but didn't manage to test and upload the binaries somewhere, but it is on my ToDo list. 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 > __________________________ > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-03-03 23:44:50
|
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 __________________________ |
From: Andrew R. <and...@us...> - 2009-03-04 09:37:19
|
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. I agree this needs more work. Generating the qsastime header and the hershey font tables should be fine using the native version of the executable. get-drv-info is more tricky. > 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. In principle I'm edgy about the ssh route. This would not be available for windows which is likely to be one major cross-compilation requirement. An alternative for windows cross-compiles might be wine. This is looking potentially messy though. The reason I made the LOCATION method changes is that this was the recommendation on the cmake wiki. It implied that under cmake 2.6 the command name in add_custom_command was interpreted as a target name and so all the dependencies and platform-specific suffixes were handled automatically so LOCATION was not needed. Of course this needs checking. > > 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. If it proves a problem we can probably work around it, but I was unclear how to get the LOCATION method to work in a cross-compiling environment. It certainly didn't work by default - I tried. >> >> 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). I assumed something like this was the case, but not having any other libraries to test it with I went with the brute force approach of disabling it. Perhaps someone could update the wiki with instructions for this? Andrew |
From: Thomas S. <th...@ws...> - 2009-03-03 23:55:35
|
>> >> 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). I have read that in places to, and have yet fully understand the distinction between the two. We use PKG_CONFIG_PATH for cross builds all the time and get results. For one thing, how would pkg-config 'know' what is native and non-native? I wouldn't want a cross build to ever link to a native lib anyway. In a build system that needed both/many separate pkg-config environments would need to be specified as such anyway. In the case of plplot this is done with the separate steps for the native and cross build. In some things I've put together, more than one can be explicitly specified for different purposes in one step. |
From: Alan W. I. <ir...@be...> - 2009-03-04 01:18:51
|
On 2009-03-03 17:59-0600 Thomas Stover wrote: > >>> >>> 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). > > I have read that in places to, and have yet fully understand the distinction > between the two. We use PKG_CONFIG_PATH for cross builds all the time and get > results. For one thing, how would pkg-config 'know' what is native and > non-native? pkg-config knows exactly what PATHS to check by what you specify to PKG_CONFIG_LIBDIR. If a non-native package does not exist, the PKG_CONFIG_LIBDIR method will do that right thing which is to report it does not exist while for this case the PKG_CONFIG_PATH method will fall back to the native path (check the man page for pkg-config) which obviously is the wrong thing to do for cross-builds. This is why the PKG_CONFIG_PATH method is deprecated for cross-build environments. > I wouldn't want a cross build to ever link to a native lib > anyway. Exactly, which is why you should always use PKG_CONFIG_LIBDIR for cross builds. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2009-03-04 00:07:19
|
Thomas Stover wrote: > > -Also extcairo wont work by itself. At least one other cairo based > driver needs to be turned on for a successful build. Not just with cross > compiles, but in general. > That was a problem with the cairo.cmake file, extcairo should build by itself now (as of v9671). Thanks for pointing out the problem. best, -Hazen |
From: Werner S. <sm...@ia...> - 2009-03-04 07:13:33
|
Hi Thomas, > > -I'm guessing that I need to try this with the SVN tree. I'm on rev > 9667. > > -I think sometimes CMake does some config caching or something that > gets in the way big time, and I can't figure out how to clear or > disable it. What are you suppose to do? I've been just starting over > again with a fresh checkout. Using CMake you're supposed to configure and compile the project in a separate build directory, e.g. mkdir build cd build cmake path_to_plplot Usually there should be no problems recompiling in the same tree, even after you changed cmake files (it will reconfigure automatically). Still, if you have the feeling something is wrong, just remove the build directory and start new. No need to checkout. Don't configure and compile in the source tree, this will lead to problems for sure. > > -Building example1 gives these warnings: > x01c.c: In function ‘main’: > x01c.c:124: warning: passing argument 3 of ‘plMergeOpts’ from > incompatible pointer type > x01c.c:125: warning: passing argument 2 of ‘c_plparseopts’ from > incompatible pointer type Hmm, plMergeOpts and plparseopts are on line 117/118 for my x01c.c (latest svn). Which x01c.c are you using? The types are const char *array[] <-> const char **array array[][] is not the same as **array, but actually the above should be okay (and all compilers so far had no problem). Which gcc version is that? > > -Anyway, example1 runs on my windows machine with this errorish > condition: > *** PLPLOT ERROR, ABORTING OPERATION *** > plInitDispatchTable: Could not open drivers directory, aborting > operation > PLplot library version: 5.9.2 > got here -- 0 You are using the dynamic drivers and it is unable to open the directory where the driver information is. Look at the function plGetDrvDir(). As long as you are not in the build tree (determined by plInBuildTree()) you should be able to set the environment variable PLPLOT_DRV_DIR to let PLplot find the *.rc files (for every dynamic driver there is a .rc file). HTH, Werner > > Plotting Options: > > Enter device number or keyword: > > -I suppose I wasn't getting this condition with the build I did with > the makefile, because I wasn't using dynamic loading. Maybe I need > to copy more files over? To a specific place? > > -What most people who want to target win32 and win64 from mingw > cross compilers do that want to use gtk (and thus cairo) is download > the official "all in one" bundles from the gtk site, and unpack to > their cross environment. After that they edit the .pc (package > config files) to reflect the real full paths of these files on the > host system. Then set the PKG_CONFIG_PATH environment variable to > the collection of .pc files you need at build time. > > -So I went ahead and tried to get a cairo driver to work by > exporting PKG_CONFIG_PATH first. That (eventually) did build just > fine, but again the same runtime error over on windows. > > -I see you guys have a separate build system to maintain for dos, > maybe a cross compile with cmake would be more maintainable. One > issue is the only guides I can find on building a cross dos tool > chain are pretty old. I haven't had time to try to make one yet due > to nostalgia being my only motivation on that one. > > -Also extcairo wont work by itself. At least one other cairo based > driver needs to be turned on for a successful build. Not just with > cross compiles, but in general. -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2009-03-04 10:59:01
|
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 |