Clint Stimpson was kind enough to explain further on the CMake
developer's list why it is currently necessary to specify
CMAKE_BUILD_TYPE as either Debug or Release with CMake for the
MinGW/Qt4 case. I forward that expanded explanation below.
Richard, I hope when you apply this advice to your PLplot build,
you will find your results are much more reliable.
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
__________________________
---------- Forwarded message ----------
Date: Wed, 22 Jun 2011 22:06:14 -0600
From: Clinton Stimpson <clin...@elemtech.com>
To: CMake Developers <cmake-develop...@cmake.org>
Cc: Alan W. Irwin <ir...@beluga.phys.uvic.ca>
Subject: Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on
MinGW
This issue is with how Qt plugins are compiled. It has come up a couple times
in the past, but this might be the first with MinGW.
When Qt is configured, a build key is generated that is configuration specific
(see qconfig.h).
On Windows, the build key for the debug and release libs are different
(regardless of the compiler used -- although they may only need to really do
it for MSVC because only it has separate debug and release runtimes).
When a user creates a Qt plugin, that build key gets embedded into the plugin
(see build key used in qplugin.h), so it can only be loaded with a compatible
Qt build.
On Windows, the correct debug or release build key needs to be used, and
choosing the correct one is dependent on compiling with -DQT_NO_DEBUG or
-DQT_DEBUG. If neither is defined, qglobal.h automatically sets QT_DEBUG,
which means it is assuming a debug build, even if one links against the release
Qt libs. I wonder if there is a way to patch Qt to make a better assumption.
So anyway, Stephen was having this issue because the build type was not
explicit and Qt assumed debug and CMake assumed Release (by choosing to link
with the release Qt libs), and the plugin was compiled with the wrong build
key, so it wouldn't load at runtime. CMake sets a build type by default for
MSVC compilers, but not MinGW or MSYS. The bug report requests that a default
build type be specified instead of left empty.
Clint
------------------------------------------------------------------------------
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
