Hi Alan, I tried rebuilding plplot 5.9.7 with the latest Qt 4.7.3 and its included gcc 4.4.0 using the cmake option -DTEST_DYNDRIVERS=OFF and everything worked. It also makes and runs the qt_example.cpp ok.
For the record you can't do it all in one go and have the examples built, you have to do the following sequence: cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DCMAKE_INSTALL_PREFIX= .. mingw32-make followed by cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. mingw32-make which then builds all the c and c++ examples. Once you have included the dll and drivers folders in your PATH you can run any of the examples just by clicking on its .exe file. I tried an install with cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX=d:\utils\plplot .. mingw32-make install But it put the bin, include, lib and share folders in the root of my D: drive, so I just moved them manually to where I wanted them. It also puts the driver DLLs in lib\plplot5.9.7\driversd which is a little counter intuitive but no real problem. I then compiled and linked my main qt/plplot application OK, but it will not run, even in release mode. If I run it from a console window nothing happens at all, after a short delay I just get a new command prompt. I checked the .exe with dependency-walker but I can see nothing unusual, all the dlls are there apart from IESHIMS.DLL which I am sure is not the problem. I also checked my simple qt/plplot example and that will not run either. I tried building the debug version and that crashes. I repeated the whole process building plplot with gcc 4.4.4, with exactly the same results. So, the only way I can get a working application is with Qt 4.5.3 (Qt SDK 2009.04) and its included compiler gcc 3.4.5 in Release mode. I am going to have to return to that and adapt my application to suit. I did this, and still my simple application does not run! What's different from Friday? I still have the plplot build from Friday, checked the DLLs against my current build and they are different sizes. Prepended Friday's dll folder to my path so they will be used rather than my latest ones and I can now run OK. Double checked, gcc -v reports version 3.4.5, the qt in my path is 2009.04. Rebuilt without the install stage and that makes no difference. I wondered if I had inadvertently left gcc 4.4.4 in my path when I built on Friday. Tried adding it and rebuilding, but the DLLs are different sizes again, and it doesn't run. So, now I am left in the situation that I have a working build of plplot which runs with Qt 4.5.3 but I don't know how I did it and I can't recreate it! I must be missing something obvious but I can't think what. Regards Richard -----Original Message----- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: 14 June 2011 18:03 To: Richard Jackson Cc: 'Arjen Markus'; 'Hazen Babcock'; 'Werner Smekal'; 'PLplot development list' Subject: RE: [Plplot-devel] Installing Plplot with Qt under Windows Hi Richard: On 2011-06-14 15:25+0100 Richard Jackson wrote: > [...]Looked at the difference between the plplot & qt link options, > see attached, but there is nothing I can make sense of - the PLplot > explicitly included many more windows standard dlls, but adding them > to qt makes no difference. > One thing that may be relevant though is that Netbeans & QtCreator > both include qtmain in the link, plplot example does not. I assume you are comparing compile and link flags with different tool chains. I would be interested in a comparison using the same Qt SDK tool chain. You should be able to obtain the compile and link flags for qt_example for that tool chain using the method below. > [...]Found this thread > http://www.qtforum.org/article/29890/qt-4-6-linking-problem.html > So that explains why Qt applications will not build with gcc versions > other that 4.4.0 I don't understand all the reasons given in that thread, but in any case I don't think you should trust anything linking to the Qt libraries that is not built with the identical tool chain (i.e. the MinGW one supplied by the Qt SDK since it appears building Qt with a different tool chain is a tricky business). > > But what I still cannot understand is why the Plplot Qt driver will > not work with this same compiler and the Qt libraries linked with this compiler. > > Conversely, why does the Plplot build work with a later compiler such > as 4.4.4, and the Plplot qt_example work with it when a Netbeans or > QtCreator application does not? It must be a compile or link flag issue. I would strip all tool-chain related packages out of your test environment other than the MinGW-4.4.0 tool chain that comes with the Qt SDK to eliminate the possibility that you are accessing an inconsistent version by mistake. Then make sure you can compile, link, and run a simple Qt example without PLplot (as your tests have indicated is possible before). Record all the compile flags and link flags used for that build. Then look at the compile flags and link flags for the cmake-configured "make VERBOSE=1 -k" command to build qt_example with the same tool chain. (The -k option to make should allow you to build as much as possible despite errors such as occurs for the simple test done by the simple test-drv-info test. Just now I looked at our cmake build-system logic, and it turns out you can ignore the simple test-drv-info test completely by using the cmake option -DTEST_DYNDRIVERS=OFF. (Sorry I did not remember this before.) So I suggest you try that experiment just in case there is some linking issue that is exclusive to that simple test that is not present for qt_example. (You may still need to use the -k option in case there are other build issues you want to bypass in order to build qt_example.) Also, to build qt_example (and its necessary dependencies) and run it just use the qt_example make target (i.e., use "make VERBOSE=1 -k qt_example" to build that application, and the test_qt_example target (i.e., use "make VERBOSE=1 -k test_qt_example") to run it. Note, these targets will not be available unless you use the -DBUILD_TEST=ON cmake option. Anyhow, if you can get a cmake-built qt_example to build and run with the Qt SDK version of the tool chain, then that potentially narrows down the linking issue to just the test-drv-info case which would be a big step forward. > > I double checked the qt_example.cpp code, it's a straightforward qt > application just like I am trying to build with NetBeans or QtCreator. > I even copied it into Netbeans and QtCreator and then stripped out all > the Plplot references leaving just an empty application and I cannot > build it with either of them with gcc 4.4.4. It sounds like both the Netbeans and QtCreator build environments will not work on anything unless you are using the Qt SDK version of the tool chain. That's a good constraint in my book since I don't trust any result with Qt that is built with anything other than the Qt SDK version of the tool chain. > [...] Thinking some more about it, now that I have built Plplot > libraries with gcc 4.4.4, would it be possible to link those with a Qt > application built with gcc 4.4.0? Tried it and it works! - I can build > a fully featured Qt Plplot program with 3D graphs, menus, panels, spinboxes etc. That's a really strange result. Which tool chain are you using at run time? I presume your PATH points to one of them but not both. (And if both it will just use the first one in the PATH unless there is something missing from that first tool chain that is resolved by the second one in your PATH.) Anyhow, I don't trust this result, and it would be better to figure out why cmake is not generating the correct compile flags/ linking flags for the Qt SDK version of the tool chain. I hope the -DTEST_DYNDRIVERS=OFF cmake option (see above) will help you to figure that out. > > Alan, I do intend to try the full MSYS build of the examples for you, > but right now my priority is to get my main application working Understood. Such linking issues can usually be solved by something really simple, but the complicated and time-consuming part is figuring it out! Thanks for all your experiments trying to track down what the issue really is. 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 __________________________ ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
