[CMake] toolchain file - cross-compiling windows-amd64->windows-x86

Joao Pedro Abreu De Souza jp_abreu at id.uff.br
Wed Sep 18 12:39:06 EDT 2019


Cool. I try using this toolchain in a toy project, just to test, and
execute the cmake inside cross-compiling x64_x86 from visual studio 2017
and all work as expected, except the linking from ninja, that break because
cannot find printf.
Is absolutely cool, better than my last toolchain. Do you know how Can I
link with libc from visual studio 2013(that was your example)? From
location on 2013, the 2017 can be deduced, I think.

To make clear, when I said how to link with libc, is literally the path
that I don't know kkkk, I know that must use libpath(or set LIB env
variable) with the path, but what path? kkk

Em qua, 18 de set de 2019 às 02:50, Eric Doenges <doenges at mvtec.com>
escreveu:

> We use ninja for building on Windows. Our toolchain file for the MSVC
> compiler is really simple (this is for MSVC 18.0, 32 bits):
>
> --- SNIP ---
>
> set(CMAKE_SYSTEM_NAME Windows)
> set(CMAKE_SYSTEM_PROCESSOR "x86")
> set(CMAKE_SYSTEM_VERSION 1)
>
> # Microsoft MSVC compiler
> set(CMAKE_C_COMPILER cl.exe)
> set(CMAKE_CXX_COMPILER cl.exe)
>
> # Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
> # so tell CMake that cl.exe supports C99
> set(CMAKE_C_COMPILE_FEATURES c_std_99)
>
> # If Visual Studio is selected as generator, only allow VS 2013
> if(CMAKE_GENERATOR MATCHES "Visual Studio")
>   if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
>     message(FATAL_ERROR "Visual Studio generator requires Visual Studio 12
> 2013"
>       " for this configuration")
>   else()
>     # Enable parallel builds for Visual Studio Projects with the /MP flag
>     set(_MP_FLAG "/MP")
>   endif()
> endif()
>
> set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
> set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")
>
> --- SNIP ---
>
> However, there is a major snag (naturally, since we're talking about
> Windows here) - in order for the Microsoft compiler to work from the
> command line, you need to set the correct environment, and CMake doesn't
> really give you a good way to do this. You can set environment variables
> from CMake, but as the documentation says "This command affects only the
> current CMake process, not the process from which CMake was called, nor the
> system environment at large, nor the environment of subsequent build or
> test processes.".
>
> The solution we use is instead of calling cmake directly, we call a Perl
> script that sets up the environment correctly and then calls cmake for
> configuration or building. An alternative solution would be to write a
> batch script wrapper for cl.exe, something like.
>
> @ECHO OFF
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
> cl.exe %*
>
> and then set this batch script as the C and C++ compiler in CMake (note
> that this is untested - I think it should work, but it may need some extra
> work).
>
> With kind regards,
> Eric
> Am 17.09.19 um 21:46 schrieb fdk17:
>
> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> --
>
> *Dr. Eric Dönges*
> Senior Software Engineer
>
> MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
> doenges at mvtec.com <mustermann at mvtec.com> | Tel: +49 89 457 695-0 |
> www.mvtec.com
>
> Find our privacy policy here <https://www.mvtec.com/imprint>.
>
>  Sign up <https://www.mvtec.com/newsletter> for our MVTec Newsletter!
>
> Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
> Amtsgericht München HRB 114695
>
>
> [image: MVTec Software GmbH Logo]
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190918/d8003edb/attachment.html>


More information about the CMake mailing list