[Plplot-devel] Instructing CMake to find Qt4 ...

Discussion:

Arjen Markus

2011-05-31 13:39:11 UTC

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.

Hazen Babcock

2011-05-31 14:23:37 UTC

Permalink

Post by Arjen Markus
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

Arjen Markus

2011-05-31 14:30:15 UTC

Permalink

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

Post by Hazen Babcock

Hazen Babcock

2011-05-31 14:32:19 UTC

Permalink

Hi Arjen,

You probably want the one in "Desktop".

-Hazen

Post by Arjen Markus
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

Post by Hazen Babcock

Arjen Markus

2011-05-31 14:36:38 UTC

Permalink

Hi Hazen,

that at least did the trick for CMake, now building PLplot and
its examples ...

Regards,

Arjen

Post by Hazen Babcock
Hi Arjen,
You probably want the one in "Desktop".
-Hazen

Post by Arjen Markus
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

Post by Hazen Babcock

Arjen Markus

2011-05-31 14:44:48 UTC

Permalink

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

Post by Arjen Markus
Hi Hazen,
that at least did the trick for CMake, now building PLplot and
its examples ...
Regards,
Arjen

Post by Hazen Babcock
Hi Arjen,
You probably want the one in "Desktop".
-Hazen

Post by Arjen Markus
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

Post by Hazen Babcock

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
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Hazen Babcock

2011-05-31 16:25:39 UTC

Permalink

Hi Arjen,

That was also my experience on 32 bit windows.

Do you have access to a 64-bit windows machine?

-Hazen

Post by Arjen Markus
Hi Hazen,
- 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

Arjen Markus

2011-06-01 06:33:50 UTC

Permalink

Hi Hazen,

On Tue, 31 May 2011 12:25:39 -0400

Post by Hazen Babcock
Hi Arjen,
That was also my experience on 32 bit windows.
Do you have access to a 64-bit windows machine?

Richard Jackson

2011-06-03 06:36:14 UTC

Permalink

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:***@deltares.nl]
Sent: 01 June 2011 07:34
To: Hazen Babcock
Cc: plplot-***@lists.sourceforge.net
Subject: Re: [Plplot-devel] Instructing CMake to find Qt4 ...

Hi Hazen,

On Tue, 31 May 2011 12:25:39 -0400

Post by Hazen Babcock
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

Hazen Babcock

2011-06-03 15:44:31 UTC

Permalink

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

Post by Richard Jackson
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-----
Sent: 01 June 2011 07:34
To: Hazen Babcock
Subject: Re: [Plplot-devel] Instructing CMake to find Qt4 ...
Hi Hazen,
On Tue, 31 May 2011 12:25:39 -0400

Post by Hazen Babcock
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
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Alan W. Irwin

2011-06-03 18:27:19 UTC

Permalink

Post by Hazen Babcock
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
path=c:\qt\2009.05\qt\bin;c:\qt\2009.05\mingw\bin;
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
__________________________

Hazen Babcock

2011-06-03 23:05:11 UTC

Permalink

Post by Alan W. Irwin
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.

Post by Alan W. Irwin
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.

Post by Alan W. Irwin
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

Alan W. Irwin

2011-06-04 02:50:36 UTC

Permalink

Post by Hazen Babcock

These both work.

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.

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
__________________________

Richard Jackson

2011-06-04 08:35:38 UTC

Permalink

Hi all,

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:***@beluga.phys.uvic.ca]
Sent: 03 June 2011 19:27
To: Hazen Babcock
Cc: Richard Jackson; plplot-***@lists.sourceforge.net
Subject: Re: [Plplot-devel] Installing Plplot with Qt under Windows

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
path=c:\qt\2009.05\qt\bin;c:\qt\2009.05\mingw\bin;
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.

Alan W. Irwin

2011-06-04 19:26:22 UTC

Permalink

Post by Richard Jackson
Hi all,

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
__________________________

Arjen Markus

2011-06-06 07:27:12 UTC

Permalink

Hi Alan,

(back after a long weekend) See my comments below.

On 2011-06-04 21:26, Alan W. Irwin wrote:
...

Post by Alan W. Irwin
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

Richard Jackson

2011-06-06 09:36:37 UTC

Permalink

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:***@deltares.nl]
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:
...

Arjen Markus

2011-06-06 10:00:44 UTC

Permalink

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

Post by Hazen Babcock
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-----
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.
...

Richard Jackson

2011-06-06 11:42:09 UTC

Permalink

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:***@beluga.phys.uvic.ca]
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.

