<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p dir="ltr">We've been doing this for years in Julia with no troubles, but all in autotools. This is our primary build configuration used to create Windows installers. We have to target mingw because of Lapack and a few smaller Fortran dependencies.</p>
<p dir="ltr">Fedora, OpenSUSE, Arch, and Cygwin all have sets of mingw cross-compiled library packages but as far as I'm aware only Cygwin has packaged a cross-built llvm yet.
</p>
<p dir="ltr">This may not be a very high profile build configuration, but it's a definite regression. I'll try to figure out if cmake is setting the env vars in places it shouldn't be. Building all of LLVM twice doesn't sound like a satisfying workaround, but
if it's the only thing we can get to work...<br>
</p>
<br>
<br>
<br>
<div class="gmail_quote">On Thu, Feb 11, 2016 at 10:27 AM -0800, "Chris Bieneman"
<span dir="ltr"><<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>></span> wrote:<br>
<br>
</div>
<div class="BodyFragment">
<div class="PlainText">Sadly you are way out in uncharted territory. I’m unaware of anyone using gcc to cross-compile LLVM. At Apple we extensively cross-compile, but we use clang as our host compiler.<br>
<br>
I’m not sure why you’re seeing the native CMake picking up your cross-compiler instead of your host compiler. Our CMake scripts don’t pass through he compiler from one configuration to the next. I’m guessing the “native” CMake is probably picking up the cross-compiler
from the environment somehow (maybe the CC and CXX envar).<br>
<br>
You can probably work around the issue by configuring a host LLVM directory and passing that directory into your cross-configured CMake invocation with the LLVM_NATIVE_BUILD option.<br>
<br>
Because you are off in uncharted territory I expect you’re mostly going to be on your own for debugging and diagnosing. I can answer specific questions, but I haven’t used a gcc toolchain for cross-compiling since the early days of the PS3 (and I’ve pretty
much blocked that out of my memory).<br>
<br>
-Chris<br>
<br>
<br>
> On Feb 10, 2016, at 11:43 PM, Tony Kelman <tony@kelman.net> wrote:<br>
> <br>
>> The problem you are hitting is caused by setting CMAKE_SYSTEM_NAME.<br>
>> When you set that CMake sets a variable CMAKE_CROSS_COMPILING. That<br>
>> variable should only be set when your host OS doesn't match your target<br>
>> OS. Since LLVM needs to build host-capable tools there is some goop to<br>
>> call out and configure a new CMake build directory to target the host.<br>
> <br>
> Right. My build OS doesn't match my target OS, my build is Linux or Cygwin,<br>
> and the target is Win32. So setting CMAKE_CROSS_COMPILING is correct.<br>
> It's the "goop" that needs some work to get back to parity with the<br>
> functionality that was working on autotools. Sorry I didn't try running<br>
> this configuration earlier on in the autotools-deprecation process.<br>
> <br>
> The new CMake build directory for the native tools needs to not use the<br>
> same settings for compiler names as the parent cross-compile build.<br>
> Any ideas how to accomplish this? I'm happy to help test out patches<br>
> and dig into cmake docs as necessary to get this working. If this would<br>
> be more appropriate to work through in an issue than on the mailing<br>
> list, do say so.<br>
> <br>
> -Tony<br>
> <br>
> <br>
<br>
</div>
</div>
</body>
</html>