Hi Richard, (in a hurry) one reason for this behaviour is that the DLLs you need are not in the path. Quite often you do not get any indication of what is wrong - the program simply stops. At other times you do get a message box.
One way to find out is to use Dependency Walker - www.dependencywalker.com. Regards, Arjen On 2011-06-17 12:59, Richard Jackson wrote: > Hi Alan, > > When I tried my main application I got it to link OK but it would not run, > either it did nothing or just "terminates unexpectedly". I would guess it's > due to incompatible library calls between the two compiler versions. So I > decided this was a dead end and I had to have both Plplot and Qt built with > the sample compiler versions. > > In the interest of simplicity I decided to go back to Qt 4.5.3 (Qt SDK > 2009.04) which builds PLplot OK with the included compiler gcc 3.4.5. I did > that and built the Qt/Plplot program which had been OK with Qt 4.7.3 and it > ran and displayed graphs OK. > > But I still have the same problem with my main application, it compiles and > links without problems but just crashes as soon as its invoked. > > This is the link command cut and pasted direct from the Netbeans window, > most of it is supplied automatically by Netbeans but I had to specifically > tell Netbeans where to find the Plplot libraries. > > g++ -enable-stdcall-fixup -Wl,-enable-auto-import > -Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o > dist/Debug/MinGW-Windows/QtProfile.exe object_script.QtProfile > -L'c:/Qt/2009.04/qt/lib' -lmingw32 -lqtmaind > build/Debug/MinGW-Windows/QtProfile_resource_res.o > C:/plplot-5.9.7/build/install/lib/libcsirocsa.dll.a > C:/plplot-5.9.7/build/install/lib/libplplotcxxd.dll.a > C:/plplot-5.9.7/build/install/lib/libplplotd.dll.a > C:/plplot-5.9.7/build/install/lib/libplplotqtd.dll.a > C:/plplot-5.9.7/build/install/lib/libqsastime.dll.a -lQtGuid4 -lQtCored4 > > I thought it might be a problem with Netbeans/Qt rather than Plplot so I > thought I would try using QtCreator instead. I built and ran my simple > Plplot example that worked with the Netbeans link but it crashes > immediately. > QtCreator gives a bit more information: > Starting D:\Data\QtProjects\App\debug\App.exe... > Invalid parameter passed to C runtime function. > Invalid parameter passed to C runtime function. > D:\Data\QtProjects\App\debug\App.exe exited with code 3 > > This was the link command cut & pasted from the QtCreator window: > g++ -enable-stdcall-fixup -Wl,-enable-auto-import > -Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o > debug\App.exe debug/mainwindow.o debug/main.o debug/csvparser.o > debug/moc_mainwindow.o -L"c:\Qt\2009.04\qt\lib" -lmingw32 -lqtmaind > C:\plplot-5.9.7\build\install\lib\libplplotqtd.dll.a > C:\plplot-5.9.7\build\install\lib\libcsirocsa.dll.a > C:\plplot-5.9.7\build\install\lib\libplplotcxxd.dll.a > C:\plplot-5.9.7\build\install\lib\libplplotd.dll.a > C:\plplot-5.9.7\build\install\lib\libqsastime.dll.a -lQtGuid4 -lQtCored4 > > For this same program, the Netbeans link command that worked OK was: > g++ -enable-stdcall-fixup -Wl,-enable-auto-import > -Wl,-enable-runtime-pseudo-reloc -Wl,-s -mthreads -Wl -Wl,-subsystem,windows > -o dist/Release/MinGW-Windows/app.exe build/Release/MinGW-Windows/main.o > build/Release/MinGW-Windows/csvparser.o > build/Release/MinGW-Windows/mainwindow.o > build/Release/MinGW-Windows/moc_mainwindow.o -L'c:/Qt/2009.04/qt/lib' > -lmingw32 -lqtmain build/Release/MinGW-Windows/app_resource_res.o > C:/plplot-5.9.7/build/install/lib/libcsirocsa.dll.a > C:/plplot-5.9.7/build/install/lib/libplplotcxxd.dll.a > C:/plplot-5.9.7/build/install/lib/libplplotd.dll.a > C:/plplot-5.9.7/build/install/lib/libplplotqtd.dll.a > C:/plplot-5.9.7/build/install/lib/libqsastime.dll.a -lQtGui4 -lQtCore4 > > The difference is the -s option which removes all symbol table and > relocation information from the executable. In Netbeans I then built the > Debug version and it crashes just like the QtCreator version. Looking back > at my main application, I was building the debug version there too, so I > changed to build a release version and it all runs! I have a feeling it > would also run with Qt 4.7.3 linked with Plplot compiled with gcc 4.4.4. One > question, does the Plplot build include debug symbols and if so, can I > disable it somehow? > > One problem I didn't mention earlier, when I built PLplot with gcc 3.4.5 it > would not build the C++ examples - it was missing the usleep() function, so > I think it's pretty pointless trying to run the test suite with this > compiler. > > I still have another major module of my application to port across which > includes threads and USB access, and it is using usleep() so I am planning > to go back to Qt 4.7.3 and gcc 4.4.0 and try building Plplot with > TEST_DYNDRIVERS=OFF next > > And just to clear up how I am choosing which compiler versions to run - for > the Plplot Cmake and make it's just a matter of having the correct compiler > and Qt binary directories in the PATH variable. For Netbeans you can > explicitly select a toolchain via a configuration window. So after I built > plplot with gcc 4.4.4 I just changed the PATH variable and Netbeans to point > at gcc 4.4.0 and it compiled and linked OK with the precompiled plplot > libraries. > > 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 > __________________________ > > 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. ------------------------------------------------------------------------------ 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