Arjen Markus

2011-06-06 12:16:57 UTC

Permalink

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

Post by Arjen Markus
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-----
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.

Richard Jackson

2011-06-06 13:37:30 UTC

Permalink

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:***@deltares.nl]
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

Arjen Markus

2011-06-06 13:40:18 UTC

Permalink

Hi Richard,

Post by Richard Jackson
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

Post by Richard Jackson
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

Arjen Markus

2011-06-14 07:37:23 UTC

Permalink

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

Post by Arjen Markus
That leaves us the Fortran problem. I will try and have a look at
that this week.

Richard Jackson

2011-06-14 14:25:37 UTC

Permalink

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:***@deltares.nl]
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,

Post by Richard Jackson
SUCCESS!!

Alan W. Irwin

2011-06-14 17:02:30 UTC

Permalink

[...]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
__________________________

Richard Jackson

2011-06-17 10:59:24 UTC

Permalink

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:***@beluga.phys.uvic.ca]
Sent: 14 June 2011 18:03
To: Richard Jackson
Cc: 'Arjen Markus'; 'Hazen Babcock'; 'Werner Smekal'; 'PLplot development
list'
Subject: RE: [Plplot-devel] Installing Plplot with Qt under Windows

[...]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
__________________________

Arjen Markus

2011-06-17 11:16:36 UTC

Permalink

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

Post by Arjen Markus
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.
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
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
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-----
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

[...]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
__________________________

Richard Jackson

2011-06-17 11:21:03 UTC

Permalink

Arjen

Thanks - I will check that!

Richard

-----Original Message-----
From: Arjen Markus [mailto:***@deltares.nl]
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

Alan W. Irwin

2011-06-17 18:30:08 UTC

Permalink

Post by Richard Jackson
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?

What you said reminded me that the Qt set of libraries comes in two
flavours, "release" and "debug". I am not sure anybody here has
actually tried this with PLplot, but from skimming through the CMake
documentation related to Qt4, it appears to me there is full support
for choosing one of those flavours. In particular, I suggest you try
using the -DCMAKE_BUILD_TYPE:STRING=Debug cmake option if you want to
use the debug flavour of Qt libraries for PLplot linking and don't
specify that option (which is what you have doing so far) if you want
to use the release flavour of the Qt libraries for PLplot linking.

N.B. You should use the results of the "make VERBOSE=1" command to see
the differences in linking between those two cases.

Note, if PLplot is linked with the release flavour of Qt (the current
status of your PLplot builds, I believe), then it would be necessary
to link your own application with that flavour of Qt, and similarly if
PLplot is linked with the debug flavour of Qt (using the cmake
-DCMAKE_BUILD_TYPE:STRING=Debug option), then your own application
should be linked the same way. I believe this consistency in Qt
flavour is necessary because different compiler optimizations are used
for the two cases which are likely incompatible with each other. So
there is a lot more involved then whether symbols are stripped or not
for the two cases.

By the way, aside from the QSAS team (which apparently use their own
independent build methods rather than our CMake-based build system),
you are our first user to attempt to use the Qt parts of PLplot within
their own independent Qt application. Thus, we are all learning this
Qt-related CMake-based build system stuff together which is why some
experimentation is needed (e.g., trying the
-DCMAKE_BUILD_TYPE:STRING=Debug cmake option) to figure out how to get
this all to work for your type of use case.

I very much appreciate the patience you have shown in trying out these
various experiments, and I am sure we can resolve all the issues you
have found if we keep persisting.

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
__________________________

Alan W. Irwin

2011-06-23 02:06:11 UTC

Permalink

Post by Alan W. Irwin
What you said reminded me that the Qt set of libraries comes in two
flavours, "release" and "debug". I am not sure anybody here has
actually tried this with PLplot, but from skimming through the CMake
documentation related to Qt4, it appears to me there is full support
for choosing one of those flavours. In particular, I suggest you try
using the -DCMAKE_BUILD_TYPE:STRING=Debug cmake option if you want to
use the debug flavour of Qt libraries for PLplot linking and don't
specify that option (which is what you have doing so far) if you want
to use the release flavour of the Qt libraries for PLplot linking.

Hi Richard:

Are you specifying one of -DCMAKE_BUILD_TYPE:STRING=Debug or
-DCMAKE_BUILD_TYPE:STRING=Release? It appears from the last few
messages in the thread at
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36994/focus=37032
that you have to be specific this way to get good Qt results with
MinGW on Windows. In other words, there appears to be something wrong
with the CMake default in this special case (MinGW and Qt on Windows).

