Alan, > On Wed, 26 Jun 2013 11:32:28 +0000 > "Schwartz, Steven J" <s.schwa...@imperial.ac.uk> wrote: >> Alan, Arjen, et al.,
... snip > 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 have now progressed this a bit, based on my subsequent email which included: "In chasing your build-project on the web I stumbled on mingw-builds which generates some external binaries. Actually only two: msys+friends and Qt. So I am going to try to build plplot (and our software) using their gcc 4.7.2 build of gcc and Qt4.8.4. Their documentation is non-existent and they don't tell me revision of 4.7.2 matches which of their Qt builds, but I've taken a good guess based on the date stamps." It took considerable effort and poking-in-the-dark to get this to build plplot. The bottom line is that I succeeded, but that the qt eps and pdf drivers still generate a landscape image that spills off the right edge of a portrait page (see attached). Two qt drivers fail to generate valid image files (empty files): tiff and jpeg. The other qt drivers (bmp, png, ppm, svg) generate plots that look ok (I haven't studied them in detail), as does the qtwidget. Here are the gorey details: I used my existing msys (rather than replace it with the one from mingw_builds). That msys (but not mingw) was fetched directly from the sourceforge project using the mingw installer. My cmake is the windows binary version 2.8.11. I fetched Qt-4.8.4-x64.7z and the matching (?) mingw gcc 4.7.2 revision 8.7 from mingw-builds. Unpacked both of those. I edited my msys .profile PATH to point to the bin folders of these. Cmake failed to find Qt4 properly, even after doing a: export CMAKE_PREFIX_PATH=/c/Qt/4.8.4 It reports QT_MOC_EXECUTABLE, QT_RCC_EXECUTABLE, and QT_UIC_EXECUTABLE not found, although it also reports the Qt version as 4.8.4. I tried renaming things (indeed, the original Qt...7z unpacks into c:/QtSDK/Qt64...). Now moc.exe, rcc.exe, uic.exe, and qmake.exe (which the googling I did suggested was cmake's primary route to locate Qt) are all in my PATH variable, as well as locatable via the export line given above. To make a (very) long story short, I invoked cmake with explicit locations for moc, rcc, uic, via -DQT_MOC_EXECUTABLE=/c/Qt/4.8.4/bin/moc.exe, etc. Interestingly, cmake didn't complain about finding the Qt includes or libraries, although to be safe I also export'ed the CMAKE_INCLUDE_PATH and CMAKR_LIBRARY_PATH . That then allows the plplot qt drivers to be built. I had to turn off the python bindings, as the build failed at the make stage with an undefined reference to '__imp_Py_initModule4' which googline revealed is an incompatibility (I think) between my 64-bit Qt and a 32-bit python installation. I don't have wxwidgets, ada, stuff needed by cairo, etc., so in the end it built the standard drivers (wingcc, ps, psc, svg, xfig, null, mem) plus the qt ones. I installed I hit another problem which, it turns out, is in common with my previous gcc 4.4 build of plplot. The Makefile in examples/c/ has an empty PKG_CONFIG_ENV that prevents 'make all' or any other make to run. I'm happy to compile from a command line against the dll's, e.g., gcc x01c.c -o x01c.exe -I../../../../include/plplot -L../../../../lib -lplplotd -lm which requires the plplot installed driversd and bin to be in my PATH. Summary: 1 Mingw-builds of gcc 4.7.4 and matching Qt4.8.4 will build plplot with appropriate PATH and: $ export CMAKE_PREFIX_PATH=/c/Qt/4.8.4 $ cmake -G "MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=install_472 -DENABLE_python=OFF -DENABLE_ada=OFF -DENABLE_java=OFF -DQT_MOC_EXECUTABLE=/c/Qt/4.8.4/bin/moc.exe -DQT_RCC_EXECUTABLE=/c/Qt/4.8.4/bin/rcc.exe -DQT_UIC_EXECUTABLE=/c/Qt/4.8.4/bin/uic.exe .. 2 But it still generates improper qt eps and pdf output files. [I turned off java to speed up the make.] Comments on the above are welcome. Despite the short summary, as someone who is cmake illiterate it took me hours to get to this stage. Most of the time, if I can't get ./configure followed by make, or the equivalent, to run within 15 minutes I give up. Steve PS With my previous gcc 4.4 toolchain I didn't have to do anything to get cmake to find Qt, and I tried to get the above 4.7.2 system to work by renaming locations so that both mingw and Qt were found in the identical locations. PPS I haven't played with my other plplot bits of test code to see if these qt drivers don't generate crashes the way the gcc 4.4 version did. Watch this space ... -------------------------------------------------------------------- Professor Steven J Schwartz Phone: +44 (0)207 594 7660 Head, Space & Atmospheric Physics Fax: +44 (0)207 594 7772 The Blackett Laboratory Email: s.schwa...@imperial.ac.uk Imperial College London Office: Huxley 6M67A London SW7 2AZ, UK Web: www.sp.ph.ic.ac.uk/~sjs --------------------------------------------------------------------
qtpdf_test.pdf
Description: qtpdf_test.pdf
------------------------------------------------------------------------------ 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
