[llvm-dev] Guidance on cross compiling LLVM with mingw-w64 and cmake

[ChrisBieneman via llvm-dev]

The CrossCompile module is in a perpetual state of "when I get a chance...", and desperately needs some cleanup.

The problem you are hitting is caused by setting CMAKE_SYSTEM_NAME. When you set that CMake sets a variable CMAKE_CROSS_COMPILING. That variable should only be set when your host OS doesn't match your target OS. Since LLVM needs to build host-capable tools there is some goop to call out and configure a new CMake build directory to target the host.

-Chris

> On Feb 10, 2016, at 6:20 AM, Mike Edwards <mike at sqlby.me> wrote:
> 
> Hi Tony,
> I don't have experience with your specific circumstance, so sorry I can't be much help there.  Thank you though for pointing out what appears to be a typo.  CC'ing Chris Bieneman as he may be able to verify if this is correct.
> 
> Chris,
> I have attached a patch which should fix the typo.  Would you mind having a look and committing if you think it is all good?
> 
> Hope you both have a good day.
> 
> Thanks,
> Mike Edwards
> 
>> On Tue, Feb 9, 2016 at 8:21 PM, Tony Kelman via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> I need to build libLLVM (individual static libraries are fine at the
>> moment) using mingw-w64 cross compilers, i686-w64-mingw32-gcc and
>> (separately) x86_64-w64-mingw32-gcc. I'd like this to work from both
>> Linux and Cygwin build environments. With autotools, this worked fine:
>> ../configure --host=i686-w64-mingw32 and that's it (with mingw32-gcc-c++
>> installed on Fedora 23, also works fine on Ubuntu, Cygwin, etc).
>> I'm trying to recreate this with cmake so we don't get stuck on 3.8
>> indefinitely. Here's what I've got so far:
>> 
>> cmake .. -DCMAKE_C_COMPILER=/usr/bin/i686-w64-mingw32-gcc \
>>   -DCMAKE_CXX_COMPILER=/usr/bin/i686-w64-mingw32-g++ \
>>   -DCMAKE_SYSTEM_NAME=Windows \
>>   -DCMAKE_RC_COMPILER=/usr/bin/i686-w64-mingw32-windres
>> # (some older versions of cmake have issues if you don't
>> # specify an absolute path to windres)
>> 
>> When this gets to "Configuring NATIVE targets" it calls cmake again
>> trying to use the same mingw compilers, but without CMAKE_SYSTEM_NAME
>> set so it doesn't succeed in configuring. During the build I then get
>> a "No rule to make target 'LLVMSupport'.  Stop." Full build log is at
>> http://sprunge.us/bCUU
>> 
>> I'd like to go with the default behavior of building a native version
>> of TableGen, but the way that's currently set up in cmake isn't working
>> here. I'm looking at cmake/modules/CrossCompile.cmake (and I think
>> "toochain" on the first line is a typo?) and trying to figure out how
>> to make its call to execute_process(COMMAND ${CMAKE_COMMAND} ...) not
>> inherit the top-level settings for CMAKE_C_COMPILER etc from the cross
>> build. Any ideas? I've tried moving my mingw settings from the command
>> line to a toolchain file but that hasn't done anything different so far.
>> I've also tried specifically creating a native toolchain file and
>> tweaking the call to llvm_create_cross_target_internal at the end of
>> CrossCompile.cmake to use it, but that hasn't worked either - keeps giving
>> Could not find toolchain file: "/home/llvm/cmake/platforms/NATIVE.cmake"
>> 
>> Is this a configuration anyone else has gotten working with cmake?
>> Thanks,
>> Tony
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> <patch.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/b5f876f7/attachment.html>