Hi "DrO": I am switching this conversation from support request ticket 38 to the plplot-general list since that is our favoured method of answering support requests, and it appears there are a number of issues we still need to discuss.
On 2016-04-03 16:07-0000 DrO wrote: > Cheers for that. > > 1) Yes, I suppose the ticket [38] can be closed, but with slight reluctance. > > As noted earlier, in a "perfect world" the solution would be a fix or > something in the PLPlot makefiles that allows the MSys side to find the > extra driver bits. If you send me some clues as to where/how the PLPlot > make etc bits look for the extra driver bits, perhaps I can have a go at > that. > > It is almost surely some "simple" path/env thing, but I am not sufficiently > good at bash/make/config to determine the specifics on my own. In any case, > one needs to get to the point where MSys/cmake produces: > > ENABLE_DYNDRIVERS: ON > DRIVERS_LIST: cairo;mem;null;ps;svg;wingcc;xfig > DEVICES_LIST: > memcairo;extcairo;pdfcairo;pngcairo;pscairo;epscairo;svgcairo;wincairo;mem;n > ull;ps;svg;wingcc;xfig > > instead of > > ENABLE_DYNDRIVERS: ON > DRIVERS_LIST: mem;null;ps;svg;xfig > DEVICES_LIST: mem;null;ps;svg;xfig OK. It sounds like you still have issues that needs to be addressed so I will keep the support request ticket 38 open for now although all further conversation should please occur on the plplot-general mailing list. One issue is wingcc is missing. That is quite unusual (since wingcc only depends on fundamental Windows libraries that should easily be found by cmake). When you reply to this message on the plplot-general mailing list please include as a separate attachment the compressed captured output from the cmake command for an initially empty build tree. Under bash I would created that compressed file as follows: mkdir build_tree cd build_tree cmake -DCMAKE_INSTALL_PREFIX=whatever wherever_top_of_plplot_source_tree >& cmake.out gzip cmake.out The resulting cmake.out.gz should include most of what I need to know to discover why the fundamental Windows libraries used by wingcc are not being found. A completely separate issue is the missing cairo device driver. However, that is due to the fundamental issue with the "vanilla" MinGW/MSYS platform I alluded to earlier, namely, unlike MinGW-w64/MSYS2 the MinGW/MSYS platform is completely missing many fundamental open-source libraries that give PLplot its power. In this case, the pango and cairo libraries and all their many library dependencies that are required by the cairo device driver are missing, but the cmake.out.gz file you will be sending me will also have zillions of WARNING messages about many other open source libraries that are not found on MinGW/MSYS which is why the result is missing so much PLplot functionality (the cairo device driver and much more, but this does not explain the wingcc issue noted above since that device driver only depends on fundamental Windows system libraries). One "solution" for the cairo device driver issue is to download the GTK+ set of libraries for Windows (which includes the required pango and cairo libraries and their dependencies). That method sometimes works, but you inevitably run into ABI trouble with that method whenever the MinGW compiler that you are using has a different ABI than the compiler used to build the binary version of GTK+ that you have downloaded. > The MinGW installation here is not the bog standard classical MinGW, it is > one that follows the much more useful structure based on the excellent work > found on this site (http://ingar.satgnu.net/devenv/mingw32/base.html), which > I refer to as the "Ingar MinGW". I have not heard of this variation of MinGW/MSYS before, but it uses the same MinGW-w64 runtime as MinGW-w64/MSYS2 and following links at that site I also found <http://ingar.satgnu.net/devenv/mingw32/base.html#install_opt> which shows that the "Ingar MinGW" platform provides GTK+ that is compiled with the same "Ingar MinGW" compiler and therefore immune to the ABI troubles I mentioned above for vanilla MinGW/MSYS. So it appears the "Ingar MinGW" platform is just like MinGW-w64/MSYS2 in this regard, but the latter platform provides many additional open-source libraries that give PLplot its power. So if you let me know the location of the dll's of all those "Ingar MinGW" GTK+ libraries, then I should be able to help you to figure out how to give the PLplot build system a hint concerning finding them. For example, one issue with PLplot and many other open-source software packages is you should not have spaces in the source tree, build tree, or install tree paths. So if you have installed your "Ingar MinGW" platform with a path prefix that includes a space, that would cause all sorts of find trouble. Note, however, that once you have addressed both the wingcc and cairo device driver issues, you still have an extraordinarly weak version of PLplot. Which is why I keep mentioning the MinGW-w64/MSYS2 platform which (when it works) gives you a powerful version of PLplot with almost complete functionality. With regard to the MinGW-w64/MSYS2 platform I acknowledge all the terrible troubles with older versions of it that you have reported to me previously in this conversation, and I can see why as a result you are so reluctant to use it. So for now, let's concentrate on getting you up and running with the weak version of PLplot that is possible on "Ingar MinGW". However, with regard to the present reliability of MinGW-w64/MSYS2, Greg Jung, has recently reported complete success with PLplot on that platform. And one of our core developers, Arjen, has had initial success with a limited test on that platform last week. But due to unfamiliarity with that platform, he violated the complex update rules relevant at the time when attempting to install more MinGW-w64/MSYS2 packages, and got stuck because of that. He soon plans to reinstall MinGW-w64/MSYS2 and follow the much simplified update rules that are available now with this latest version (see <https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>). So in sum we are still quite inexperienced with this platform, and we will keep in mind the bad results you have had for earlier versions of this platform, but we soon might be in position to say both a PLplot user and core PLplot developer have had complete success with a powerful version of PLplot on the MinGW-w64/MSYS2 platform by religiously following the installation and upgrade rules for that platform detailed in <https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/>. Note in particular the advice there which is "MUST use folder names that consist of only ascii characters and no spaces" which jibes with my similar advice above concerning PLplot itself. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