There is a newly created CMake bug report about this issue at
http://public.kitware.com/Bug/view.php?id=12301. But the easy
workaround appears to be to specifically set one of the two choices
above.

As you know, I once got the qt device driver to work on wine, but then
lost it again. I ascribed that failure as being due to incompatible
MinGW versions. But in future wine/MinGW tests I am always going to set
CMAKE_BUILD_TYPE to one of the above to see if that improves
reliability.

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
__________________________

Richard Jackson

2011-06-23 18:11:40 UTC

Permalink

Alan

I rebuilt plplot 5.9.7 with the latest Qt 4.7.3 and its included gcc 4.4.0
using this cmake command:
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_INSTALL_PREFIX= ..

It built Ok, it runs the examples OK, it runs my simple application OK, it
runs my main application OK until I include the my module with threads,
sleeps and third party USB drivers. Then I get lots of compile errors due to
lack of sys/times.h and conflicting definitions between Qt and the third
party software. That's something I will need to sort out separately.

But I can now say that PLplot is OK with Qt under Windows, so long as you
specify -DTEST_DYNDRIVERS=OFF. Without that the test still crashes.

Thanks for all your support

Richard

Post by Richard Jackson
-----Original Message-----
Sent: 23 June 2011 03:06
To: Richard Jackson
Cc: PLplot development list
Subject: RE: [Plplot-devel] Installing Plplot with Qt under Windows

Are you specifying one of -DCMAKE_BUILD_TYPE:STRING=Debug or
-DCMAKE_BUILD_TYPE:STRING=Release? It appears from the last few
messages in the thread at
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36994/f
ocus=37032
that you have to be specific this way to get good Qt results with
MinGW on Windows. In other words, there appears to be something wrong
with the CMake default in this special case (MinGW and Qt on Windows).
There is a newly created CMake bug report about this issue at
http://public.kitware.com/Bug/view.php?id=12301. But the easy
workaround appears to be to specifically set one of the two choices
above.
As you know, I once got the qt device driver to work on wine, but then
lost it again. I ascribed that failure as being due to incompatible
MinGW versions. But in future wine/MinGW tests I am always going to set
CMAKE_BUILD_TYPE to one of the above to see if that improves
reliability.
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
__________________________

Alan W. Irwin

2011-06-23 20:42:37 UTC

Permalink

Post by Richard Jackson
Alan
I rebuilt plplot 5.9.7 with the latest Qt 4.7.3 and its included gcc 4.4.0
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_INSTALL_PREFIX= ..
It built Ok, it runs the examples OK, it runs my simple application OK, it
runs my main application OK [....]

Excellent news indeed.

Post by Richard Jackson
But I can now say that PLplot is OK with Qt under Windows, so long as you
specify -DTEST_DYNDRIVERS=OFF. Without that the test still crashes.

Just a thought, but I wonder if maybe you forgot to put the path for
the dll subdirectory on your PATH _before_ you ran make? If you did
that necessary PATH change afterward before you ran the "x01c -dev
qtwidget" test that would explain the bad result you are seeing with
the simple dynamic load test that is done with -DTEST_DYNDRIVERS=ON
while getting a good result for the more extensive "x01c -dev
qtwidget" test.

Alan W. Irwin

2011-06-25 04:56:55 UTC

Permalink

Post by Alan W. Irwin

Excellent news indeed.

Post by Richard Jackson
But I can now say that PLplot is OK with Qt under Windows, so long as you
specify -DTEST_DYNDRIVERS=OFF. Without that the test still crashes.

Just a thought, but I wonder if maybe you forgot to put the path for
the dll subdirectory on your PATH _before_ you ran make?

Never mind. Forget that thought. You obviously had the dll
subdirectory in your PATH because the test of our xfig driver on your
platform was fine.

So I think two conditions must be met to solve the puzzling issue of
why test-dyn-drv fails to load the qt.so plug-in while essentially the
equivalent qt.so test (and a lot more) succeeds with "x01c -dev
qtwidget" on your platform. These conditions are a developer with
access to Qt on Windows needs to (1) replicate this issue and (2)
diagnose exactly what the trouble is with the Windows run-time test
tools they are aware of.

Of course, until we can find a solution continue to work around the
issue with -DTEST_DYNDRIVERS=OFF.

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
__________________________

Richard Jackson

2011-06-20 10:34:09 UTC

Permalink

Hi Alan,

