View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012444CMakeCMakepublic2011-09-03 06:082016-06-10 14:31
ReporterMichael Kapelko 
Assigned ToBill Hoffman 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
Platformx86OSWindowsOS VersionXP
Product VersionCMake 2.8.4 
Target VersionFixed in Version 
Summary0012444: Starting with CMake 2.8.4 it passes invalid msse flag when compiling with MinGW
Description2.8.3 is the last version that works correctly with Ogre: http://www.ogre3d.org/forums/viewtopic.php?f=2&p=421826 [^]
The problem is that it passes -msse to custom command that invokes windres.exe to compile resources:

src/OgreMain/CMakeLists.txt:
- - - -
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/OgreWin32Resources.rc.obj
      COMMAND ${OGRE_MINGW_RC} -I${CMAKE_CURRENT_SOURCE_DIR}/src/WIN32
                               -i${CMAKE_CURRENT_SOURCE_DIR}/src/WIN32/OgreWin32Resources.rc
                               -o${CMAKE_CURRENT_BINARY_DIR}/OgreWin32Resources.rc.obj
      DEPENDS ${RESOURCE_FILES})
- - - -
Steps To ReproduceJust try to compile Ogre under Windows with CMake >= 2.8.4.
TagsNo tags attached.
Attached Files

 Relationships
related to 0012371closedKitware Robot Resource compilation gets wrong parameters on CB+MingW 
has duplicate 0012871closedBrad King add_definitions adds flags to RC_DEFINES 
related to 0012998closedKitware Robot rc-File support for MinGW: <FLAGS> incompatibilities between GCC and windres 

  Notes
(0027326)
Mathias Gaunard (reporter)
2011-09-04 06:26

Does using VERBATIM fix the issue?
(0027329)
Brad King (manager)
2011-09-05 08:01

Are you sure it is the custom command that ends up with -msse? CMake 2.8.4 added native support for windres:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2f308c8 [^]
(0027499)
Michael Kapelko (reporter)
2011-10-01 02:38

VERBATIM didn't help.
(0027500)
Michael Kapelko (reporter)
2011-10-01 02:42

I've looked at CMake-2.8.5 docs, but it doesn't contain any info on 'windres'. How do I modify the above custom command to employ the auto support for resources?
(0027502)
Brad King (manager)
2011-10-03 08:34

Just add a ".rc" source file to your executable. CMake will generate the call to windres for it just like a call to the C compiler.
(0027551)
Michael Kapelko (reporter)
2011-10-07 10:58

I've done it, and still it puts some -msse flag.

[ 7%] Building RC object OgreMain/CMakeFiles/OgreMain.dir/src/WIN32/OgreWin32Re
sources.rc.obj
cd /d OgreMain && C:\MinGW\bin\windres.exe -O coff -IC:\build\ogre\src\OgreMain
\include -I..\include -IC:\MinGW\include -IC:\MinGW\include\OIS -IC:\build\ogre\
src -IC:\build\ogre\src\OgreMain\include\Threading -IC:\build\ogre\src\OgreMain\
include\WIN32 -IC:\build\ogre\src\OgreMain\src\nedmalloc -IC:\build\ogre\src\Ogr
eMain -msse -DOgreMain_EXPORTS -D_WIN32_WINNT=0x0500 -DOGRE_NONCLIENT_BUILD -
D_MT -D_USRDLL C:\build\ogre\src\OgreMain\src\WIN32\OgreWin32Resources.rc CMakeF
iles\OgreMain.dir\src\WIN32\OgreWin32Resources.rc.obj
C:\MinGW\bin\windres.exe: invalid option -- m
(0028153)
Brandon Van Every (reporter)
2012-01-03 21:10
edited on: 2012-01-05 17:26

Still fails in Ogre MinGW build with CMake 2.8.6. Also fails in 2.8.7. Verified that it builds fine with 2.8.3.

(0028195)
M.S. Babaei (reporter)
2012-01-05 11:30

Yep!! the problem with OGRE3D on windows is still there!!
It just works on <= 2.8.3
(0028236)
Sam Morris (reporter)
2012-01-10 10:42

According to the CMake developers, Ogre is doing the wrong thing here. See http://www.cmake.org/Bug/view.php?id=12871 [^] for information and http://www.ogre3d.org/mantis/view.php?id=492 [^] for the fix.
(0028239)
Brandon Van Every (reporter)
2012-01-10 13:15
edited on: 2012-01-10 13:20

