From: Richard J. <rrj...@gm...> - 2011-05-26 16:23:31
|
I have a Plplot-5.9.7/Qt application running well under Fedora 14 and I am now trying to port it to Windows using MinGW. Following the instructions at http://www.miscdebris.net/plplot_wiki/index.php?title=Configure_PLplot_for_M inGW/CLI .... I downloaded and installed Qt_SDK_Windows_online_v1_1_en.exe from http://qt.nokia.com/downloads/sdk-windows-cpp and checked I can build Qt applications without Plplot OK. I downloaded and installed cmake from http://www.cmake.org/cmake/resources/software.html. I added C:\QtSDK\Desktop\Qt\4.7.3\mingw\bin\ and C:QtSDK\mingw\bin to my PATH variable. In the build directory I ran cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install .. It runs through OK until it gets to Scanning dependencies of target test-drv-info [ 83%] Building C object drivers/CMakeFiles/test-drv-info.dir/test-drv-info.c.obj Linking C executable ..\dll\test-drv-info.exe [ 83%] Built target test-drv-info Scanning dependencies of target xfig [ 85%] Building C object drivers/CMakeFiles/xfig.dir/xfig.c.obj Linking C shared module ..\dll\xfig.dll [ 85%] Built target xfig Scanning dependencies of target test_xfig_dyndriver [ 85%] Generating test_dyndrivers_dir/xfig.rc [ 87%] Built target test_xfig_dyndriver Scanning dependencies of target test_qt_dyndriver [ 87%] Generating test_dyndrivers_dir/qt.rc This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Running the make again with VERBOSE=1 I see the line [ 87%] Generating test_dyndrivers_dir/qt.rc cd C:\plplot-5.9.7\build\drivers && ..\dll\test-drv-info.exe qt > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc I checked the test-drv-info.c and added some debug printf's to it which indicate it is returning normally with no error. The contents of qt.rc are: bmpqt:Qt Windows bitmap driver:0:qt:66:bmpqt jpgqt:Qt jpg driver:0:qt:67:jpgqt pngqt:Qt png driver:0:qt:68:pngqt ppmqt:Qt ppm driver:0:qt:69:ppmqt tiffqt:Qt tiff driver:0:qt:70:tiffqt svgqt:Qt SVG driver:0:qt:71:svgqt qtwidget:Qt Widget:1:qt:72:qtwidget epsqt:Qt EPS driver:0:qt:73:epsqt pdfqt:Qt PDF driver:0:qt:74:pdfqt extqt:External Qt driver:0:qt:75:extqt memqt:Memory Qt driver:0:qt:76:memqt I am running 64 bit Windows 7. So, can anyone help me with this, has anyone succeeded in running Plplot with Qt under Windows 7? Thanks Richard |
From: Alan W. I. <ir...@be...> - 2011-05-26 17:16:39
|
Hi Richard: On 2011-05-26 17:23+0100 Richard Jackson wrote: > I have a Plplot-5.9.7/Qt application running well under Fedora 14 and I am > now trying to port it to Windows using MinGW. > Following the instructions at > http://www.miscdebris.net/plplot_wiki/index.php?title=Configure_PLplot_for_M > inGW/CLI .... > > I downloaded and installed Qt_SDK_Windows_online_v1_1_en.exe from > http://qt.nokia.com/downloads/sdk-windows-cpp and checked I can build Qt > applications without Plplot OK. > I downloaded and installed cmake from > http://www.cmake.org/cmake/resources/software.html. > I added C:\QtSDK\Desktop\Qt\4.7.3\mingw\bin\ and C:QtSDK\mingw\bin to my > PATH variable. > > In the build directory I ran cmake -G "MinGW Makefiles" > -DCMAKE_INSTALL_PREFIX=install .. > It runs through OK until it gets to > > Scanning dependencies of target test-drv-info > [ 83%] Building C object > drivers/CMakeFiles/test-drv-info.dir/test-drv-info.c.obj > Linking C executable ..\dll\test-drv-info.exe > [ 83%] Built target test-drv-info > Scanning dependencies of target xfig > [ 85%] Building C object drivers/CMakeFiles/xfig.dir/xfig.c.obj > Linking C shared module ..\dll\xfig.dll > [ 85%] Built target xfig > Scanning dependencies of target test_xfig_dyndriver > [ 85%] Generating test_dyndrivers_dir/xfig.rc > [ 87%] Built target test_xfig_dyndriver > Scanning dependencies of target test_qt_dyndriver > [ 87%] Generating test_dyndrivers_dir/qt.rc > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > > Running the make again with VERBOSE=1 I see the line > [ 87%] Generating test_dyndrivers_dir/qt.rc > cd C:\plplot-5.9.7\build\drivers && ..\dll\test-drv-info.exe qt > > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc > > I checked the test-drv-info.c and added some debug printf's to it which > indicate it is returning normally with no error. > The contents of qt.rc are: > bmpqt:Qt Windows bitmap driver:0:qt:66:bmpqt > jpgqt:Qt jpg driver:0:qt:67:jpgqt > pngqt:Qt png driver:0:qt:68:pngqt > ppmqt:Qt ppm driver:0:qt:69:ppmqt > tiffqt:Qt tiff driver:0:qt:70:tiffqt > svgqt:Qt SVG driver:0:qt:71:svgqt > qtwidget:Qt Widget:1:qt:72:qtwidget > epsqt:Qt EPS driver:0:qt:73:epsqt > pdfqt:Qt PDF driver:0:qt:74:pdfqt > extqt:External Qt driver:0:qt:75:extqt > memqt:Memory Qt driver:0:qt:76:memqt That result is correct (i.e., the same as I get on Linux). Could you confirm (1) when you run ..\dll\test-drv-info.exe qt > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc by hand there are no errors and you produce the above good result, while if (2) you run the same command automatically via cmake and "make VERBOSE=1" _in a fresh build directory_ you get run-time errors? If so, then the next question is what (e.g., PATH) is different between the two cases? Also, for the second case with run-time errors do you get the above qt.rc result or no result at all? > > I am running 64 bit Windows 7. > > So, can anyone help me with this, has anyone succeeded in running Plplot > with Qt under Windows 7? I am not sure whether it is related or not, but my own tests of the qt device under wine (the free [in both senses] implementation of Windows that is available under Linux) have been problematic. When I tried it for an old version of MinGW it worked fine. But once I moved to the modern version of MinGW (4.5.0-1) installed with the automatic mingw/msys installer, the qt device driver quit working. The (linking) issue was that the nokia downloadable Qt SDK contained an old version of MinGW that was incompatible with MinGW (4.5.0-1). This result was for a number of months ago, and I am sure that both MinGW and Qt SDK have been updated since, and they may be compatible now. But the point is that the version of MinGW in the Qt SDK should be the same as the version of MinGW that you have downloaded independently in order to get reliable results. Note that independent download and install of MinGW is necessary if you are interested in more languages (such as Fortran and Ada) than those supported by the Qt SDK version of MinGW. But if you are only interested in C and C++, I assume you could manipulate your PATH so that you exclusively used the Qt SDK version of MinGW. 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: Richard J. <rrj...@go...> - 2011-05-26 17:49:07
|
Alan, Thanks for the quick response. If I run ..\dll\test-drv-info.exe qt > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc It produces the same qt.rc file but still I get the error: This application has requested the Runtime to terminate it in an unusual> way. Please contact the application's support team for more information. I am sure that test-drv-info is trying to return normally, I put a printf just before the return 0 statement to prove it. So, I too was wondering if it was something to do with MinGW, but what I can't understand is why the preceding test-drv-info.exe qt xfig works OK. I only have the version of MinGW that comes with QtSDK - I decided on this because I also use Netbeans and they suggest this is the most stable. I may try another version. I looked at the Makefiles and the CMakefiles to see if I could persuade the Make to continue despite this error and see if it produces a working installation. But my knowledge of CMake is not good enough to find the right place to make this change. Maybe someone could help me on this? Thanks Richard -----Original Message----- From: Alan W. Irwin [mailto:ir...@be...] Sent: 26 May 2011 18:16 To: Richard Jackson Cc: plp...@li... Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows Hi Richard: On 2011-05-26 17:23+0100 Richard Jackson wrote: > I have a Plplot-5.9.7/Qt application running well under Fedora 14 and I am > now trying to port it to Windows using MinGW. > Following the instructions at > http://www.miscdebris.net/plplot_wiki/index.php?title=Configure_PLplot_for_M > inGW/CLI .... > > I downloaded and installed Qt_SDK_Windows_online_v1_1_en.exe from > http://qt.nokia.com/downloads/sdk-windows-cpp and checked I can build Qt > applications without Plplot OK. > I downloaded and installed cmake from > http://www.cmake.org/cmake/resources/software.html. > I added C:\QtSDK\Desktop\Qt\4.7.3\mingw\bin\ and C:QtSDK\mingw\bin to my > PATH variable. > > In the build directory I ran cmake -G "MinGW Makefiles" > -DCMAKE_INSTALL_PREFIX=install .. > It runs through OK until it gets to > > Scanning dependencies of target test-drv-info > [ 83%] Building C object > drivers/CMakeFiles/test-drv-info.dir/test-drv-info.c.obj > Linking C executable ..\dll\test-drv-info.exe > [ 83%] Built target test-drv-info > Scanning dependencies of target xfig > [ 85%] Building C object drivers/CMakeFiles/xfig.dir/xfig.c.obj > Linking C shared module ..\dll\xfig.dll > [ 85%] Built target xfig > Scanning dependencies of target test_xfig_dyndriver > [ 85%] Generating test_dyndrivers_dir/xfig.rc > [ 87%] Built target test_xfig_dyndriver > Scanning dependencies of target test_qt_dyndriver > [ 87%] Generating test_dyndrivers_dir/qt.rc > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > > Running the make again with VERBOSE=1 I see the line > [ 87%] Generating test_dyndrivers_dir/qt.rc > cd C:\plplot-5.9.7\build\drivers && ..\dll\test-drv-info.exe qt > > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc > > I checked the test-drv-info.c and added some debug printf's to it which > indicate it is returning normally with no error. > The contents of qt.rc are: > bmpqt:Qt Windows bitmap driver:0:qt:66:bmpqt > jpgqt:Qt jpg driver:0:qt:67:jpgqt > pngqt:Qt png driver:0:qt:68:pngqt > ppmqt:Qt ppm driver:0:qt:69:ppmqt > tiffqt:Qt tiff driver:0:qt:70:tiffqt > svgqt:Qt SVG driver:0:qt:71:svgqt > qtwidget:Qt Widget:1:qt:72:qtwidget > epsqt:Qt EPS driver:0:qt:73:epsqt > pdfqt:Qt PDF driver:0:qt:74:pdfqt > extqt:External Qt driver:0:qt:75:extqt > memqt:Memory Qt driver:0:qt:76:memqt That result is correct (i.e., the same as I get on Linux). Could you confirm (1) when you run ..\dll\test-drv-info.exe qt > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc by hand there are no errors and you produce the above good result, while if (2) you run the same command automatically via cmake and "make VERBOSE=1" _in a fresh build directory_ you get run-time errors? If so, then the next question is what (e.g., PATH) is different between the two cases? Also, for the second case with run-time errors do you get the above qt.rc result or no result at all? > > I am running 64 bit Windows 7. > > So, can anyone help me with this, has anyone succeeded in running Plplot > with Qt under Windows 7? I am not sure whether it is related or not, but my own tests of the qt device under wine (the free [in both senses] implementation of Windows that is available under Linux) have been problematic. When I tried it for an old version of MinGW it worked fine. But once I moved to the modern version of MinGW (4.5.0-1) installed with the automatic mingw/msys installer, the qt device driver quit working. The (linking) issue was that the nokia downloadable Qt SDK contained an old version of MinGW that was incompatible with MinGW (4.5.0-1). This result was for a number of months ago, and I am sure that both MinGW and Qt SDK have been updated since, and they may be compatible now. But the point is that the version of MinGW in the Qt SDK should be the same as the version of MinGW that you have downloaded independently in order to get reliable results. Note that independent download and install of MinGW is necessary if you are interested in more languages (such as Fortran and Ada) than those supported by the Qt SDK version of MinGW. But if you are only interested in C and C++, I assume you could manipulate your PATH so that you exclusively used the Qt SDK version of MinGW. 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: Alan W. I. <ir...@be...> - 2011-05-26 19:37:48
|
Hi Richard: On 2011-05-26 18:48+0100 Richard Jackson wrote: > Alan, > > Thanks for the quick response. > > If I run ..\dll\test-drv-info.exe qt > > C:/plplot-5.9.7/build/drivers/test_dyndrivers_dir/qt.rc > It produces the same qt.rc file but still I get the error: > > This application has requested the Runtime to terminate it in an unusual> > way. > Please contact the application's support team for more information. > > I am sure that test-drv-info is trying to return normally, I put a printf > just before the return 0 statement to prove it. Hmmm. I guess that means "return 0;" doesn't really mean exactly that in all cases for the Windows platform. I strongly suspect (because virtually all test-drv-info.exe issues concern linking) there is some preceding run-time linking error that is causing the above error message once the test-drv-info.exe application exits. Under wine, I am more experienced with MinGW/MSYS (-G "MSYS Makefiles" cmake option) rather than MinGW without MSYS (-G "MinGW Makefiles" cmake option). In any case, note that MSYS has the really useful ldd.exe application which allows you to analyze whether there are any linking errors. It has been a while since I tried ldd.exe under wine, but the equivalent ldd application under Linux gives the following results for qt.so in the build tree ldd -r drivers/qt.so linux-vdso.so.1 => (0x00007fffea3ff000) libplplotd.so.10 => /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.10 (0x00007eff60598000) libplplotqtd.so.0 => /home/software/plplot_svn/HEAD/build_dir/bindings/qt_gui/libplplotqtd.so.0 (0x00007eff60376000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007eff6014c000) libdl.so.2 => /lib/libdl.so.2 (0x00007eff5ff48000) libcsirocsa.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0 (0x00007eff5fd3e000) libcsironn.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0 (0x00007eff5fb34000) libqhull.so.5 => /home/software/qhull/install/lib/libqhull.so.5 (0x00007eff5f8d1000) libqsastime.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0 (0x00007eff5f6c9000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007eff5f441000) libm.so.6 => /lib/libm.so.6 (0x00007eff5f1bf000) libQtSvg.so.4 => /usr/lib/libQtSvg.so.4 (0x00007eff5ef63000) libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x00007eff5e284000) libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x00007eff5e03c000) libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007eff5dbaa000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007eff5d896000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007eff5d680000) libc.so.6 => /lib/libc.so.6 (0x00007eff5d31e000) /lib64/ld-linux-x86-64.so.2 (0x00007eff60a21000) libz.so.1 => /usr/lib/libz.so.1 (0x00007eff5d107000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007eff5ced1000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007eff5ccb5000) libaudio.so.2 => /usr/lib/libaudio.so.2 (0x00007eff5ca9c000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007eff5c7bf000) libpng12.so.0 => /lib/libpng12.so.0 (0x00007eff5c599000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007eff5c352000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00007eff5c149000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00007eff5bf2e000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007eff5bd24000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007eff5bb11000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007eff5b7d6000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007eff5b5d2000) librt.so.1 => /lib/librt.so.1 (0x00007eff5b3c9000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007eff5b1a1000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00007eff5af3c000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007eff5ad39000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007eff5ab09000) libuuid.so.1 => /lib/libuuid.so.1 (0x00007eff5a904000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007eff5a6e8000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007eff5a4e2000) You will note that all the PLplot build-tree and Qt libraries are found in the correct location. In addition, the -r option for ldd lets you know if there are any undefined symbols detected by the run-time linking. (You often get such undefined symbols if there is a library version mismatch or incompatibility). For my present Linux case, there are no such undefined symbols, and that was also true for the wine platform tests I did for the old MinGW installation but not true of the later MinGW installation where ldd.exe -r showed missing symbols indicating library version mismatches which explained the other qt device errors I was getting from that MinGW version. There may be some Windows application that does the same thing as ldd which states which versions of libraries are being used to make sure you are not using some stale older version by mistake due to an incorrect PATH and which also checks for undefined symbols. Anyhow, I would advise running ldd.exe or Windows equivalent to check for such linking issues. Of course, the PATH (which, of course, has to include the dll subdirectory of the build tree) which you use during your ldd or equivalent test has to be the same as during your run of test-drv-info.exe. > > So, I too was wondering if it was something to do with MinGW, but what I > can't understand is why the preceding test-drv-info.exe qt xfig works OK. That only tests the xfig device driver which has a much less complicated run-time linking environment, i.e., ldd -r drivers/xfig.so linux-vdso.so.1 => (0x00007fffe71d4000) libplplotd.so.10 => /home/software/plplot_svn/HEAD/build_dir/src/libplplotd.so.10 (0x00007ff8a5cbb000) libm.so.6 => /lib/libm.so.6 (0x00007ff8a5a17000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007ff8a580e000) libdl.so.2 => /lib/libdl.so.2 (0x00007ff8a560a000) libcsirocsa.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/csa/libcsirocsa.so.0 (0x00007ff8a5400000) libcsironn.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/nn/libcsironn.so.0 (0x00007ff8a51f6000) libqhull.so.5 => /home/software/qhull/install/lib/libqhull.so.5 (0x00007ff8a4f93000) libqsastime.so.0 => /home/software/plplot_svn/HEAD/build_dir/lib/qsastime/libqsastime.so.0 (0x00007ff8a4d8b000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007ff8a4b03000) libc.so.6 => /lib/libc.so.6 (0x00007ff8a47a2000) /lib64/ld-linux-x86-64.so.2 (0x00007ff8a613c000) libz.so.1 => /usr/lib/libz.so.1 (0x00007ff8a458a000) > > I only have the version of MinGW that comes with QtSDK - I decided on this > because I also use Netbeans and they suggest this is the most stable. I may > try another version. I recommend the very latest automatic downloader/installer for MinGW/MSYS. It is still rough around the edges, but it gets the principal job done (at least under wine) which is to analyze the zillions of different MinGW/MSYS dependencies and download and install only the subset of MinGW/MSYS packages that you need. > > I looked at the Makefiles and the CMakefiles to see if I could persuade the > Make to continue despite this error and see if it produces a working > installation. But my knowledge of CMake is not good enough to find the > right place to make this change. > > Maybe someone could help me on this? The problem with the idea of skipping the test-drv-info.exe test is that test is a really simple test of the qt device driver. If that simple test cannot finish without run-time errors (almost always due to bad run-time linking), then the same will likely be true if you run one of the qt devices in a less superficial way. Thus, I am virtually positive you must figure out the reason for the run-time error that you are getting (e.g., by running ldd.exe or Windows equivalent) with the simple test of qt.so. If you cannot figure out the reason for the run-time error, I think you are stuck for the qt devices, and to continue with PLplot you must disable the qt device driver and use some different set of PLplot device (such as the cairo ones). BTW, the qt and cairo devices are our best devices (with cairo currently slightly in the lead). So if you lose qt but can get cairo to work (or vice versa) the results generally look really good. However, if you cannot get either to work, then there are plenty of other devices that might meet your needs, but the fonts, for example, may not look as good as for the qt and cairo devices. 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: Arjen M. <arj...@de...> - 2011-05-27 07:21:00
|
Hi Alan, On 2011-05-26 21:37, Alan W. Irwin wrote: > > Hmmm. I guess that means "return 0;" doesn't really mean exactly that > in all cases for the Windows platform. I strongly suspect (because > virtually all test-drv-info.exe issues concern linking) there is some > preceding run-time linking error that is causing the above error > message once the test-drv-info.exe application exits. > I think the error that is reported occurs _after_ the return statement in the "postamble" of a program. I have seen this message before and it is rather unhelpful. Quite possibly some access violation occurs somewhere in the program, upsetting internal structures, like the ones maintained by malloc() and free() and this is only noticed when the program actually finishes and cleans up everything. But that does not help the average programmer one bit. > Under wine, I am more experienced with MinGW/MSYS (-G "MSYS Makefiles" > cmake option) rather than MinGW without MSYS (-G "MinGW Makefiles" > cmake option). In any case, note that MSYS has the really useful > ldd.exe application which allows you to analyze whether there are any > linking errors. It has been a while since I tried ldd.exe under wine, > but the equivalent ldd application under Linux gives the following > results for qt.so in the build tree > ... > > There may be some Windows application that does the same thing as ldd > which states which versions of libraries are being used to make sure > you are not using some stale older version by mistake due to an > incorrect PATH and which also checks for undefined symbols. Anyhow, I > would advise running ldd.exe or Windows equivalent to check for such > linking issues. Of course, the PATH (which, of course, has to include > the dll subdirectory of the build tree) which you use during your ldd > or equivalent test has to be the same as during your run of > test-drv-info.exe. > The canonical application to use on Windows is "Dependency Walker" - http://www.dependencywalker.com/. It is not flawless, as it does not really support "side-by-side assemblies", but it ought to give you enough insight in what DLLs are found where and what symbols are exported etc. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Richard J. <rrj...@go...> - 2011-05-27 10:44:25
|
Alan, Arjen, I tried a few more things: 1. I downloaded the latest MinGW and used that instead, it does has later compiler and library versions but makes no difference, I still get the same error. 2. I installed and ran everything on a 32 bit XP machine instead of 64 bit Windows 7, it makes no difference, I still get the same error. 3. I looked at qt.dll with PEexplorer, it showed me the attached list of dependencies, qt.depend.txt. gpsvc.dll is missing, I googled this and it's to do with group policy services and can't be seen unless you are running as administrator - it is actually there in windows/system32. Its commonly shown as missing in dll explorers but doesn't do any harm unless anything tries to load it. I'm almost certain this is not the problem. 4. More interestingly the PE disassembler is showing a problem as you can see in the attached screenshot. There is code potentially running into non-executable stuff if the jnz is not taken, but I don't know how to find where this is. In view of the next test below i don't think its relevant. 5. I hacked test-drv-info.c around to make it do nothing but a direct call to load the qt dll without using ltdl_win32. If it loads it, it then exits abnormally, even when making no further reference to it. If I make it not load it, it exits normally. 6. I get a Windows pop up when it exits abnormally which has a more details button, somehow I missed that yesterday. It gives this information: Problem signature: Problem Event Name: APPCRASH Application Name: test-drv-info.exe Application Version: 0.0.0.0 Application Timestamp: 4ddf59cb Fault Module Name: libgcc_s_dw2-1.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 4a404122 Exception Code: 40000015 Exception Offset: 000077f2 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 2057 Additional Information 1: d5d2 Additional Information 2: d5d281f2a1bbc99521afb94afe3326b1 Additional Information 3: 5c06 Additional Information 4: 5c06047b4e989d4e5419db87ebae8062 I wouldn't know how to interpret this. 7. I tried downloading and running dependency walker instead of PEexplore and it showed me some more errors: Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module. Error: Modules with different CPU types were found. Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module. In the module detail its showing IESHIMS.DLL as missing and all the Windows DLL's as 64bit with the Plplot and Qt dlls as 32 bit. It finds gpsvc.dll OK. I've attached the output as qt.txt. I found IESHIMS.DLL in c:\Program Files\Internet Explorer and out it into my PATH so dependency walker no longer shows it as missing but it makes no difference to the error. I guess the mixture ofd 32 and 64 bit dlls is not the problem either as I get the same error on 32 bit XP. So, I've really run out of ideas now. It's not an option for me to use another driver such as Cairo under Windows, I have a large Fedora Qt application, Plplot is only a part of it. It's a requirement for me to make a port of it for Windows so I guess I'm just going to have to look at other plotting packages, unless anyone has any more suggestions. Am I really the only person using Qt/Plplot with Windows? Anyway thanks for the help Regards Richard |
From: Arjen M. <arj...@de...> - 2011-05-27 11:03:16
|
Hi Richard, like I said Dependency Walker is not entirely perfect. I have seen such DLLs as IESHIMS.DLL pop up too and various others that were reported as missing, but turned out to be irrelevant. I have never programmed via Qt, but perhaps the time has come to take a closer look. I will see that I download it as per your information and see if that reproduces the problem. That ought to give us at least some starting point. Regards, Arjen On 2011-05-27 12:44, Richard Jackson wrote: > Alan, Arjen, > > I tried a few more things: > > 1. I downloaded the latest MinGW and used that instead, it does has later > compiler and library versions but makes no difference, I still get the same > error. > 2. I installed and ran everything on a 32 bit XP machine instead of 64 bit > Windows 7, it makes no difference, I still get the same error. > 3. I looked at qt.dll with PEexplorer, it showed me the attached list of > dependencies, qt.depend.txt. gpsvc.dll is missing, I googled this and it's > to do with group policy services and can't be seen unless you are running as > administrator - it is actually there in windows/system32. Its commonly shown > as missing in dll explorers but doesn't do any harm unless anything tries > to load it. I'm almost certain this is not the problem. > 4. More interestingly the PE disassembler is showing a problem as you can > see in the attached screenshot. There is code potentially running into > non-executable stuff if the jnz is not taken, but I don't know how to find > where this is. In view of the next test below i don't think its relevant. > 5. I hacked test-drv-info.c around to make it do nothing but a direct call > to load the qt dll without using ltdl_win32. If it loads it, it then exits > abnormally, even when making no further reference to it. If I make it not > load it, it exits normally. > 6. I get a Windows pop up when it exits abnormally which has a more details > button, somehow I missed that yesterday. > It gives this information: > > Problem signature: > Problem Event Name: APPCRASH > Application Name: test-drv-info.exe > Application Version: 0.0.0.0 > Application Timestamp: 4ddf59cb > Fault Module Name: libgcc_s_dw2-1.dll > Fault Module Version: 0.0.0.0 > Fault Module Timestamp: 4a404122 > Exception Code: 40000015 > Exception Offset: 000077f2 > OS Version: 6.1.7600.2.0.0.256.48 > Locale ID: 2057 > Additional Information 1: d5d2 > Additional Information 2: d5d281f2a1bbc99521afb94afe3326b1 > Additional Information 3: 5c06 > Additional Information 4: 5c06047b4e989d4e5419db87ebae8062 > > I wouldn't know how to interpret this. > > 7. I tried downloading and running dependency walker instead of PEexplore > and it showed me some more errors: > > Error: At least one module has an unresolved import due to a missing export > function in an implicitly dependent module. > Error: Modules with different CPU types were found. > Warning: At least one delay-load dependency module was not found. > Warning: At least one module has an unresolved import due to a missing > export function in a delay-load dependent module. > > In the module detail its showing IESHIMS.DLL as missing and all the Windows > DLL's as 64bit with the Plplot and Qt dlls as 32 bit. It finds gpsvc.dll OK. > I've attached the output as qt.txt. I found IESHIMS.DLL in c:\Program > Files\Internet Explorer and out it into my PATH so dependency walker no > longer shows it as missing but it makes no difference to the error. I guess > the mixture ofd 32 and 64 bit dlls is not the problem either as I get the > same error on 32 bit XP. > > So, I've really run out of ideas now. > > It's not an option for me to use another driver such as Cairo under Windows, > I have a large Fedora Qt application, Plplot is only a part of it. It's a > requirement for me to make a port of it for Windows so I guess I'm just > going to have to look at other plotting packages, unless anyone has any more > suggestions. Am I really the only person using Qt/Plplot with Windows? > > Anyway thanks for the help > > Regards > Richard > > > > > > ------------------------------------------------------------------------ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Steve S. <s.s...@im...> - 2011-05-27 11:19:53
|
Richard, On Fri, 2011-05-27 at 11:44 +0100, Richard Jackson wrote: > It's not an option for me to use another driver such as Cairo under > Windows, > I have a large Fedora Qt application, Plplot is only a part of it. > It's a > requirement for me to make a port of it for Windows so I guess I'm > just > going to have to look at other plotting packages, unless anyone has > any more > suggestions. Am I really the only person using Qt/Plplot with Windows? No you're not. We likewise built a large Qt application called QSAS and eventually needed to support it on Windows (and MacOS) in addition to the *nix platforms on which it was initially developed. And my team wrote the initial plplot qt drivers for that purpose, to replace the older fortran-based pgplot routines we used up to then. Since then, of course, the plplot core team have modified and improved the plplot qt drivers we delivered to them; we pick up newer plplot versions from time to time. Instead of relying on separate installations of plplot and such, we bundle much of the source code with our own, and use our own build scripts to compile and link it all together. On our *nix platforms we use autoconf rather than Cmake. Some of this of course might be regarded as heresy by the plplot purists, e.g.: * we aren't up-to-date with plplot releases * we don't use Cmake * we don't build any drivers apart from the qt ones but it works for us and our user community. Using qt also enables you to embed graphics in qt widgets adorned with control buttons, sliders, etc., and generally makes for a very consistent clean user interface and experience. Before you get too excited I need to come clean a bit. The person on the team who successfully ported QSAS to Windows is no longer with us. We rely on somewhat blindly following his recipe. We live in fear that something in Windows or qt or mingw or whatever will grow into a brick wall that we lack the time, energy, and expertise to solve (this is much wider, of course, than just the plplot component of QSAS). If you are interested in pursuing this, I would suggest that you download the Windows version of QSAS and see if it runs out of the box on your platform; we ship binaries for Windows due to the difficulty in building it, and ditto for our Mac version, whereas the *nix ones are usually built from source by our users. If so, that may give you some incentive to pursue further; if not, we'd like to hear about it in order to see if there is something we need to fix. Then I'd suggest you look at the "recipe" to which I referred above, which I'll send to you off-line; it is build_windows.txt and lives in our doc directory. That may give some clues to help you. In particular, my ex-colleague includes several tips about what to check/not check at various stages of the mingw installation. You can pick pick up QSAS at: http://www.sp.ph.ic.ac.uk/csc-web/QSAS/ HTH, and good luck Best wishes Steve PS: I've bcc'ed this to my colleague who maintains and develops our software. You can reach us at csc...@im... -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Richard J. <rrj...@go...> - 2011-05-27 12:03:49
|
Steve, Thanks very much for the information, that will give me something to work with. Unfortunately I'm going to be away for the next couple of weeks now, but I will get back to this on my return. Thanks again Richard -----Original Message----- From: Steve Schwartz [mailto:s.s...@im...] Sent: 27 May 2011 12:22 To: Richard Jackson Cc: 'Arjen Markus'; 'Alan W. Irwin'; plp...@li... Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows Richard, On Fri, 2011-05-27 at 11:44 +0100, Richard Jackson wrote: > It's not an option for me to use another driver such as Cairo under > Windows, > I have a large Fedora Qt application, Plplot is only a part of it. > It's a > requirement for me to make a port of it for Windows so I guess I'm > just > going to have to look at other plotting packages, unless anyone has > any more > suggestions. Am I really the only person using Qt/Plplot with Windows? No you're not. We likewise built a large Qt application called QSAS and eventually needed to support it on Windows (and MacOS) in addition to the *nix platforms on which it was initially developed. And my team wrote the initial plplot qt drivers for that purpose, to replace the older fortran-based pgplot routines we used up to then. Since then, of course, the plplot core team have modified and improved the plplot qt drivers we delivered to them; we pick up newer plplot versions from time to time. Instead of relying on separate installations of plplot and such, we bundle much of the source code with our own, and use our own build scripts to compile and link it all together. On our *nix platforms we use autoconf rather than Cmake. Some of this of course might be regarded as heresy by the plplot purists, e.g.: * we aren't up-to-date with plplot releases * we don't use Cmake * we don't build any drivers apart from the qt ones but it works for us and our user community. Using qt also enables you to embed graphics in qt widgets adorned with control buttons, sliders, etc., and generally makes for a very consistent clean user interface and experience. Before you get too excited I need to come clean a bit. The person on the team who successfully ported QSAS to Windows is no longer with us. We rely on somewhat blindly following his recipe. We live in fear that something in Windows or qt or mingw or whatever will grow into a brick wall that we lack the time, energy, and expertise to solve (this is much wider, of course, than just the plplot component of QSAS). If you are interested in pursuing this, I would suggest that you download the Windows version of QSAS and see if it runs out of the box on your platform; we ship binaries for Windows due to the difficulty in building it, and ditto for our Mac version, whereas the *nix ones are usually built from source by our users. If so, that may give you some incentive to pursue further; if not, we'd like to hear about it in order to see if there is something we need to fix. Then I'd suggest you look at the "recipe" to which I referred above, which I'll send to you off-line; it is build_windows.txt and lives in our doc directory. That may give some clues to help you. In particular, my ex-colleague includes several tips about what to check/not check at various stages of the mingw installation. You can pick pick up QSAS at: http://www.sp.ph.ic.ac.uk/csc-web/QSAS/ HTH, and good luck Best wishes Steve PS: I've bcc'ed this to my colleague who maintains and develops our software. You can reach us at csc...@im... -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Hazen B. <hba...@ma...> - 2011-05-27 13:03:28
|
On 05/27/2011 06:44 AM, Richard Jackson wrote: > It's not an option for me to use another driver such as Cairo under Windows, > I have a large Fedora Qt application, Plplot is only a part of it. It's a > requirement for me to make a port of it for Windows so I guess I'm just > going to have to look at other plotting packages, unless anyone has any more > suggestions. Am I really the only person using Qt/Plplot with Windows? Richard, I have installed and used Plplot with Qt on 32bit Windows XP following the "standard" route, so I know that it can be done. I used MinGW 5.1.4, CMake 2.8, Qt 4.6.0 and PLplot 5.9.6. However, I did not see the error that is troubling you, so unfortunately I don't think I can be of much help. -Hazen |