I tried rebuilding plplot 5.9.7 with the latest Qt 4.7.3 and its included
gcc 4.4.0 using the cmake option -DTEST_DYNDRIVERS=OFF and everything
worked. It also makes and runs the qt_example.cpp ok.

For the record you can't do it all in one go and have the examples built,
you have to do the following sequence:
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DCMAKE_INSTALL_PREFIX= ..
mingw32-make
followed by
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_INSTALL_PREFIX= ..
mingw32-make
which then builds all the c and c++ examples.
Once you have included the dll and drivers folders in your PATH you can run
any of the examples just by clicking on its .exe file.
I tried an install with
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_INSTALL_PREFIX=d:\utils\plplot ..
mingw32-make install
But it put the bin, include, lib and share folders in the root of my D:
drive, so I just moved them manually to where I wanted them. It also puts
the driver DLLs in lib\plplot5.9.7\driversd which is a little counter
intuitive but no real problem.

I then compiled and linked my main qt/plplot application OK, but it will not
run, even in release mode. If I run it from a console window nothing happens
at all, after a short delay I just get a new command prompt. I checked the
.exe with dependency-walker but I can see nothing unusual, all the dlls are
there apart from IESHIMS.DLL which I am sure is not the problem. I also
checked my simple qt/plplot example and that will not run either. I tried
building the debug version and that crashes.

I repeated the whole process building plplot with gcc 4.4.4, with exactly
the same results.

So, the only way I can get a working application is with Qt 4.5.3 (Qt SDK
2009.04) and its included compiler gcc 3.4.5 in Release mode. I am going to
have to return to that and adapt my application to suit. I did this, and
still my simple application does not run! What's different from Friday? I
still have the plplot build from Friday, checked the DLLs against my current
build and they are different sizes. Prepended Friday's dll folder to my path
so they will be used rather than my latest ones and I can now run OK. Double
checked, gcc -v reports version 3.4.5, the qt in my path is 2009.04. Rebuilt
without the install stage and that makes no difference. I wondered if I had
inadvertently left gcc 4.4.4 in my path when I built on Friday. Tried adding
it and rebuilding, but the DLLs are different sizes again, and it doesn't
run.

So, now I am left in the situation that I have a working build of plplot
which runs with Qt 4.5.3 but I don't know how I did it and I can't recreate
it! I must be missing something obvious but I can't think what.

Regards
Richard

-----Original Message-----
From: Alan W. Irwin [mailto:***@beluga.phys.uvic.ca]
Sent: 14 June 2011 18:03
To: Richard Jackson
Cc: 'Arjen Markus'; 'Hazen Babcock'; 'Werner Smekal'; 'PLplot development
list'
Subject: RE: [Plplot-devel] Installing Plplot with Qt under Windows

[...]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,

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
__________________________

Alan W. Irwin

2011-06-20 16:19:12 UTC

Permalink

[...]So, the only way I can get a working application is with Qt 4.5.3 (Qt SDK
2009.04) and its included compiler gcc 3.4.5 in Release mode. I am going to
have to return to that and adapt my application to suit. I did this, and
still my simple application does not run! What's different from Friday? I
still have the plplot build from Friday, checked the DLLs against my current
build and they are different sizes. Prepended Friday's dll folder to my path
so they will be used rather than my latest ones and I can now run OK. Double
checked, gcc -v reports version 3.4.5, the qt in my path is 2009.04. Rebuilt
without the install stage and that makes no difference. I wondered if I had
inadvertently left gcc 4.4.4 in my path when I built on Friday. Tried adding
it and rebuilding, but the DLLs are different sizes again, and it doesn't
run.
So, now I am left in the situation that I have a working build of plplot
which runs with Qt 4.5.3 but I don't know how I did it and I can't recreate
it! I must be missing something obvious but I can't think what.

Because I have begun to test PLplot on Windows (and the wine version
of Windows at that) only recently, I don't understand the details, and
I may even have this wrong, but my understanding is the on Windows
systems, CMake not only searches for system components via the PATH,
but also via the registry. On wine I avoided all registry
complications (I hope) when I installed Qt4 by installing it in a
non-system location. Then I put qmake from that location on my PATH,
and the result worked when I didn't have incompatible compilers.
Anyhow, if you have several Qt versions on your system and one of
those is in the registry, it is possible you are accessing the wrong
version of qmake which then would pull in a Qt version that was
different then the one you wanted. Because of this uncertainty, I
suggest on systems with multiple Qt4 versions installed, you should
always check your cmake output and your "make VERBOSE=1" output for
everything qt related to make sure you are accessing the Qt4 header
and library locations consistent with how you specified the qmake
location with your PATH. I hope this fundamental check of cmake and
make output will help you figure out how to replicate what you had
before.

