From: Arjen M. <arj...@de...> - 2011-05-31 13:39:19
|
Hello, I installed Qt for Windows and hoped CMake would pick it up without me having to do anything. But that was too hopeful a thought. I quickly browsed the FindQt.cmake file, but that did not reveal much, at least not within the short timespan I had allotted myself. My question is: is there an option I can set to tell CMake where to find Qt? (The registry keys I saw in the FindQt.cmake file do not match the ones that were set by the installation process, and I have no idea if I can just add the ones FindQt expects) 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: Hazen B. <hba...@ma...> - 2011-05-31 14:24:05
|
On 05/31/2011 09:39 AM, Arjen Markus wrote: > Hello, > > I installed Qt for Windows and hoped CMake would pick it up > without me having to do anything. But that was too hopeful > a thought. I quickly browsed the FindQt.cmake file, but that > did not reveal much, at least not within the short timespan > I had allotted myself. > > My question is: is there an option I can set to tell CMake > where to find Qt? (The registry keys I saw in the FindQt.cmake > file do not match the ones that were set by the installation > process, and I have no idea if I can just add the ones FindQt > expects) I think that it just needs to be able to find the qmake executable, which is usually in qt\bin. I've been puzzling over my build scripts to see exactly how I did this when I built with Qt. My best guess is that I just made sure that the directory containing qmake was in my path. -Hazen |
From: Arjen M. <arj...@de...> - 2011-05-31 14:30:35
|
Hi Hazen, hm, there is a wagonload of qmake.exe's, one for each supported sub-platform. If this is enough, I should be able to get it working. Thanks. Regards, Arjen On 2011-05-31 16:23, Hazen Babcock wrote: > On 05/31/2011 09:39 AM, Arjen Markus wrote: >> Hello, >> >> I installed Qt for Windows and hoped CMake would pick it up >> without me having to do anything. But that was too hopeful >> a thought. I quickly browsed the FindQt.cmake file, but that >> did not reveal much, at least not within the short timespan >> I had allotted myself. >> >> My question is: is there an option I can set to tell CMake >> where to find Qt? (The registry keys I saw in the FindQt.cmake >> file do not match the ones that were set by the installation >> process, and I have no idea if I can just add the ones FindQt >> expects) > > I think that it just needs to be able to find the qmake executable, > which is usually in qt\bin. I've been puzzling over my build scripts to > see exactly how I did this when I built with Qt. My best guess is that I > just made sure that the directory containing qmake was in my path. > > -Hazen > 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: Hazen B. <hba...@ma...> - 2011-05-31 14:32:38
|
Hi Arjen, You probably want the one in "Desktop". -Hazen On 05/31/2011 10:30 AM, Arjen Markus wrote: > Hi Hazen, > > hm, there is a wagonload of qmake.exe's, one for each supported > sub-platform. If this is enough, I should be able to get it > working. Thanks. > > Regards, > > Arjen > > On 2011-05-31 16:23, Hazen Babcock wrote: >> On 05/31/2011 09:39 AM, Arjen Markus wrote: >>> Hello, >>> >>> I installed Qt for Windows and hoped CMake would pick it up >>> without me having to do anything. But that was too hopeful >>> a thought. I quickly browsed the FindQt.cmake file, but that >>> did not reveal much, at least not within the short timespan >>> I had allotted myself. >>> >>> My question is: is there an option I can set to tell CMake >>> where to find Qt? (The registry keys I saw in the FindQt.cmake >>> file do not match the ones that were set by the installation >>> process, and I have no idea if I can just add the ones FindQt >>> expects) >> >> I think that it just needs to be able to find the qmake executable, >> which is usually in qt\bin. I've been puzzling over my build scripts to >> see exactly how I did this when I built with Qt. My best guess is that I >> just made sure that the directory containing qmake was in my path. >> >> -Hazen >> |
From: Hazen B. <hba...@ma...> - 2011-05-31 16:26:05
|
Hi Arjen, That was also my experience on 32 bit windows. Do you have access to a 64-bit windows machine? -Hazen On 05/31/2011 10:44 AM, Arjen Markus wrote: > Hi Hazen, > > to follow up on this: > - The C examples with the various Qt drivers look fine > - There were problems with the Fortran examples - multiple definitions > of such routines as _gfortran_st_write_done (so from the runtime > library of gfortran) > > That requires some checking, but apart from that, it looks like Qt > works out-of-the-box, at least on Windows XP, 32 bits. > > Which also means that to investigate Richard Jackson's problem, we > need to move to a 64-bits Windows machine. > > Regards, > > Arjen > |
From: Hazen B. <hba...@ma...> - 2011-06-03 15:45:07
|
Well at least I can now confirm your bad result, so now maybe Arjen can too? I'm running 32 bit Windows XP (in VirtualBox on a linux machine). Failure with CMake 2.8.4, Qt 4.6.0, PLplot 5.9.6 I set path to: path=c:\qt\2009.05\qt\bin;c:\qt\2009.05\mingw\bin; Also I have: Success with Cmake 2.6.4, Qt 4.5.3, PLplot 5.9.6 Failure with CMake 2.6.4, Qt 4.6.0, PLplot 5.9.6 Failure with CMake 2.8.4, Qt 4.6.0, PLplot-SVN Failure with CMake 2.8.4, Qt 4.7.0, PLplot-SVN So it looks like an issue with more recent versions of Qt? Except that Arjen did not have any trouble with the most recent version? I can try the most recent version, but unfortunately I don't currently have enough space on my VM hard drive to install it. -Hazen On 06/03/2011 02:36 AM, Richard Jackson wrote: > Hi Hazem, Arjen, Alan > > Encouraged by your success I tried again to get plplot installed but I still > cannot get past the problem with test-drv-info terminating improperly. > > I tried to use the same configuration as Hazem reported success with last > week. > > On an old (but fully updated) 32 bit Windows XP machine I installed > ftp://ftp.qt.nokia.com/qtsdk/qt-sdk-win-opensource-2009.05.exe from > ftp://ftp.qt.nokia.com/qtsdk/ and verified that it is Qt v4.6.0. > > I installed cmake 2.8.4 from > http://www.cmake.org/cmake/resources/software.html > > I added C:\Qt\2009.05\mingw\bin;C:\Qt\2009.05\qt\bin to my PATH variable to > use the included copy of MinGW and to let Cmake find to Qt installation. > > I downloaded Plplot 5.9.6, made a build directory and from within it ran > cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install .. > > followed by > > mingw32-make > > and I get the test-drv-info qt error. > > I tried using the latest version of MinGW by downloading > mingw-get-inst-20110530.exe from > http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mi > ngw-get-inst/ and installing to C:\MinGW. > > I changed my PATH variable to point to that instead of the one provided with > Qt, but I still got the same error. > > I wondered whether the problem was to do with latest Windows XP updates from > Microsoft so using VirtualBox I made a new virtual XP machine and installed > XP SP2 into it and disabled all updating. Then on this clean machine I > repeated the process above but I still got the same error. > > So, my question is, how is my configuration different from yours? You > mentioned using cmake 2.8, but that does not seem to be available on the > cmake website, there is only versions 2.8.4 or 2.6.4 available. You also > mentioned MinGW 5.1.4, but I can't find anywhere which tells me exactly > which version it is which is included with the Qt SDK, or which the current > installer downloads. If you can tell me where to find the versions you used > I will try them. > > I also ran the cmake with output redirected to the attached file cmake.txt, > some of the output still appeared on the screen and I pasted that into the > attached file cmakescreen.txt. Maybe it helps? > > Thanks very much everyone for your help and interest > > Regards > Richard > > > > -----Original Message----- > From: Arjen Markus [mailto:arj...@de...] > Sent: 01 June 2011 07:34 > To: Hazen Babcock > Cc: plp...@li... > Subject: Re: [Plplot-devel] Instructing CMake to find Qt4 ... > > Hi Hazen, > > On Tue, 31 May 2011 12:25:39 -0400 > Hazen Babcock<hba...@ma...> wrote: >> >> Hi Arjen, >> >> That was also my experience on 32 bit windows. >> >> Do you have access to a 64-bit windows machine? >> > > yes, but it doesn't currently hav all the development > bits and pieces installed, so that will require some > extra work. But it ought to be worth the effort. > > 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. > > > > > > ---------------------------------------------------------------------------- > -- > Simplify data backup and recovery for your virtual environment with vRanger. > > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2011-06-03 18:27:28
|
On 2011-06-03 11:44-0400 Hazen Babcock wrote: > > Well at least I can now confirm your bad result, so now maybe Arjen can > too? I'm running 32 bit Windows XP (in VirtualBox on a linux machine). > > Failure with CMake 2.8.4, Qt 4.6.0, PLplot 5.9.6 > > I set path to: > path=c:\qt\2009.05\qt\bin;c:\qt\2009.05\mingw\bin; > > Also I have: > Success with Cmake 2.6.4, Qt 4.5.3, PLplot 5.9.6 > Failure with CMake 2.6.4, Qt 4.6.0, PLplot 5.9.6 > Failure with CMake 2.8.4, Qt 4.6.0, PLplot-SVN > Failure with CMake 2.8.4, Qt 4.7.0, PLplot-SVN > > So it looks like an issue with more recent versions of Qt? Except that > Arjen did not have any trouble with the most recent version? I can try > the most recent version, but unfortunately I don't currently have enough > space on my VM hard drive to install it. Hi Hazen: That is excellent news that you have managed to confirm the issue. Could you remove some of those failures (as needed to give you the space) and try Cmake 2.8.4, Qt 4.5.3, PLplot 5.9.6 and Cmake 2.8.4, Qt 4.5.3, PLplot-SVN? If both of those succeed it gives us a lot more confidence that it is the Qt version alone that is the source of the Windows difficulty and not anything to do with CMake version or PLplot version. Where exactly (URL's please) are you getting your various Qt SDK versions for Windows? I would like to try some of these experiments (using the MinGW version inside the Qt SDK) myself under wine. I plan to stick with CMake-2.8.4 (since any version of CMake before 2.8.3 does not work under wine due to a wine-specific issue) and PLplot-SVN and simply vary the Qt version alone. It is because of my planned wine tests with CMake-2.8.4 and PLplot-SVN that I am interested in your results for those with Qt 4.5.3. 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: Hazen B. <hba...@ma...> - 2011-06-03 23:05:57
|
On 06/03/2011 02:27 PM, Alan W. Irwin wrote: > > Hi Hazen: > > That is excellent news that you have managed to confirm the issue. > > Could you remove some of those failures (as needed to give you the > space) and try > > Cmake 2.8.4, Qt 4.5.3, PLplot 5.9.6 > > and > > Cmake 2.8.4, Qt 4.5.3, PLplot-SVN? These both work. > If both of those succeed it gives us a lot more confidence that it is the > Qt version alone that is the source of the Windows difficulty and not > anything to do with CMake version or PLplot version. It looks like something has changed with Qt, but I'm pretty sure Arjen used the latest version of Qt (4.7.3) and did not see this error, so I think we have to wait for his thoughts. > Where exactly (URL's please) are you getting your various Qt SDK > versions for Windows? I would like to try some of these experiments > (using the MinGW version inside the Qt SDK) myself under wine. I plan > to stick with CMake-2.8.4 (since any version of CMake before 2.8.3 > does not work under wine due to a wine-specific issue) and PLplot-SVN > and simply vary the Qt version alone. It is because of my planned You can find the Qt SDK's here (thanks to Richard for the link): ftp://ftp.qt.nokia.com/qtsdk/ 2009.04 -> Qt 4.5.3 2009.05 -> Qt 4.6.0 2010.05 -> Qt 4.7.0 -Hazen |
From: Alan W. I. <ir...@be...> - 2011-06-04 02:50:44
|
On 2011-06-03 19:05-0400 Hazen Babcock wrote: > On 06/03/2011 02:27 PM, Alan W. Irwin wrote: >> >> Hi Hazen: >> >> That is excellent news that you have managed to confirm the issue. >> >> Could you remove some of those failures (as needed to give you the >> space) and try >> >> Cmake 2.8.4, Qt 4.5.3, PLplot 5.9.6 >> >> and >> >> Cmake 2.8.4, Qt 4.5.3, PLplot-SVN? > > These both work. > >> If both of those succeed it gives us a lot more confidence that it is the >> Qt version alone that is the source of the Windows difficulty and not >> anything to do with CMake version or PLplot version. > > It looks like something has changed with Qt, but I'm pretty sure Arjen used > the latest version of Qt (4.7.3) and did not see this error, so I think we > have to wait for his thoughts. > >> Where exactly (URL's please) are you getting your various Qt SDK >> versions for Windows? I would like to try some of these experiments >> (using the MinGW version inside the Qt SDK) myself under wine. I plan >> to stick with CMake-2.8.4 (since any version of CMake before 2.8.3 >> does not work under wine due to a wine-specific issue) and PLplot-SVN >> and simply vary the Qt version alone. It is because of my planned > > You can find the Qt SDK's here (thanks to Richard for the link): > ftp://ftp.qt.nokia.com/qtsdk/ > > 2009.04 -> Qt 4.5.3 > 2009.05 -> Qt 4.6.0 > 2010.05 -> Qt 4.7.0 Hi Hazen: Thanks for all of the information I requested. It is strange that the ftp site stops with 4.7.0. I suggest Richard and you try http://qt.nokia.com/downloads/ where 4.7.3 is available for all platforms including Windows. For what it is worth, 4.6.3 works fine here under Linux. So assuming Arjen confirms 4.7.3 works on Windows (and you and Richard do as well and I do the same under wine) maybe the issue is ".0" trouble (bad initial releases in each 4.x series) for Nokia Qt releases? If 4.7.3 works for all of you (and under wine for me), then we are done (other than documentation of the Qt version problems on our wiki), but just in case not, or if you want to explore the problem further, it appears the latest version of 4.6.x is available at the above ftp site. My guess is that will be 2010.04, but if not, it is highly likely it is one of 2010.0[1-3] which are also available at the ftp site. I plan to test at least Qt 4.5.3 and Qt-4.7.3 under wine to see whether I can replicate everyone else's proprietary Windows results for those Qt versions. 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-06-04 08:35:50
|
Hi all, On 2011-06-03 11:44-0400 Hazen Babcock wrote: > Also I have: > Success with Cmake 2.6.4, Qt 4.5.3, Plplot 5.9.6 > Failure with CMake 2.6.4, Qt 4.6.0, Plplot 5.9.6 So I thought I would try Qt 4.5.3 or earlier Looking at http://en.wikipedia.org/wiki/Qt_%28framework%29 I saw that Qt 4.5 was released on March 3rd 2009 and that Qt 4.6 was released on 1st December 2009 so I downloaded qt-sdk-win-opensource-2009.03.1.exe dated 25/06/2009 from ftp://ftp.qt.nokia.com/qtsdk/ . After downloading it I saw that it was Qt 4.5.2. I installed it on my Virtual 32 bit Windows XP SP2 machine and Plplot built OK with the included MinGW, Cmake 2.8.4 and Plplot 5.9.6 I installed it on my 64 bit Windows 7 machine and Plplot built OK with the included MinGW, Cmake 2.8.4 and Plplot 5.9.6 On the Windows 7 machine I then tried the same Qt 4.5.2 and included MinGW, Cmake 2.8.4, Plplot 5.9.7 and that built OK On the Windows 7 machine I then tried the same Qt 4.5.2, Cmake 2.8.4, Plplot 5.9.7 with the current release MinGW and I got the test-drv-info qt abnormal termination error. Next I tried Qt 4.5.3 (Qt SDK 2009.04) and that builds OK with its own MinGW. Just to be sure I tried Qt 4.6.0 (SDK 2009.05) again with its own MinGW and it fails as before Then I had the idea to try Qt 4.6.0 with the MinGW from Qt 4.5.3 and it builds OK now. So then I again tried the latest Qt version 4.7.3 with the MinGW from Qt 4.5.3 and Plplot 5.9.7 builds OK. Just to be sure I tried the included and latest versions of MinGW with Qt 4.7.3 and Plplot will not build. So I went back to Qt 4.7.3 and the MinGW from Qt 4.5.3. I again successfully built Plplot 5.9.7 and then did a mingw32-make install which seemed OK. I couldn't figure out how to make the examples - I think it needs paths configuring correctly in MSYS? - but I put this to one side for a while and tried building a simple non Plplot Qt example in Netbeans using this toolset and I got lots of compiler errors so I don't think its going to work. I double checked and it still compiled OK with the latest MinGW. So then I went back to Qt 4.5.3 with its own MinGW, it builds and installs OK and I now can build and run my simple Qt application in Netbeans. Next I tried including qt.h from Plplot and I am now getting multiple errors. They are to do with finding include files but I haven't figured them out yet and I have run out of time for today so I will post this email now. I'm not sure when I will be able to come back to it, I hope to find some time next week. Regards Richard -----Original Message----- From: Alan W. Irwin [mailto:ir...@be...] Sent: 03 June 2011 19:27 To: Hazen Babcock Cc: Richard Jackson; plp...@li... Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows On 2011-06-03 11:44-0400 Hazen Babcock wrote: > > Well at least I can now confirm your bad result, so now maybe Arjen can > too? I'm running 32 bit Windows XP (in VirtualBox on a linux machine). > > Failure with CMake 2.8.4, Qt 4.6.0, PLplot 5.9.6 > > I set path to: > path=c:\qt\2009.05\qt\bin;c:\qt\2009.05\mingw\bin; > > Also I have: > Success with Cmake 2.6.4, Qt 4.5.3, PLplot 5.9.6 > Failure with CMake 2.6.4, Qt 4.6.0, PLplot 5.9.6 > Failure with CMake 2.8.4, Qt 4.6.0, PLplot-SVN > Failure with CMake 2.8.4, Qt 4.7.0, PLplot-SVN > > So it looks like an issue with more recent versions of Qt? Except that > Arjen did not have any trouble with the most recent version? I can try > the most recent version, but unfortunately I don't currently have enough > space on my VM hard drive to install it. Hi Hazen: That is excellent news that you have managed to confirm the issue. Could you remove some of those failures (as needed to give you the space) and try Cmake 2.8.4, Qt 4.5.3, PLplot 5.9.6 and Cmake 2.8.4, Qt 4.5.3, PLplot-SVN? If both of those succeed it gives us a lot more confidence that it is the Qt version alone that is the source of the Windows difficulty and not anything to do with CMake version or PLplot version. Where exactly (URL's please) are you getting your various Qt SDK versions for Windows? I would like to try some of these experiments (using the MinGW version inside the Qt SDK) myself under wine. I plan to stick with CMake-2.8.4 (since any version of CMake before 2.8.3 does not work under wine due to a wine-specific issue) and PLplot-SVN and simply vary the Qt version alone. It is because of my planned wine tests with CMake-2.8.4 and PLplot-SVN that I am interested in your results for those with Qt 4.5.3. 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-06-04 19:26:33
|
On 2011-06-04 09:35+0100 Richard Jackson wrote: > Hi all, > > On 2011-06-03 11:44-0400 Hazen Babcock wrote: >> Also I have: >> Success with Cmake 2.6.4, Qt 4.5.3, Plplot 5.9.6 >> Failure with CMake 2.6.4, Qt 4.6.0, Plplot 5.9.6 > > So I thought I would try Qt 4.5.3 or earlier > Looking at http://en.wikipedia.org/wiki/Qt_%28framework%29 I saw that Qt 4.5 > was released on March 3rd 2009 and that Qt 4.6 was released on 1st December > 2009 so I downloaded qt-sdk-win-opensource-2009.03.1.exe dated 25/06/2009 > from ftp://ftp.qt.nokia.com/qtsdk/ . After downloading it I saw that it was > Qt 4.5.2. > > I installed it on my Virtual 32 bit Windows XP SP2 machine and Plplot built > OK with the included MinGW, Cmake 2.8.4 and Plplot 5.9.6 > > I installed it on my 64 bit Windows 7 machine and Plplot built OK with the > included MinGW, Cmake 2.8.4 and Plplot 5.9.6 > > On the Windows 7 machine I then tried the same Qt 4.5.2 and included MinGW, > Cmake 2.8.4, Plplot 5.9.7 and that built OK > > On the Windows 7 machine I then tried the same Qt 4.5.2, Cmake 2.8.4, Plplot > 5.9.7 with the current release MinGW and I got the test-drv-info qt abnormal > termination error. > > Next I tried Qt 4.5.3 (Qt SDK 2009.04) and that builds OK with its own > MinGW. > > Just to be sure I tried Qt 4.6.0 (SDK 2009.05) again with its own MinGW and > it fails as before > > Then I had the idea to try Qt 4.6.0 with the MinGW from Qt 4.5.3 and it > builds OK now. > > So then I again tried the latest Qt version 4.7.3 with the MinGW from Qt > 4.5.3 and Plplot 5.9.7 builds OK. > > Just to be sure I tried the included and latest versions of MinGW with Qt > 4.7.3 and Plplot will not build. > > So I went back to Qt 4.7.3 and the MinGW from Qt 4.5.3. I again successfully > built Plplot 5.9.7 and then did a mingw32-make install which seemed OK. > > I couldn't figure out how to make the examples - I think it needs paths > configuring correctly in MSYS? - but I put this to one side for a while and > tried building a simple non Plplot Qt example in Netbeans using this toolset > and I got lots > of compiler errors so I don't think its going to work. I double checked and > it still compiled OK with the latest MinGW. > > So then I went back to Qt 4.5.3 with its own MinGW, it builds and installs > OK and I now can build and run my simple Qt application in Netbeans. Next I > tried including qt.h from Plplot and I am now getting multiple errors. They > are to do with finding include files but I haven't figured them out yet and > I have run out of time for today so I will post this email now. > > I'm not sure when I will be able to come back to it, I hope to find some > time next week. Hi Richard: Thanks very much for all your efforts to test various MinGW and Qt version combinations. It sounds like most of the issues you have run into concern the MinGW version that comes with versions of Qt after 4.5.3. I will see (a) if I can replicate your test results on wine for some of those version combinations and (b) where there is a failure try to discover what the issue is. The later versions of MinGW work well for me (under wine) for anything not having to do with our qt device driver which is why I suspect the qt troubles may have to do with some linking issue. I hope to investigate that hypothesis further with ldd under wine. (Apparently, no ldd is available under MinGW/MSYS, but cywin does have that very useful utility which identifies exact locations of the dll's that are used and also lets you know of any undefined symbols are left for run-time linking.) Unless and until we can find a fix for later versions of MinGW and Qt, I am very glad to hear that the combination of MinGW from Qt 4.5.3 and Qt 4.5.3 builds for you. I would stick with that combination for now (since I doubt that the 4.5.3 MinGW version that passed the simple build test with Qt 4.7.3 will pass more extensive testing with Qt 4.7.3). In the past here is how I have tested PLplot under wine. Put the dll subdirectory of the top-level build directory (where all the build-tree dll's are automatically collected for the Windows platform case) on your PATH, put MSYS _last_ on your PATH, use the "MSYS Makefiles" cmake generator, and use the -DBUILD_TEST=ON option for cmake. Our test system requires a modern bash which is why I suggested putting MSYS (which supplies a modern bash for windows) on your PATH. The "MSYS Makefiles" cmake generator enables cmake to generate make files that also depend on the msys version of bash as well as other msys applications. Then run make VERBOSE=1 test_noninteractive >& make_test_noninteractive.out make VERBOSE=1 test_interactive >& make_test_interactive.out The former tests essentially all non-interactive devices (including the qt ones). The latter will display lots of interactive results on your desktop (including the qt ones). For the test_interactive target, we are most interested in any errors showing up in make_test_interactive.out so our test systems uses the -np PLplot option to remove the pause between pages for most examples so you don't have to interact with them. However, that option does not yet work for all test examples so you might have to do some clicking (and sometimes just hitting the enter key) to get through a subset of the interactive examples. There is one caveat to the above for the present case. I am a bit concerned about how a modern MSYS will interact with the older MinGW versions you tend to get with Qt. However, I used objdump -p (I don't have access to the Cygwin version of ldd yet) to show that bash.exe supplied by MSYS has no MinGW dll dependencies. So I think the above MSYS-dependent steps will work for you even when you are using a Qt version of MinGW. Assuming the above tests work well, then the VERBOSE option tells you all the compile and link options that you need to get any application to work with PLplot. Thanks again for all your testing help, and in the weeks ahead I hope one of the PLplot developers with access to Windows (maybe even me with wine) can come up with a solution for MinGW and Qt versions later than those associated with Qt 4.5.3. 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-06-06 07:27:30
|
Hi Alan, (back after a long weekend) See my comments below. On 2011-06-04 21:26, Alan W. Irwin wrote: ... > > Unless and until we can find a fix for later versions of MinGW and Qt, > I am very glad to hear that the combination of MinGW from Qt 4.5.3 and > Qt 4.5.3 builds for you. I would stick with that combination for now > (since I doubt > that the 4.5.3 MinGW version that passed the simple build test with > Qt 4.7.3 will pass more extensive testing with Qt 4.7.3). > When I built PLplot with Qt support I used the version of Qt that is installed via an executable "Qt_SDK_Win_online_v1_1_1_en.exe. This apparently downloads the stuff that is required on the fly. The installation on my machine has version 4.7.3. To build PLplot I used the following path to Qt: c:\QtSDK\Desktop\Qt\4.7.3\mingw\bin From the build files produced by CMake I do not see much that comes from that directory other than Qt libraries and include files (and utilities like qmake). So I wonder why the MinGW version is important ... Regards, Arjen > In the past here is how I have tested PLplot under wine. > > Put the dll subdirectory of the top-level build directory (where all > the build-tree dll's are automatically collected for the Windows > platform case) on your PATH, put MSYS _last_ on your PATH, use the > "MSYS Makefiles" cmake generator, and use the -DBUILD_TEST=ON option > for cmake. Our test system requires a modern bash which is > why I suggested putting MSYS (which supplies a modern bash for > windows) on your PATH. The "MSYS Makefiles" cmake generator enables > cmake to generate make files that also depend on the msys version of > bash as well as other msys applications. > > Then run > > make VERBOSE=1 test_noninteractive >& make_test_noninteractive.out > make VERBOSE=1 test_interactive >& make_test_interactive.out > > The former tests essentially all non-interactive devices (including the > qt ones). The latter will display lots of interactive results on your > desktop > (including the qt ones). > > For the test_interactive target, we are most interested in any errors > showing up in make_test_interactive.out so our test systems uses the > -np PLplot option to remove the pause between pages for most examples > so you don't have to interact with them. However, that option does > not yet work for all test examples so you might have to do some > clicking (and sometimes just hitting the enter key) to get through a > subset of the interactive examples. > > There is one caveat to the above for the present case. I am a bit > concerned about how a modern MSYS will interact with the older MinGW > versions you tend to get with Qt. However, I used objdump -p (I don't > have access to the Cygwin version of ldd yet) to show that bash.exe > supplied by MSYS has no MinGW dll dependencies. So I think the above > MSYS-dependent steps will work for you even when you are using a Qt > version of MinGW. > > Assuming the above tests work well, then the VERBOSE option tells you > all the compile and link options that you need to get any application > to work with PLplot. > > Thanks again for all your testing help, and in the weeks ahead I hope > one of the PLplot developers with access to Windows (maybe even me > with wine) can come up with a solution for MinGW and Qt versions later > than those associated with Qt 4.5.3. > > 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. |
From: Richard J. <rrj...@go...> - 2011-06-06 09:36:47
|
Hi Arjen, I started with Qt_SDK_Win_online_v1_1_1_en.exe which downloaded Qt 4.7.3 and I could not build Plplot with it. I tried on both Windows 7 64 bit and XP 32 bit. So what can be the difference between your setup and mine? Could you post a printout from dependency walker of your qt.dll, so that we can compare it with mine? What is your full system path, is there anything else included? What version of MinGW are you using - the version included with Qt, the latest download or some other version? If you are using a different version maybe you could try using the version from c:\QtSDK\mingw\bin by changing your path and checking if that works for you. I'm away on a business trip this week so I don't have access to my old XP machine, but I will download Qt 4.7.3 onto my virtual XP machine and try again. It would be really good to crack this Thanks & Regards Richard -----Original Message----- From: Arjen Markus [mailto:arj...@de...] Sent: 06 June 2011 08:27 To: Alan W. Irwin Cc: Richard Jackson; 'Hazen Babcock'; Werner Smekal; PLplot development list Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows Hi Alan, (back after a long weekend) See my comments below. On 2011-06-04 21:26, Alan W. Irwin wrote: ... > > Unless and until we can find a fix for later versions of MinGW and Qt, > I am very glad to hear that the combination of MinGW from Qt 4.5.3 and > Qt 4.5.3 builds for you. I would stick with that combination for now > (since I doubt > that the 4.5.3 MinGW version that passed the simple build test with > Qt 4.7.3 will pass more extensive testing with Qt 4.7.3). > When I built PLplot with Qt support I used the version of Qt that is installed via an executable "Qt_SDK_Win_online_v1_1_1_en.exe. This apparently downloads the stuff that is required on the fly. The installation on my machine has version 4.7.3. To build PLplot I used the following path to Qt: c:\QtSDK\Desktop\Qt\4.7.3\mingw\bin From the build files produced by CMake I do not see much that comes from that directory other than Qt libraries and include files (and utilities like qmake). So I wonder why the MinGW version is important ... Regards, Arjen |
From: Arjen M. <arj...@de...> - 2011-06-06 10:01:10
|
Hi Richard, I have created a report via Dependency Walker - this is, compressed and all, a file of 1.6 MB, so I will send it to you privately (it does not seem wise to send to all subscribers). Regards, Arjen On 2011-06-06 11:36, Richard Jackson wrote: > Hi Arjen, > > I started with Qt_SDK_Win_online_v1_1_1_en.exe which downloaded Qt 4.7.3 and > I could not build Plplot with it. > I tried on both Windows 7 64 bit and XP 32 bit. > > So what can be the difference between your setup and mine? > Could you post a printout from dependency walker of your qt.dll, so that we > can compare it with mine? > > What is your full system path, is there anything else included? > What version of MinGW are you using - the version included with Qt, the > latest download or some other version? > If you are using a different version maybe you could try using the version > from c:\QtSDK\mingw\bin by changing your path and checking if that works for > you. > > I'm away on a business trip this week so I don't have access to my old XP > machine, but I will download Qt 4.7.3 onto my virtual XP machine and try > again. > > It would be really good to crack this > > Thanks & Regards > Richard > > > -----Original Message----- > From: Arjen Markus [mailto:arj...@de...] > Sent: 06 June 2011 08:27 > To: Alan W. Irwin > Cc: Richard Jackson; 'Hazen Babcock'; Werner Smekal; PLplot development list > Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows > > Hi Alan, > > (back after a long weekend) See my comments below. > > On 2011-06-04 21:26, Alan W. Irwin wrote: > ... >> Unless and until we can find a fix for later versions of MinGW and Qt, >> I am very glad to hear that the combination of MinGW from Qt 4.5.3 and >> Qt 4.5.3 builds for you. I would stick with that combination for now >> (since I doubt >> that the 4.5.3 MinGW version that passed the simple build test with >> Qt 4.7.3 will pass more extensive testing with Qt 4.7.3). >> > > When I built PLplot with Qt support I used the version of Qt that > is installed via an executable "Qt_SDK_Win_online_v1_1_1_en.exe. > This apparently downloads the stuff that is required on the fly. > The installation on my machine has version 4.7.3. > > To build PLplot I used the following path to Qt: > c:\QtSDK\Desktop\Qt\4.7.3\mingw\bin > > From the build files produced by CMake I do not see much that comes from > that directory other than Qt libraries and include files (and utilities > like qmake). So I wonder why the MinGW version is important ... > > 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-06-06 11:42:20
|
Hi Alan, I thought I would have a go at building the examples as per your instructions below, but I'm confused as to exactly what you mean by the cmake instructions. Anyway, I started with a new build directory and ran cmake -G "MinGW Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. It ran through and compiled all the C examples but failed on the C++ ones as usleep() was undefined. I copied the compiled C examples and then reran the make without the -DBUILD_TEST=ON and installed plplot OK. Then I tried running the examples. They all list all 18 drivers but will not load any of them. I tried again adding C:\msys\1.0\bin to my PATH and running cmake -G "MSYS Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. but it fails in the same way. I'll have a look at Arjen's DLL dump tonight, but at first sight it looks like he has a different gcc compiler, its showing d:\gcc4.6\bin\ in his PATH. gcc -v reports version 3.4.5 on my system for the MinGW included with Qt 4.5.3 and its reporting version 4.5.2 for the latest MinGW download. The MSYS gcc version is also 4.5.2. Regards Richard -----Original Message----- From: Alan W. Irwin [mailto:ir...@be...] Sent: 04 June 2011 20:26 In the past here is how I have tested PLplot under wine. Put the dll subdirectory of the top-level build directory (where all the build-tree dll's are automatically collected for the Windows platform case) on your PATH, put MSYS _last_ on your PATH, use the "MSYS Makefiles" cmake generator, and use the -DBUILD_TEST=ON option for cmake. Our test system requires a modern bash which is why I suggested putting MSYS (which supplies a modern bash for windows) on your PATH. The "MSYS Makefiles" cmake generator enables cmake to generate make files that also depend on the msys version of bash as well as other msys applications. Then run make VERBOSE=1 test_noninteractive >& make_test_noninteractive.out make VERBOSE=1 test_interactive >& make_test_interactive.out The former tests essentially all non-interactive devices (including the qt ones). The latter will display lots of interactive results on your desktop (including the qt ones). For the test_interactive target, we are most interested in any errors showing up in make_test_interactive.out so our test systems uses the -np PLplot option to remove the pause between pages for most examples so you don't have to interact with them. However, that option does not yet work for all test examples so you might have to do some clicking (and sometimes just hitting the enter key) to get through a subset of the interactive examples. There is one caveat to the above for the present case. I am a bit concerned about how a modern MSYS will interact with the older MinGW versions you tend to get with Qt. However, I used objdump -p (I don't have access to the Cygwin version of ldd yet) to show that bash.exe supplied by MSYS has no MinGW dll dependencies. So I think the above MSYS-dependent steps will work for you even when you are using a Qt version of MinGW. Assuming the above tests work well, then the VERBOSE option tells you all the compile and link options that you need to get any application to work with PLplot. |
From: Alan W. I. <ir...@be...> - 2011-06-06 16:39:27
|
On 2011-06-06 12:42+0100 Richard Jackson wrote: > Hi Alan, > > I thought I would have a go at building the examples as per your > instructions below, but I'm confused as to exactly what you mean by the > cmake instructions. I assume you meant make (as opposed to cmake) instructions. Below, I will try to make those clearer. > Anyway, I started with a new build directory and ran > cmake -G "MinGW Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. > It ran through and compiled all the C examples but failed on the C++ ones as > usleep() was undefined. I copied the compiled C examples and then reran the > make without the -DBUILD_TEST=ON and installed plplot OK. > Then I tried running the examples. They all list all 18 drivers but will not > load any of them. You are obviously aware of this already, but just to clarify for others, cmake does not build anything. Instead, it prepares your choice of backend tool to do the actual build. That tool choice is done with the cmake back-end generator chosen with the cmake -G option. For example, -G "MinGW Makefiles" uses a generator that prepares Makefiles for the MinGW version of make and MinGW compilers. That generator only works if sh.exe from MSYS is not on the PATH. (You can arrange that by removing/renaming sh.exe or by removing MSYS from your PATH altogether.) In contrast, -G "MSYS Makefiles" chooses a generator that prepares a very different set of Makefiles for the MSYS version of make with both MinGW (for the compilers) and MSYS on the PATH. I have read your further posts today, and it appears you have finally had success with Qt-4.7.3 for a special version of the latest MinGW compiler, but so far your testing of the result has been limited to running a few of the examples by hand using the results from the "MinGW Makefiles" generator. For the next step I suggest you install MSYS on your platform (if that is not available already) and try using the "MSYS Makefiles" cmake generator. That is the generator I have had succes with on wine. Because MSYS will be on your PATH, that automatically makes bash.exe from MSYS available. (Another possibility for bash.exe is the winbash package. We have used that in the past for Windows tests, but it is a very old and limited version of bash which is no longer maintained and which does not work for all components of our testing system because of that limited functionality. Therefore, I can no longer recommend winbash unless there is some strong reason why you do not want to install MSYS on your windows platform.) bash.exe is a prerequisite for our test system and should make it possible for you to run the test_noninteractive and test_interactive make targets as recommended below. (Note, these targets will not be available unless bash.exe is on your PATH so that may have been the source of your previous difficulty with these tests.) These targets run _all_ noninteractive and interactive examples in the build tree for a fairly comprehensive run-time check of every component of PLplot that you are able to build. Warning. The plot files that result from running the test_noninteractive target will consume something like 2GB of disk space (until you remove your build tree where the tests are done). Good luck with your further testing of your PLplot build on Windows with a modern Qt. Alan > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: 04 June 2011 20:26 > In the past here is how I have tested PLplot under wine. > > Put the dll subdirectory of the top-level build directory (where all > the build-tree dll's are automatically collected for the Windows > platform case) on your PATH, put MSYS _last_ on your PATH, use the > "MSYS Makefiles" cmake generator, and use the -DBUILD_TEST=ON option > for cmake. Our test system requires a modern bash which is > why I suggested putting MSYS (which supplies a modern bash for > windows) on your PATH. The "MSYS Makefiles" cmake generator enables > cmake to generate make files that also depend on the msys version of > bash as well as other msys applications. > > Then run > > make VERBOSE=1 test_noninteractive >& make_test_noninteractive.out > make VERBOSE=1 test_interactive >& make_test_interactive.out > > The former tests essentially all non-interactive devices (including the > qt ones). The latter will display lots of interactive results on your > desktop > (including the qt ones). > > For the test_interactive target, we are most interested in any errors > showing up in make_test_interactive.out so our test systems uses the > -np PLplot option to remove the pause between pages for most examples > so you don't have to interact with them. However, that option does > not yet work for all test examples so you might have to do some > clicking (and sometimes just hitting the enter key) to get through a > subset of the interactive examples. > > There is one caveat to the above for the present case. I am a bit > concerned about how a modern MSYS will interact with the older MinGW > versions you tend to get with Qt. However, I used objdump -p (I don't > have access to the Cygwin version of ldd yet) to show that bash.exe > supplied by MSYS has no MinGW dll dependencies. So I think the above > MSYS-dependent steps will work for you even when you are using a Qt > version of MinGW. > > Assuming the above tests work well, then the VERBOSE option tells you > all the compile and link options that you need to get any application > to work with PLplot. > __________________________ 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-06-06 12:17:11
|
Hi Richard, for your information, I am using GCC 4.6.0. The output from gcc -v is: Built by Equation Solution <http://www.Equation.com>. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=d:/gcc4.6/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe Target: i686-pc-mingw32 Thread model: win32 gcc version 4.6.0 20110101 (experimental) (GCC) Regards, Arjen On 2011-06-06 13:42, Richard Jackson wrote: > Hi Alan, > > I thought I would have a go at building the examples as per your > instructions below, but I'm confused as to exactly what you mean by the > cmake instructions. > Anyway, I started with a new build directory and ran > cmake -G "MinGW Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. > It ran through and compiled all the C examples but failed on the C++ ones as > usleep() was undefined. I copied the compiled C examples and then reran the > make without the -DBUILD_TEST=ON and installed plplot OK. > Then I tried running the examples. They all list all 18 drivers but will not > load any of them. > > I tried again adding C:\msys\1.0\bin to my PATH and running > cmake -G "MSYS Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. > but it fails in the same way. > > I'll have a look at Arjen's DLL dump tonight, but at first sight it looks > like he has a different gcc compiler, its showing d:\gcc4.6\bin\ in his > PATH. gcc -v reports version 3.4.5 on my system for the MinGW included with > Qt 4.5.3 and its reporting version 4.5.2 for the latest MinGW download. The > MSYS gcc version is also 4.5.2. > > Regards > Richard > > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: 04 June 2011 20:26 > In the past here is how I have tested PLplot under wine. > > Put the dll subdirectory of the top-level build directory (where all > the build-tree dll's are automatically collected for the Windows > platform case) on your PATH, put MSYS _last_ on your PATH, use the > "MSYS Makefiles" cmake generator, and use the -DBUILD_TEST=ON option > for cmake. Our test system requires a modern bash which is > why I suggested putting MSYS (which supplies a modern bash for > windows) on your PATH. The "MSYS Makefiles" cmake generator enables > cmake to generate make files that also depend on the msys version of > bash as well as other msys applications. > > Then run > > make VERBOSE=1 test_noninteractive >& make_test_noninteractive.out > make VERBOSE=1 test_interactive >& make_test_interactive.out > > The former tests essentially all non-interactive devices (including the > qt ones). The latter will display lots of interactive results on your > desktop > (including the qt ones). > > For the test_interactive target, we are most interested in any errors > showing up in make_test_interactive.out so our test systems uses the > -np PLplot option to remove the pause between pages for most examples > so you don't have to interact with them. However, that option does > not yet work for all test examples so you might have to do some > clicking (and sometimes just hitting the enter key) to get through a > subset of the interactive examples. > > There is one caveat to the above for the present case. I am a bit > concerned about how a modern MSYS will interact with the older MinGW > versions you tend to get with Qt. However, I used objdump -p (I don't > have access to the Cygwin version of ldd yet) to show that bash.exe > supplied by MSYS has no MinGW dll dependencies. So I think the above > MSYS-dependent steps will work for you even when you are using a Qt > version of MinGW. > > Assuming the above tests work well, then the VERBOSE option tells you > all the compile and link options that you need to get any application > to work with PLplot. > > 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-06-06 13:37:42
|
SUCCESS!! Whilst waiting for something else, I downloaded gcc 4.6 32 bit from http://www.Equation.com into my virtual XP machine and successfully built PLplot 5.9.7 with Qt 4.7.3. (I had to disable Fortran by renaming the gcc 4.6 Fortran compiler or the make just stopped after completing the Fortran examples) Then I reran the cmake with the -DBUILD_TEST=ON option and reran the mingw32-make and it successfully built all the c & c++ examples. After including the dll folder in my path I can run all the examples with the wingcc driver and the qt_example also runs fine. I will try the 64bit version of gcc 4.6 on my Windows 7 machine next Regards Richard -----Original Message----- From: Arjen Markus [mailto:arj...@de...] Sent: 06 June 2011 13:17 To: Richard Jackson Cc: 'Alan W. Irwin'; 'Hazen Babcock'; 'Werner Smekal'; 'PLplot development list' Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows Hi Richard, for your information, I am using GCC 4.6.0. The output from gcc -v is: Built by Equation Solution <http://www.Equation.com>. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=d:/gcc4.6/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-w rapper.exe Target: i686-pc-mingw32 Thread model: win32 gcc version 4.6.0 20110101 (experimental) (GCC) Regards, Arjen On 2011-06-06 13:42, Richard Jackson wrote: > Hi Alan, > > I thought I would have a go at building the examples as per your > instructions below, but I'm confused as to exactly what you mean by the > cmake instructions. > Anyway, I started with a new build directory and ran > cmake -G "MinGW Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. > It ran through and compiled all the C examples but failed on the C++ ones as > usleep() was undefined. I copied the compiled C examples and then reran the > make without the -DBUILD_TEST=ON and installed plplot OK. > Then I tried running the examples. They all list all 18 drivers but will not > load any of them. > > I tried again adding C:\msys\1.0\bin to my PATH and running > cmake -G "MSYS Makefiles" -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX= .. > but it fails in the same way. > > I'll have a look at Arjen's DLL dump tonight, but at first sight it looks > like he has a different gcc compiler, its showing d:\gcc4.6\bin\ in his > PATH. gcc -v reports version 3.4.5 on my system for the MinGW included with > Qt 4.5.3 and its reporting version 4.5.2 for the latest MinGW download. The > MSYS gcc version is also 4.5.2. > > Regards > Richard > > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: 04 June 2011 20:26 > In the past here is how I have tested PLplot under wine. > > Put the dll subdirectory of the top-level build directory (where all > the build-tree dll's are automatically collected for the Windows > platform case) on your PATH, put MSYS _last_ on your PATH, use the > "MSYS Makefiles" cmake generator, and use the -DBUILD_TEST=ON option > for cmake. Our test system requires a modern bash which is > why I suggested putting MSYS (which supplies a modern bash for > windows) on your PATH. The "MSYS Makefiles" cmake generator enables > cmake to generate make files that also depend on the msys version of > bash as well as other msys applications. > > Then run > > make VERBOSE=1 test_noninteractive >& make_test_noninteractive.out > make VERBOSE=1 test_interactive >& make_test_interactive.out > > The former tests essentially all non-interactive devices (including the > qt ones). The latter will display lots of interactive results on your > desktop > (including the qt ones). > > For the test_interactive target, we are most interested in any errors > showing up in make_test_interactive.out so our test systems uses the > -np PLplot option to remove the pause between pages for most examples > so you don't have to interact with them. However, that option does > not yet work for all test examples so you might have to do some > clicking (and sometimes just hitting the enter key) to get through a > subset of the interactive examples. > > There is one caveat to the above for the present case. I am a bit > concerned about how a modern MSYS will interact with the older MinGW > versions you tend to get with Qt. However, I used objdump -p (I don't > have access to the Cygwin version of ldd yet) to show that bash.exe > supplied by MSYS has no MinGW dll dependencies. So I think the above > MSYS-dependent steps will work for you even when you are using a Qt > version of MinGW. > > Assuming the above tests work well, then the VERBOSE option tells you > all the compile and link options that you need to get any application > to work with PLplot. > > 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: Arjen M. <arj...@de...> - 2011-06-06 13:40:26
|
Hi Richard, On 2011-06-06 15:37, Richard Jackson wrote: > SUCCESS!! > That _is_ good news - so it seems to be a mismatch between the versions of Qt and GCC ... I hope you can proclaim this for 64-bits Windows as well. That leaves us the Fortran problem. I will try and have a look at that this week. Regards, Arjen > Whilst waiting for something else, I downloaded gcc 4.6 32 bit from > http://www.Equation.com into my virtual XP machine and successfully built > PLplot 5.9.7 with Qt 4.7.3. (I had to disable Fortran by renaming the gcc > 4.6 Fortran compiler or the make just stopped after completing the Fortran > examples) > Then I reran the cmake with the -DBUILD_TEST=ON option and reran the > mingw32-make and it successfully built all the c & c++ examples. After > including the dll folder in my path I can run all the examples with the > wingcc driver and the qt_example also runs fine. > > > I will try the 64bit version of gcc 4.6 on my Windows 7 machine next > 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: Arjen M. <arj...@de...> - 2011-06-14 07:37:37
|
Hello all, the problem that occurs with Qt in combination with the Fortran 95 examples is that the linker complains about duplicate symbols. CMake is supposed to add the linker option --Wl,--allow-multiple-definition to the link statement, but for reasons I have not fathomed yet, this does not happen when Qt is mixed in. (One theory I have, but I have not investigated this yet, is that CMake does not include the Windows-GNU-Fortran.cmake file in these circumstances, even though that file is related to CMake 2.6 and not CMake 2.8. Well, that is something to explore further) Regards, Arjen On 2011-06-06 15:40, Arjen Markus wrote: > > That leaves us the Fortran problem. I will try and have a look at > that this week. > 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-06-14 14:25:53
Attachments:
Link.txt
|
Hi all, I installed gcc 4.6 on my 64 bit W7 machine. It built and compiled and ran plplot 5.9.7 examples no problem, including the qt one Then I tried to compile a simple qt program in Netbeans using gcc 4.6, this program does not use Plplot. The link fails with an undefined reference to `_Unwind_Resume' I then tried to compile one of the supplied Qt examples from within Qt creator, it fails with the same error I was concerned that the multiple installs might be having some effect so I created a new clean XP virtual machine. I installed latest MinGW and latest Qt SDK and verified that I can build the Qt supplied examples with the Qt supplied MinGW gcc 4.4.0. I then installed GCC 4.6 and I do get the same error undefined reference to `_Unwind_Resume' when I try to build a Qt example from Qt Creator. I installed Netbeans and got the same error with the empty default Qt application. I installed Cmake 2.8.4 and verified that I can still build Plplot 5.9.7 with gcc 4.6 and can make and run the qt_example OK without any compile errors. I found this comment for the error reported by someone else on the qt forums: You are probably trying to build your application using a different compiler/linker than that which was used to build Qt. Try using the MinGW which is included with the Qt installer (if using pre-compiled binaries of Qt), or try rebuilding Qt from source using the same toolchain which you plan to use to compile your application. See my (probably) related bug report in TDM's GCC/MinGW bug tracker here. But why does it work with the PLplot Qt example? Must be different compile/link options I guess. 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. Found another comment that latest Qt is built with g++ 4.4.0, found 4.4.4 on the equation.com website and tried that. It builds Plplot OK, but I get the same undefined `_Unwind_Resume' with Qt. Double checked that the MinGW included with latest Qt sdk has g++ 4.4.0 and double checked I can build a non plplot Qt application Ok with it, but it still will not build plplot itself, I still get the unexpected termination of test_dyn_drv with qt.dll. 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 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? 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. So, I then downloaded the qt source and tried to build that with gcc 4.4.4, but I got many errors. It seems everything I try just gives more problems. 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. 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 Regards, Richard -----Original Message----- From: Arjen Markus [mailto:arj...@de...] Sent: 06 June 2011 14:40 To: Richard Jackson Cc: 'Alan W. Irwin'; 'Hazen Babcock'; 'Werner Smekal'; 'PLplot development list' Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows Hi Richard, On 2011-06-06 15:37, Richard Jackson wrote: > SUCCESS!! > That _is_ good news - so it seems to be a mismatch between the versions of Qt and GCC ... I hope you can proclaim this for 64-bits Windows as well. That leaves us the Fortran problem. I will try and have a look at that this week. Regards, Arjen > Whilst waiting for something else, I downloaded gcc 4.6 32 bit from > http://www.Equation.com into my virtual XP machine and successfully built > PLplot 5.9.7 with Qt 4.7.3. (I had to disable Fortran by renaming the gcc > 4.6 Fortran compiler or the make just stopped after completing the Fortran > examples) > Then I reran the cmake with the -DBUILD_TEST=ON option and reran the > mingw32-make and it successfully built all the c & c++ examples. After > including the dll folder in my path I can run all the examples with the > wingcc driver and the qt_example also runs fine. > > > I will try the 64bit version of gcc 4.6 on my Windows 7 machine next > 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: Alan W. I. <ir...@be...> - 2011-06-14 17:02:40
Attachments:
Link.txt
|
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 __________________________ |
From: Richard J. <rrj...@go...> - 2011-06-17 10:59:37
|
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...@be...] 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-06-17 11:16:54
|
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...@be...] > 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. |
From: Richard J. <rrj...@go...> - 2011-06-17 11:21:14
|
Arjen Thanks - I will check that! Richard -----Original Message----- From: Arjen Markus [mailto:arj...@de...] Sent: 17 June 2011 12:17 To: Richard Jackson Cc: 'PLplot development list' Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows 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 |