On Thursday, June 23, 2011 10:45:25 am Alan W. Irwin wrote: > On 2011-06-22 22:06-0600 Clinton Stimpson wrote: > > 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. > > Hi Clint: > > I looked further at what CMake does currently about this. Here are > the files in the CMake-2.8.4 source tree that mention QT_NO_DEBUG or > QT_DEBUG > > software@raven> find cmake-2.8.4 -type f -print0 |\ > xargs -0 egrep -l '(QT_DEBUG|QT_NO_DEBUG)' > cmake-2.8.4/Docs/cmake.html > cmake-2.8.4/Docs/cmake-modules.txt > cmake-2.8.4/Docs/cmake-modules.html > cmake-2.8.4/Docs/cmake.txt > cmake-2.8.4/Docs/cmake-gui.docbook > cmake-2.8.4/Docs/cmake-gui.1 > cmake-2.8.4/Docs/cmake.docbook > cmake-2.8.4/Docs/cmake-gui.txt > cmake-2.8.4/Docs/cmakemodules.1 > cmake-2.8.4/Docs/cmake.1 > cmake-2.8.4/Docs/cmake-gui.html > cmake-2.8.4/ChangeLog.txt > cmake-2.8.4/Modules/UseQt4.cmake > cmake-2.8.4/Modules/FindQt3.cmake > cmake-2.8.4/Modules/FindQt4.cmake > > I presume all the Docs ones are generated from FindQt4.cmake and > FindQt3.cmake documentation lines, and we can ignore the > mention in ChangeLog.txt. That just leaves > > cmake-2.8.4/Modules/UseQt4.cmake > cmake-2.8.4/Modules/FindQt3.cmake > cmake-2.8.4/Modules/FindQt4.cmake > > I will concentrate on just the Qt4 case. FindQt4.cmake just documents > QT_NO_DEBUG and QT_DEBUG but takes no action itself. That just leaves > one file, UseQt4.cmake which has only the following lines concerning those > variables. > > SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG) > SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELEASE > QT_NO_DEBUG) SET_PROPERTY(DIRECTORY APPEND PROPERTY > COMPILE_DEFINITIONS_RELWITHDEBINFO QT_NO_DEBUG) SET_PROPERTY(DIRECTORY > APPEND PROPERTY COMPILE_DEFINITIONS_MINSIZEREL QT_NO_DEBUG) > > Shouldn't the general (Qt4) fix for this bug be to add > > SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS QT_NO_DEBUG) > > to the above lines? That fix seems simpler and more flexible than > forcing a default CMAKE_BUILD_TYPE for the MinGW case. >
Yeah, I came to the same conclusion and committed a fix. http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b20 I also made note of that on the thread in the cmake list and in the bug report. I wonder if this will make it into 2.8.5? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
