thr3ads.net - llvm dev - [llvm-dev] LLVM cross-compilation cmake issues [Oct 2017]

If this information is useful, please help other people find it:
Share via:

Shoaib Meenai via llvm-dev

2017-Oct-18 00:11 UTC

[llvm-dev] LLVM cross-compilation cmake issues

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 on behalf of
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
   
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=

Pirama Arumuga Nainar via llvm-dev

2017-Oct-20 18:09 UTC

head link

[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> 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 on behalf of
> 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
>     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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171020/0cfdaacc/attachment.html>

Shoaib Meenai via llvm-dev

2017-Oct-23 16:56 UTC

head link

[llvm-dev] LLVM cross-compilation cmake issues

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>

Maybe Matching Threads

Search for more apparently analagous threads

llvm dev - Oct 2017 - LLVM cross-compilation cmake issues

[llvm-dev] LLVM cross-compilation cmake issues

[llvm-dev] LLVM cross-compilation cmake issues

[llvm-dev] LLVM cross-compilation cmake issues

Maybe Matching Threads