[OGRE-460] Forcing i686 architecture on MinGW

[paroj]

[reporter="Mako_energy", created="Mon, 24 Nov 2014 03:29:25 +0100"]

At around line 150 of the root CMakeLists.txt file in the Ogre 2.0 trunk (I suspect this applies to all other versions of Ogre as well), there is a condition that checks for MinGW and if found would force the CMake architecture to i686 using "-march=i686". This is not a 64-bit architecture and thus will cause any MinGW64 compiler configured to actually build 64-bit libraries to fail.

From doing some research it seems this line for the architecture was added to resolve a linking bug on MinGW a while back. It should stay for 32-bit builds, but shouldn't exist for 64-bit builds. For example, replace:

Unable to find source-code formatter for language: before. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=i686")

with...

Unable to find source-code formatter for language: after. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

  if( CMAKE_SIZEOF_VOID_P EQUAL 8 )
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=athlon64")
  else( CMAKE_SIZEOF_VOID_P EQUAL 8 )
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=i686")
  endif( CMAKE_SIZEOF_VOID_P EQUAL 8 )

This should preserve the previous bugfix while enable compilation on 64-bit MinGW builds.

[paroj]

[author="dark_sylinc", created="Tue, 25 Nov 2014 00:02:33 +0100"]

MinGW is not my thing. Perhaps Philip Allgaier you can see the problem and if it applies to other branches as well (most likely)?

[paroj]

[author="spacegaier", created="Tue, 25 Nov 2014 11:39:20 +0100"]

@Matias Goldberg MinGW isn't mine either and given that it seems to be not Ogre2.0-specific you are off the hock.

@John B I am not sure if the "CMAKE_SIZEOF_VOID_P" approach makes sense here since that would always force 64bit compilation on 64bit machines from my understanding. But someone might still want to build 32bit Ogre despite having a 64bit system.

CMAKE_SIZEOF_VOID_P

Size of a void pointer.
This is set to the size of a pointer on the machine, and is determined by a try compile. If a 64 bit size is found, then the library search path is modified to look for 64 bit libraries first.

So we need to somehow determine the target bit structure based on what the user selected for example in the CMake Gui dropdown.

[paroj]

[author="mako_energy", created="Tue, 25 Nov 2014 11:46:16 +0100"]

With my current understanding of MinGW64 (in my personal case being with TDM-GCC), 32 or 64 bit compilations are controlled by setting "-m32" or "-m64" in with the global compiler options. If neither is specified then it will default to 64-bit. In either case this check will detect the desired build as the compiler has been configured.

If other MinGW packages configure this differently (such as MinGW-w64) then this could be a problem I suppose. I don't have that information currently.

[paroj]

[author="mako_energy", created="Tue, 25 Nov 2014 11:49:41 +0100"]

Apologies, it has also just occurred to me that setting the architecture to athlon64 may not be required at all. The main issue with the existing code in CMake is that a 32-bit architecture is being set for all builds, prohibiting 64 bit builds. So you may be able to encase the i686 architecture in a check that verifies void pointers are 4 bytes and that could fix it. I will test this at my next earliest convenience.

[paroj]

[author="mako_energy", created="Tue, 25 Nov 2014 12:39:58 +0100"]

Wrapping the architecture config in a check for pointers being 4 bytes like so...

Unable to find source-code formatter for language: check. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

  if( CMAKE_SIZEOF_VOID_P EQUAL 4 )
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=i686")
  endif ()

...allowed compilation in my 64-bit environment without issue. During that compile I did some light research on how MinGW-w64 is set up and they seem to take the same compiler flags I mentioned earlier. MSYS's Mingw64 seems to not take them, but operate with completely different installs. So still not much in the way of interchangeability that needs to be worried about.

[paroj]

[author="mako_energy", created="Mon, 1 Dec 2014 21:15:26 +0100"]

@Philip Allgaier At first I had no idea what you meant by saying that having a solution that would work if 64 bit builds were selected in the CMake generator list. I now realize that among the vast sea of Visual Studio generators that you can do that. This design does not apply to any other group of generators however, and all of the CMake modifications I have proposed thus far are for CMake logic that is inside a check for MinGW(which is already in the file, encasing the offending code I quoted earlier). So this will have zero chance at contaminating builds for other compilers. Whether or not it'll work with the selected generator in the CMake pulldown doesn't apply.

[paroj]

[author="spacegaier", created="Mon, 1 Dec 2014 22:42:51 +0100"]

Okay, that makes sense then. I simply assumed that non VS generators also has a dedicated 64bit generator.

Could you provide a pull-request for Ogre 1.10 and Ogre 2.0 on BitBucket with CMake changes? Details can be found on the ogre3d.org website.

[paroj]

[author="mako_energy", created="Thu, 11 Dec 2014 22:52:22 +0100"]

Pull request created:
https://bitbucket.org/sinbad/ogre/pull-request/444/wrapped-the-forcing-of-an-architecture-on/diff