Why does behavior change between 2.8.3 and 2.8.4 then? Ok, because 2.8.4 added support for Windows resource scripts: the options added with -msse are end up in RC_FLAGS, and are hence passed to windres, which doesn't know what to do with them.

(0029235)
David Cole (manager)
2012-04-19 08:50

Unset target version, removed from roadmap.

Feel free to update target version when work is underway for this issue.
(0029253)
Michael Kapelko (reporter)
2012-04-19 11:24

Is there really a need for compile definitions for RC? May be introduce separate RC_COMPILE_FLAGS or smth specifically for RC? It won't conflict then.
(0033034)
Todd Greer (reporter)
2013-05-13 18:52

The documentation for add_definitions specifically states that add_definitions "can be used to add any flags," even though "it was originally intended to add preprocessor definitions." [http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:add_definitions [^]]

Either the documentation needs to be fixed, or people need to stop saying that it shouldn't be used to add flags.

IMHO, the documentation should be considered correct, for two reasons:

1. The documentation has said this since 2.6.0, possibly longer. Much code has relied on that documentation.

2. Setting project-wide flags with CMAKE_CXX_FLAGS is poorly documented and difficult to get right, which is why people want to use add_definitions.

Many people, myself include, have carefully read CMake's documentation and have come to the conclusion that add_definitions is the correct place to set flags that should be used across the project. It is only through stumbling upon various postings and bug reports that one hears any differently.
(0033036)
Michael Kapelko (reporter)
2013-05-14 08:55

Ok. The issue can closed then.
(0033058)
Jan Hudec (reporter)
2013-05-16 09:55
edited on: 2013-08-13 03:24

The problem is that add_definitions is still the only way to define the flags reasonably globally.

With CMAKE_*_FLAGS I have to add them to both C and CXX and COMPILE_FLAGS (from where I could filter out the flags with undocumented CMAKE_RC_FLAG_REGEX) only exists on targets, but is not inherited from directories or global, so with tens of targets is not suitable either.

(0041901)
Kitware Robot (administrator)
2016-06-10 14:28

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2011-09-03 06:08 Michael Kapelko New Issue
2011-09-04 06:26 Mathias Gaunard Note Added: 0027326
2011-09-05 08:01 Brad King Note Added: 0027329
2011-10-01 02:38 Michael Kapelko Note Added: 0027499
2011-10-01 02:42 Michael Kapelko Note Added: 0027500
2011-10-03 08:34 Brad King Note Added: 0027502
2011-10-03 08:35 Brad King Assigned To => Bill Hoffman
2011-10-03 08:35 Brad King Status new => assigned
2011-10-07 10:58 Michael Kapelko Note Added: 0027551
2012-01-03 21:10 Brandon Van Every Note Added: 0028153
2012-01-04 05:23 Brandon Van Every Note Added: 0028155
2012-01-04 05:23 Brandon Van Every Note Deleted: 0028155
2012-01-04 05:23 Brandon Van Every Note Edited: 0028153
2012-01-05 11:30 M.S. Babaei Note Added: 0028195
2012-01-05 13:24 Bill Hoffman Target Version => CMake 2.8.8
2012-01-05 17:26 Brandon Van Every Note Edited: 0028153
2012-01-10 10:42 Sam Morris Note Added: 0028236
2012-01-10 13:15 Brandon Van Every Note Added: 0028239
2012-01-10 13:20 Brandon Van Every Note Edited: 0028239
2012-01-10 13:54 Brad King Relationship added has duplicate 0012871
2012-02-27 08:57 Brad King Relationship added related to 0012998
2012-02-27 08:57 Brad King Relationship added related to 0012371
2012-04-19 08:50 David Cole Note Added: 0029235
2012-04-19 08:50 David Cole Target Version CMake 2.8.8 =>
2012-04-19 11:24 Michael Kapelko Note Added: 0029253
2013-05-13 18:52 Todd Greer Note Added: 0033034
2013-05-14 08:55 Michael Kapelko Note Added: 0033036
2013-05-16 09:55 Jan Hudec Note Added: 0033058
2013-08-13 03:24 Jan Hudec Note Edited: 0033058
2016-06-10 14:28 Kitware Robot Note Added: 0041901
2016-06-10 14:28 Kitware Robot Status assigned => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team