Error while compiling cross-compiler

Eric Schug schugschug at
Mon Mar 11 04:11:10 CET 2013

That explanation helps a lot. I can see now why there is much 
controversy over using template haskell in some other projects.
I did finally get it some of the libraries to compile including terminfo 
and integer-gmp,
I had tried a number of things to get it to work, and I'm not sure what 
all of the changes I needed to do.

But some of them were

export C_INCLUDE_PATH={path to target version of ncurses.h or curses.h}

editing  mk/ to use GMP
   GMP_INCLUDE_DIRS ={path to target version of gmp.h}
   GMP_LIB_DIRS = {path to target version of libgmp.a}

Running configure with extra LDFLAGS option
./configure --target=arm-linux-gnueabihf --prefix=$rpitools 
LDFLAGS=-L{path to target version of libcurses.a}

after the install to $rpitools I could install further packages using 
(it seems I needed to include --with-hc-pkg as well)

cabal install 
--prefix=$rpitools bytestring==

tools={path to local copy of}

I'll try it again using a cleaner method.  One should be able to do 
cross compile by just toplevel configure options and modifying 
mk/ but I wasn't getting anywhere just doing that. I had on a 
number of attempts manually called configure within the libraries only 
for them to be recalled again when running make, overwriting my corrections.


On 03/10/13 22:01, Austin Seipp wrote:
> On Sun, Mar 10, 2013 at 8:12 PM, Eric Schug<schugschug at>  wrote:
>> After reading over the wiki it sounds like these are only used for stage 2
>> compiler, which includes ghci and template haskell.
>> Is that correct?
>> I have the executable ghc-stage1 so I guess that is as much as functionality
>> I will get for cross-compiling to raspberry pi.
> Yes. However, the stage2 compiler could certainly be built as well.
> The idea is you create an x86 ->  ARM stage1 compiler, and then
> recompile everything again using stage1, yielding a stage2 compiler
> that is built for ARM, and compiles for ARM. This way you can get a
> 'full toolchain' easily on another machine that's much more powerful.
> You can just transport it to your ARM machine in the form of a binary
> distribution and then use it. It doesn't work that way yet, but I
> believe that is the plan.
> Unfortunately some libraries also require the stage2 compiler to be
> used on the host (anything that uses GHCi/Linking-related features,
> including Template Haskell.) So you do miss some things still. I don't
> think these problems are insurmountable, but I'm not sure what the
> plans are at the moment to solve this for packages like vector/dph to
> get TH things to run on the host. It may just be best to try to ensure
> those packages require it can later be installed from cabal on the
> host (this is true of all these packages, I think, so in practice this
> is OK.)
>> Are there optimization features that are missing from the stage 1 compiler?
> Not really. Both stages contain the exact same optimizations and
> whatnot. stage2 exists because of the slight complications that arise
> when linking code at runtime (using GHCi-ish features. More on this in
> a sec.)
> When building an RPi compiler, there *is* an optimization catch
> though: unregisterised vs registerised. Briefly, this is a locality
> optimization for the CPU that places jump tables for closures and
> thunks 'near' the code that uses them, in the .text section. This
> improves performance wrt. spacial locality. But it's not really
> related to stage 1 vs 2 (although I believe you can only have an
> unregisterised stage1.)
>> Why must template haskell support only work with the stage 2 compiler which
>> can only run on the target platform.
> I explained this recently here, but for plugins and not Template Haskell/GHCi:
> But the same logic applies, because when you use Template Haskell or
> GHCi you *are* dynamically linking Haskell code at runtime. When you
> dynamically link object code, the 'thing' into which that code is
> injected must be built with the same compiler as the object code. And
> when the 'thing' is the compiler itself, it must be built with itself
> first!
> I've seen a lot of questions about this in recent memory it feels like
> and I think perhaps this isn't explained well enough. Perhaps it
> deserves a nice spot in the users guide?
> Really now that I think about it, the whole cross compilation story
> should be put in the users guide. I think an explanation of stage1 vs
> stage2 (and other concerns) are worth putting there too. This is
> clearly something users want based on all the discussion around it,
> and when people download tarballs or look up docs on a specific
> version of GHC, it would be nice to see docs written for that, and not
> ones that are changed due to the wiki constantly being updated (which
> is good too!)
> Cross compilation is getting pretty far and a lot of users have gotten
> it working, so I think the aspects of maintaining such a section of
> the guide will not be too high over time, and it's certainly a place
> users will want to look first I think.
> Thoughts?
>> Eric
>> On 03/10/13 08:26, Simon Marlow wrote:
>>> On 09/03/13 12:18, Eric Schug wrote:
>>>> Ok using git HEAD, which got me further, but now errors when compiling
>>>> terminfo.
>>>> Its having problems locating the headers and libraries for
>>>> cursers/ncursers
>>>> Although, I have the host headers and libraries, but I expect it is
>>>> searching for the target versions.
>>>> These I can pull from my raspberry pi, but I am not sure where to put
>>>> them such that the
>>>> cross compiler will find them.
>>> I think I disabled terminfo (and hence haskeline) for my RPi
>>> cross-compiler.  I commented them out of as a temporary measure, but
>>> didn't get around to finding a proper solution.
>>> Cheers,
>>>      Simon
>>>> On 03/08/13 20:19, Austin Seipp wrote:
>>>>> 7.6.2 doesn't really support cross compilation. The bulk of the work
>>>>> has been done in the git repository. Any artifacts of cross
>>>>> compilation support in released tarballs can be ignored.
>>>>> Please do try the steps on the wiki page, using a copy of HEAD from
>>>>> git. I tried this a week or two ago and encountered no difficulties if
>>>>> my memory serves correctly.
>>>>> Sent from my iPhone^H^H^H^H^HPortable Turing machine
>>>>> On Mar 8, 2013, at 6:34 PM, Eric Schug<schugschug at>   wrote:
>>>>>> I am following the instructions for creating a cross compiler for
>>>>>> Raspberry Pi, but I get a file does not exist error during stage 1
>>>>>> (see below).
>>>>>> The basic steps I have taken are
>>>>>> apt-get install llvm
>>>>>> git clone
>>>>>> export rpitools=`pwd`/rpitools/
>>>>>> export tools=`pwd`/tools
>>>>>> export
>>>>>> PATH=$PATH:$tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin
>>>>>> wget
>>>>>> tar jxvf ghc-7.6.2-src.tar.bz2
>>>>>> cd ghc-7.6.2/
>>>>>> ./configure --target=arm-linux-gnueabihf --prefix=$rpitools
>>>>>> make
>>>>>> make -r --no-print-directory -f phase=1 phase_1_builds
>>>>>> CROSS_COMPILE="arm-unknown-linux-gnueabihf-" "inplace/bin/ghc-cabal"
>>>>>> configure
>>>>>> --with-ghc="/media/2612bbee-1ea0-43dd-82f4-c7e7d3fe634b_/eric/haskell/ghc-7.6.2/inplace/bin/ghc-stage1"
>>>>>> --with-ghc-pkg="/media/2612bbee-1ea0-43dd-82f4-c7e7d3fe634b_/eric/haskell/ghc-7.6.2/inplace/bin/ghc-pkg"
>>>>>> --flag=include-ghc-prim --enable-library-for-ghci
>>>>>> --configure-option=CFLAGS=" -fno-stack-protector   "
>>>>>> --configure-option=LDFLAGS=" -Wl,--hash-size=31
>>>>>> -Wl,--reduce-memory-overheads  " --configure-option=CPPFLAGS="   "
>>>>>> --with-gcc="/media/2612bbee-1ea0-43dd-82f4-c7e7d3fe634b_/eric/haskell/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc"
>>>>>> --configure-option=--with-cc="/media/2612bbee-1ea0-43dd-82f4-c7e7d3fe634b_/eric/haskell/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc"
>>>>>> --with-ar="/usr/bin/ar" --with-ranlib="true"
>>>>>> --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" --
>>>>>> dist-install libraries/ghc-prim
>>>>>> Configuring ghc-prim-
>>>>>> ghc-cabal: /tmp/22147.o: does not exist
>>>>>> make[1]: *** [libraries/ghc-prim/dist-install/] Error 1
>>>>>> make: *** [all] Error 2
>>>>>> I am not sure if I need to create a mk/ file using the
>>>>>> mk/, but when I do so and add the line
>>>>>> Stage1Only = YES
>>>>>> I still get the same error only with a different temp filename.
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at
> --
> Regards,
> Austin

More information about the ghc-devs mailing list