Cross-Compiler: Windows-to-iOS

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Cross-Compiler: Windows-to-iOS

Alex Carter
Hello, ghc-devs!

This is continuation of a conversation from the iphone list, but since
it seems to be more of a general cross-compilation issue, I'll toss it
up for you guys. (See the conversation history below if you're

The gist is that I'm trying to build a Windows-to-iOS cross-compiler,
and since I imagine this isn't something done very often, I've hit a
few bumps along the way.

First up, gcc (4.5.2, inplace/mingw/bin) really doesn't seem to like
rts/Task.h:283, complaining "error: aggregate value used where an
integer was expected." For this configuration, presumably OSThreadId
is pthread_t and TaskId is uint64, so I'm not sure why it doesn't like
the casts. I worked around with

    return *( (TaskId*) ( (size_t*) &taskID ) );

Last night I was stuck on compiling some automatically generated
headers that come out of the deriveConstants utility, and as best I
can gather, it generates a header that is (marginally) dependent upon
the platform on which it's currently running by using System.Info.os,
but the compilation that uses the header seems to be expecting it to
work for the target (runtime, maybe?). I added an "os" switch to
deriveConstants rather than using System.Info.os and passed the target
OS through in includes/ where it's invoked.

So that seems to fix my issues with StgAsyncIOResults (Windows-only,
right?) but I have no idea if these hacks make any sense in the big
picture, or if the compiler will even work once I finish the build...

Presently I'm stuck on something I expected to be rather
straightforward: "Warning: Couldn't figure out LLVM version! Make sure
you have installed LLVM." The iOS toolchain I'm using is in my PATH,
and both "llc -version" and "opt -version" work as expected in my
shell. I'm curious if it's because of the odd version number:

    $ llc -version
    LLVM (
      LLVM version 3.3svn

Is ./configure perhaps getting caught up on the "svn" and treating
this as a failure of version detection? I haven't been able to find a
way to manually override the configuration and specify the LLVM paths.

Any help is appreciated so I can get back to writing Haskell instead
of build debugging. ;)


On Wed, Dec 11, 2013 at 12:27 AM, Simon Marlow <marlowsd at> wrote:

> Yes, this is correct.  ghc_boot_platform describes the platforms for the
> stage 1 compiler (assuming you're looking at the one in compiler/stage1).
> ghcplatform.h describes the platforms in use for compiled code, so the host
> in that case is ios.  In fact ghcplatform.h shouldn't have a target platform
> at all - the only reason it does is for "backwards compatibility", though I
> don't remember exactly what goes wrong if we remove these.
> Cheers,
> Simon
> On 11/12/2013 00:08, Alex Carter wrote:
>> I'm on an interesting journey building a GHC cross-compiler on Windows
>> to target iOS, using a third-party iOS toolchain for Windows
>> ( for the curious), and I'm running
>> into an unusual issue. Since this is a cross-compiler, this should be
>> all stage 1, so in ghc_boot_platform.h I see what I expect:
>>      ...
>>      #define BUILD_OS "mingw32"
>>      #define HOST_OS "mingw32"
>>      #define TARGET_OS "ios"
>>      ...
>> but ghcplatform.h shows:
>>      ...
>>      #define BUILD_OS  "mingw32"
>>      #define HOST_OS  "ios"
>>      ...
>>      #define TARGET_OS  "ios"
>>      ...
>> which I understand to mean that whatever's happening there is set up
>> for the stage 2 compiler (unless there's some good magic happening
>> here with the deriveConstants utility?). I discovered this through a
>> pragma added at the error site:
>>      ...
>>      rts/Task.h:280:9: note: #pragma message: HOST_OS=ios
>>      rts/Task.h:287:5: error: aggregate value used where an integer was
>> expected
>>      ...
>> Anybody know what's going on here? Is it right (for some reason beyond
>> my current comprehension) for ghcplatform.h to have the #defines it
>> does? Is HOST_OS=ios correct, but rts/Task.h:280 should also check
>> defined(ios_HOST_OS)?
>> Thanks for the help,
>> Alex
>> _______________________________________________
>> iPhone mailing list
>> iPhone at