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
curious.)
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/ghc.mk 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 (http://llvm.org/):
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. ;)
Thanks,
Alex
On Wed, Dec 11, 2013 at 12:27 AM, Simon Marlow
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 (http://www.pmbaty.com/iosbuildenv/ 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@haskell.org http://www.haskell.org/mailman/listinfo/iphone
participants (1)
-
Alex Carter