CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32 argument

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32 argument

LightGoLeft
Hello,

I am currently using TDM-GCC-64 (MinGW) and MSVC to build binaries on 64 bit
Windows to build both 32 and 64bit binaries. However, I found architecture
passed to GNUtoMS bat is determined by CMAKE_SIZEOF_VOID_P which is not
correctly set.

For GCC, I set
  SET(CMAKE_CXX_FLAGS "-m32 ${CMAKE_CXX_FLAGS}")
  SET(CMAKE_C_FLAGS "-m32 ${CMAKE_C_FLAGS}")
But, message(${CMAKE_SIZEOF_VOID_P }) is always 8. That causes GNUtoMS
generating x64 *.lib from x86 *.a. I don't know whether this is a bug or by
design.

Thanks,
Hao.




--
Sent from: http://cmake.3232098.n2.nabble.com/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32 argument

Craig Scott-3


On Wed, Dec 27, 2017 at 7:04 PM, LightGoLeft <[hidden email]> wrote:
Hello,

I am currently using TDM-GCC-64 (MinGW) and MSVC to build binaries on 64 bit
Windows to build both 32 and 64bit binaries. However, I found architecture
passed to GNUtoMS bat is determined by CMAKE_SIZEOF_VOID_P which is not
correctly set.

For GCC, I set
  SET(CMAKE_CXX_FLAGS "-m32 ${CMAKE_CXX_FLAGS}")
  SET(CMAKE_C_FLAGS "-m32 ${CMAKE_C_FLAGS}")
But, message(${CMAKE_SIZEOF_VOID_P }) is always 8. That causes GNUtoMS
generating x64 *.lib from x86 *.a. I don't know whether this is a bug or by
design.

CMake determines the bitness of the target when it does its compiler checks, which is performed at the first project() command it hits, and it caches the result for all subsequent CMake invocations. If you need to pass a flag like -m32 to build for 32-bit targets on a 64-bit host, you need to use a toolchain file and specify the -m32 option in there. If you simply add lines like your example above to your project's CMakeLists.txt file, they won't be picked up properly when CMake does its compiler tests. The correct way to specify this sort of flag in a toolchain file would look something like this (note the use of ..._INIT variables):

set(CMAKE_C_FLAGS_INIT   -m32)
set(CMAKE_CXX_FLAGS_INIT -m32)

set(CMAKE_EXE_LINKER_FLAGS_INIT    -m32)
set(CMAKE_MODULE_LINKER_FLAGS_INIT -m32)
set(CMAKE_SHARED_LINKER_FLAGS_INIT -m32)

Your toolchain file should also be setting CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_VERSION and CMAKE_SYSTEM_PROCESSOR to whatever is appropriate for your target architecture/platform (sorry, I'm not sure off the top of my head what these would typically be for your case). Be sure to clear any previous build if you want to experiment with this, since CMake caches its results after the first run.

--
Craig Scott
Melbourne, Australia

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32 argument

LightGoLeft

Hi Scott,

 

Thanks for the reply. It worked.

 

Hao.

From: [hidden email]
Sent: 2017
1227 21:35
To: [hidden email]
Cc: [hidden email]
Subject: Re: [CMake] CMAKE_SIZEOF_VOID_P did not set correctly by TDM-GCC -m32 argument

 

 

 

On Wed, Dec 27, 2017 at 7:04 PM, LightGoLeft <[hidden email]> wrote:

Hello,

I am currently using TDM-GCC-64 (MinGW) and MSVC to build binaries on 64 bit
Windows to build both 32 and 64bit binaries. However, I found architecture
passed to GNUtoMS bat is determined by CMAKE_SIZEOF_VOID_P which is not
correctly set.

For GCC, I set
  SET(CMAKE_CXX_FLAGS "-m32 ${CMAKE_CXX_FLAGS}")
  SET(CMAKE_C_FLAGS "-m32 ${CMAKE_C_FLAGS}")
But, message(${CMAKE_SIZEOF_VOID_P }) is always 8. That causes GNUtoMS
generating x64 *.lib from x86 *.a. I don't know whether this is a bug or by
design.

 

CMake determines the bitness of the target when it does its compiler checks, which is performed at the first project() command it hits, and it caches the result for all subsequent CMake invocations. If you need to pass a flag like -m32 to build for 32-bit targets on a 64-bit host, you need to use a toolchain file and specify the -m32 option in there. If you simply add lines like your example above to your project's CMakeLists.txt file, they won't be picked up properly when CMake does its compiler tests. The correct way to specify this sort of flag in a toolchain file would look something like this (note the use of ..._INIT variables):

 

set(CMAKE_C_FLAGS_INIT   -m32)

set(CMAKE_CXX_FLAGS_INIT -m32)

 

set(CMAKE_EXE_LINKER_FLAGS_INIT    -m32)

set(CMAKE_MODULE_LINKER_FLAGS_INIT -m32)

set(CMAKE_SHARED_LINKER_FLAGS_INIT -m32)

 

Your toolchain file should also be setting CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_VERSION and CMAKE_SYSTEM_PROCESSOR to whatever is appropriate for your target architecture/platform (sorry, I'm not sure off the top of my head what these would typically be for your case). Be sure to clear any previous build if you want to experiment with this, since CMake caches its results after the first run.

 

--

Craig Scott

Melbourne, Australia

https://crascit.com

 


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake