[llvm-dev] LLVM cross-compilation cmake issues

Shoaib Meenai via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 23 09:56:40 PDT 2017


That will work well for me. Thank you!

From: Pirama Arumuga Nainar <pirama at google.com>
Date: Friday, October 20, 2017 at 11:09 AM
To: Shoaib Meenai <smeenai at fb.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] LLVM cross-compilation cmake issues

CROSS_TOOLCHAIN_FLAGS_NATIVE can be used to pass CMake variables when building the native tools.  What I do is set up a toolchain file:

set(CMAKE_C_COMPILER {host-cc})
set(CMAKE_CXX_COMPILER {host-cxx})
...

And pass this to the top level CMake:

-DCROSS_TOOLCHAIN_FLAGS_NATIVE="-DCMAKE_TOOLCHAIN_FILE=<path-to-above-file>"

CMAKE_C_COMPILER etc can instead be directly set in this flag (instead of a toolchain file):

-DCROSS_TOOLCHAIN_FLAGS_NATIVE="-DCMAKE_C_COMPILER=<host-cc> ..."


On Tue, Oct 17, 2017 at 5:11 PM, Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
I'm an idiot and sent to llvm-commits instead of llvm-dev. Fixing.

On 10/17/17, 5:09 PM, "llvm-commits on behalf of Shoaib Meenai via llvm-commits" <llvm-commits-bounces at lists.llvm.org<mailto:llvm-commits-bounces at lists.llvm.org> on behalf of llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>> wrote:

    Hi all (CC beanz for cmake advice),



    I'm running into a cmake problem when I try to cross-compile a Windows-hosted

    toolchain (building on Linux). I'm using clang-cl as my cross-compiler, and I

    set up the compiler paths in a cmake toolchain file. Unfortunately, as part of

    setting up the compiler, cmake sets the environment variables ASM, CC, CXX,

    etc. to the paths it found. It's easy enough to reproduce this; just configure

    the following CMakeLists.txt:



    message(STATUS "CC is $ENV{CC}")

    project(null C)

    message(STATUS "CC is $ENV{CC}")



    The first printout should be empty (assuming you don't have CC set in your

    environment already, of course), and the second value should be the full path

    the compiler found by cmake. Note that this will only occur on the initial

    configure; subsequent configures should have the compiler setup cached, and

    will therefore not set the environment variable. I've confirmed this behavior

    on cmake 3.5, 3.6, and 3.9, so I'm fairly sure it's universal.



    This causes problems for me because when I'm running the initial cmake

    configure for my cross-compile, ASM, CC, and CXX get set to the values for my

    cross-compiler (clang-cl). LLVM's build then launches the configure for the

    native portions of the build (TableGen, etc.), but this configure is launched

    with the aforementioned environment variables, and cmake's compiler detection

    picks up on those environment variables, so it then tries to compile the

    native portions with my cross-compiler, which goes about as well as you'd

    expect.



    My current workaround is to simply unset these environment variables before

    running the native configure step:



    --- a/cmake/modules/CrossCompile.cmake

    +++ b/cmake/modules/CrossCompile.cmake

    @@ -45,6 +45,9 @@ function(llvm_create_cross_target_internal target_name toolchain buildtype)

              # Propagate LLVM_EXTERNAL_CLANG_SOURCE_DIR so that clang-tblgen can be built

              set(external_clang_dir "-DLLVM_EXTERNAL_CLANG_SOURCE_DIR=${LLVM_EXTERNAL_CLANG_SOURCE_DIR}")

            endif()

    +    unset(ENV{ASM})

    +    unset(ENV{CC})

    +    unset(ENV{CXX})

         execute_process(COMMAND ${CMAKE_COMMAND} ${build_type_flags}

             -G "${CMAKE_GENERATOR}" -DLLVM_TARGETS_TO_BUILD=${LLVM_TARGETS_TO_BUILD}

             ${CROSS_TOOLCHAIN_FLAGS_${target_name}} ${CMAKE_SOURCE_DIR}



    It would be more proper to save the values of these environment variables at

    the start of the configure (before any project command is run) and restore

    those values before starting the native configure, of course. This still feels

    pretty ugly though, and I'm sure I'm not the first person to run into a

    similar issue. What would be the best way to fix this?



    Thanks,

    Shoaib



    _______________________________________________
    llvm-commits mailing list
    llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>
    https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=8ELwXEfNVoGOamcM1LPnxtDt4B9cgcSOabVKJZexuuU&s=TewHIKn_JhBOwiDZuDz6rGWMoBaH2jNeGs5OM7LG6cY&e=


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=qFQxRnRUC41XbKVdOpYJLdYqihp4Fx--ayW0eB7ISd4&s=w3ZRpCJ-YxoB5MoosSaF7q1kwK9i3Fg4vkyPL7PN0bk&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171023/ba2882b4/attachment.html>


More information about the llvm-dev mailing list