You also mentioned having to invoke cmake twice when using
-DTEST_DYNDRIVERS=OFF. That doesn't seem right so I will
look into that.

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
__________________________

Richard Jackson

2011-06-22 08:43:37 UTC

Permalink

Hi Alan,

Post by Alan W. Irwin
Because I have begun to test PLplot on Windows (and the wine version
of Windows at that) only recently, I don't understand the details, and
I may even have this wrong, but my understanding is the on Windows
systems, CMake not only searches for system components via the PATH,
but also via the registry

I am completely uninstalling and reinstalling Qt when I change versions so
that I don't believe this is the problem. I double checked in the registry
and the only Qt references I can find are in ...MuiCache and they are all to
Qt 4.7.3 that I currently have installed.

Post by Alan W. Irwin
Please send your captured cmake and "make VERBOSE=1" output to me off
list for the case where you try to do everything in one go starting
with an empty build tree with the anomalous result that the examples
are _not_ built.

I rebuilt plplot 5.9.7 with Qt 4.5.3 (Qt SDK 2009.04) and its included
compiler gcc 3.4.5.
These are the versions that worked OK with my application last Friday.
I did:
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_INSTALL_PREFIX= .. >cmake.txt
I've attached cmake.txt, some of the output came to the screen, I've
attached that as cmake2.txt.

Then I did mingw32-make "VERBOSE=1" >make.txt
I've attached make.txt

Post by Alan W. Irwin
qt_example.cpp may not be a sufficient test. For example, what happens
if you actually try to use one of the dynamic drivers, e.g.,
examples/c/x01c -dev qtwidget

I added the newly created dll folder to my path and x01c -dev qtwidget runs
OK as does qt_example

I checked the DLL sizes and they are different (smaller) from the ones I
created last Friday which worked with Netbeans.

Then I did mingw32-make install > makeinstall.txt, I've attached the output.

So I was wrong when I said on Friday that you can't do it all with just a
single cmake, sorry for the confusion.

I did the Netbeans make again of my simple test application
It still doesn't run, just returns straight to the command prompt without
any error message.

I also did the qt make of the is application, it still doesn't run, qt says
Starting D:\Data\QtProjects\App\release\App.exe...
D:\Data\QtProjects\App\release\App.exe exited with code 1

I've attached the Qt make log.

