Hi Steve: Thanks for your contributions to this thread. More below in context.
On Wed, 26 Jun 2013 11:32:28 +0000 "Schwartz, Steven J" <s.schwa...@imperial.ac.uk> wrote: > Alan, Arjen, et al., > > I have been following this thread, and the parallel ones re Cygwin build and > also build_project, with some interest. We ship a binary Windows version of > our QSAS software (which includes the Qt libraries and a somewhat > stripped-down version of plplot which only drives our own version of the > qt-widgets device). This seems to work fine. As I have succumbed to the > corporate Windows pressure I no longer use linux so have spent more time > exploring aspects of Windows builds. I'm a novice in Cygwin, mingw, and msys. > > QSAS builds under msys. We/I don't build Qt from source (but if Alan has a > foolproof way to do that I'd consider having a go). So I use the last Qt4 > binary system provided by Qt, namely 4.8.4. This was built against mingw 4.4, > and there are various discussion-group posts suggesting that compiling > against this binary Qt requires using the same version of mingw. That is my understanding as well. But MinGW-4.4 is really old with lots of known issues. This is the motivation behind my wanting to provide the means of building Qt4 directly from source using the MinGW version chosen by the user (4.7.2 in my case). > Luckily (?) > someone out there made a zipped file with mingw 4.4.0 available for precisely > that reason. This I access via the msys layer (which is needed for some or > other reason, rather than just building directly in mingw. I have noticed > that other modules we use didn't interface correctly when built directly from > mingw for probably subtle reasons, so I have stuck to always working in an > msys window/environment). We don't use cmake (and have ceased using configure > - preferring a relatively simple and transparent build shell-script. The > script builds the necessary bits of plplot alongside other 3rd party modules > and the rest of QSAS). > > I have tried to build a more complete plplot against this configuration, > namely: > > Windows 7 > Qt 4.8.4 binary > Mingw 4.4.0 > Msys (current version) > Cmake 2.8.11 (windows) > > The build almost completes normally, but test-drv-info crashes dealing with > the qt drivers. The windows crash report shows that the error occurred in > libgcc_s_dw2-1.dll. This issue on Windows platforms is well known, and it might be worth your while to search the archive of this mailing list for discussions of it. What is going on is that test-drv-info attempts to do _exactly_ what the PLplot library does in dynamically loading the device drivers and testing the results of that dynamic load, but for some reason test-drv-info succeeds but with a non-zero return code that indicates some sort of internal failure while the equivalent code in the PLplot library succeeds but with a zero return code (for an application linked to that library) indicating complete success. It's a very strange issue which we have just not been able to figure out. There is only a workaround for it now which is to specify -DTEST_DYNDRIVERS=OFF, but if the QSAS team could figure this out it would be nice to drop that workaround. After all, it does make sense to run a simple test of dynamic loading of our devices to make sure the linking has been done properly before attempting to use PLplot It is also somewhat ironic that the test fails (on some devices depending on subtle linking issues which appear to be intermittent) on Windows while the actual use always succeeds. > Nonetheless everything appears to have been built and > installs ok. The native plplot drivers (wingcc, ps,psc, svg) run fine. The Qt > ones enjoy mixed success. Sometimes they crash in the same way, other times > they run fine (small changes to the source files - looks like some memory > issues). My experience is MinGW-4.7.x is more reliable than previous versions so I attribute the qt device driver run-time crashes you are encountering to your (forced) use of MinGW-4.4. > The qt ps and pdf files always generate a portrait page with the > plot spilling off the right hand edge of the page. On Linux I have just run examples/c/x01c -dev epsqt -o test.eps and examples/c/x01c -dev pdfqt -o test.pdf In both cases, the results are in landscape mode (according to the gv viewer) and look fine. The results on Windows that you report are obviously not as good so if/when I get Qt4 and PLplot built with MinGW-4.7.2, I will do a detailed comparison of qt results on Wine with the equivalents on Linux to see whether I encounter a similar issues to what you have found. > I've not tried to > install the extra bits to try to build other drivers such as wxWidgets, > cairo, etc., and do not need them. To be honest, the bare wingcc and psc > drivers are adequate for my testing needs, with my main work done via QSAS. > [There is a separate notion here about what a "minimal binary plplot" > distribution might contain, which risks everyone chipping in their one > additional driver and binding until you get back to the full distribution > :-)] Exactly. :-) A build script that has options to build a light version of PLplot or the complete version makes sense from the build-time perspective, but for binary distribution I think only the complete version makes sense because of the widely varying needs of users. In response to other things you have said, it is certainly encouraging for us that the QSAS team distributes binary versions of their software (including your own special form of PLplot build) without any showstopper issues. I anticipate no technical showstoppers via the CMake-based approach so the only potential showstopper I can see for our own binary distribution of PLplot is security concerns. How do you deal with the security implications of distributing binaries? 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 __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