Post by Alan W. Irwin
If the above use of
one of the qt dynamic devices works with -DTEST_DYNDRIVERS=OFF, then
can you confirm you still get a build-time error (and if so please
identify the device driver that fails) from the simple test of each of
the dynamic devices invoked with -DTEST_DYNDRIVERS=ON? (I am asking
you to repeat this test because you appear to be having difficulty
with replicating your older results.

That will require uninstalling Qt 4.5.3 and installing Qt 4.7.3, once I've
done that I will repeat all the above tests and send results in a separate
email.

Regards
Richard

Alan W. Irwin

2011-06-22 22:09:24 UTC

Permalink

Post by Richard Jackson
I rebuilt plplot 5.9.7 with Qt 4.5.3 (Qt SDK 2009.04) and its included
compiler gcc 3.4.5.
These are the versions that worked OK with my application last Friday.
I added the newly created dll folder to my path and x01c -dev qtwidget runs
OK as does qt_example

That will require uninstalling Qt 4.5.3 and installing Qt 4.7.3, once I've
done that I will repeat all the above tests and send results in a separate
email.

No, please repeat exactly what you did above with plplot 5.9.7 and Qt
4.5.3 but with with -DTEST_DYNDRIVERS=ON. (I know that doesn't help
you with your netbeans issue, but I am trying to discover if the light
testing of the dynamic devices configured by -DTEST_DYNDRIVERS=ON
actually works for you for a system where more extensive testing of
the qtwidget device implied by "x01c -dev qtwidget" actually appears
to be working properly.)

Also, I suggest to help you sort out your replication issues, you do
as much as possible of testing with scripts (if you are running bash)
or batch files. Running a script or batch file reduces a lot of
possibilities for the cause of differences so, for example, if you
notice a difference in results between Friday's and Monday's run of
the identical script it should make it easier to track down the reason
for the difference.

I will have a look later at the build results you attached.

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
__________________________

Richard Jackson

2011-06-22 19:04:49 UTC

Permalink

Hi Alan,

Next instalment...

I rebuilt plplot 5.9.7 with the latest Qt 4.7.3 and its included gcc 4.4.0.
These are the versions that will not run the dynamic driver test and will
not work with my application.
I did:
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_INSTALL_PREFIX= .. >cmake.txt
I've attached cmake.txt.

Then I did mingw32-make "VERBOSE=1" >make.txt
I've attached make.txt

Post by Alan W. Irwin
qt_example.cpp may not be a sufficient test. For example, what happens
if you actually try to use one of the dynamic drivers, e.g.,
examples/c/x01c -dev qtwidget

I added the newly created dll folder to my path and x01c -dev qtwidget runs
OK as does qt_example

I deleted the build hierarchy, created a new build folder and built with the
test of dynamic drivers

cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_INSTALL_PREFIX= .. >cmakedyn.txt
mingw32-make "VERBOSE=1" >makedyn.txt

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
mingw32-make[2]: *** [drivers/test_dyndrivers_dir/qt.rc] Error 3
mingw32-make[1]: *** [drivers/CMakeFiles/test_qt_dyndriver.dir/all] Error 2
mingw32-make: *** [all] Error 2

I've attached cmakedyn.txt and makedyn.txt

I made again without the dynamic driver test and installed it in with
mingw32-make install > makeinstall.txt

I then did the qt make of my simple qt/plplot application, it wouldn't start
the compilation throwing up strange errors so I told qt to make a new empty
application and copied my source files across. I copied across the include
and library paths and then it built but wouldn't run, but then I realised it
was in debug mode. I switched to release mode and now it runs!
For the record I've attached the make log qtmake.txt.

Went to do the same for Netbeans, and I couldn't find the include files,
realised that for qtcreator I was using the old build path to my working
4.5.3 installation. Strange, I can't see an install folder in my new build -
a bit of checking and its putting them in the root of my d: drive. Changed
qtcreator to look there for includes and libraries and rebuilt and it still
runs! I've attached this build log as qtmake1.txt

Set Netbeans with these include and library paths and built my app, this
time it runs! - But after a few clicks it crashes and exits. I've attached
the build log as nbmake.txt. On a quick look its using /usr/bin/make rather
that mingw32-make , must be the msys make.
I've run out of time tonight, will have a closer look at the logs tomorrow

Regards
Richard

Alan W. Irwin

2011-06-20 16:52:40 UTC

Permalink

Post by Arjen Markus
Hi Alan,
I tried rebuilding plplot 5.9.7 with the latest Qt 4.7.3 and its included
gcc 4.4.0 using the cmake option -DTEST_DYNDRIVERS=OFF and everything
worked. It also makes and runs the qt_example.cpp ok.

qt_example.cpp may not be a sufficient test. For example, what happens
if you actually try to use one of the dynamic drivers, e.g.,

examples/c/x01c -dev qtwidget

That example is much nearer what happens for the simple dynamic driver
test invoked by specifying -DTEST_DYNDRIVERS=ON. If the above use of
one of the qt dynamic devices works with -DTEST_DYNDRIVERS=OFF, then
can you confirm you still get a build-time error (and if so please
identify the device driver that fails) from the simple test of each of
the dynamic devices invoked with -DTEST_DYNDRIVERS=ON? (I am asking
you to repeat this test because you appear to be having difficulty
with replicating your older results.)

Post by Arjen Markus
For the record you can't do it all in one go and have the examples built,
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DCMAKE_INSTALL_PREFIX= ..
mingw32-make
followed by
cmake -G "MinGW Makefiles" -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON
-DCMAKE_INSTALL_PREFIX= ..
mingw32-make
which then builds all the c and c++ examples.

Strange. I cannot replicate this issue on my Linux platform.
Starting with an empty build tree, I do just the following:

cmake [...] -DTEST_DYNDRIVERS=OFF -DBUILD_TEST=ON [...] >& cmake.out

make -j4 >& make.out

Both the captured *.out files show no errors. Furthermore,

examples/c/x01c -dev qtwidget

and other such tests of the various C examples work without issues.

Please send your captured cmake and "make VERBOSE=1" output to me off
list for the case where you try to do everything in one go starting
with an empty build tree with the anomalous result that the examples are
_not_ built.

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
__________________________

Alan W. Irwin

2011-06-06 16:39:20 UTC

Permalink

Post by Arjen Markus
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.

Post by Arjen Markus
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

Post by Arjen Markus
-----Original Message-----
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
__________________________