Error while compiling cross-compiler

Mon Mar 11 03:01:01 CET 2013

On Sun, Mar 10, 2013 at 8:12 PM, Eric Schug <schugschug at gmail.com> 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:

http://www.mail-archive.com/cvs-ghc@haskell.org/msg44422.html

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 ghc.mk 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 gmail.com>  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 https://github.com/raspberrypi/tools.git
>>>>> export rpitools=`pwd`/rpitools/
>>>>> export tools=`pwd`/tools
>>>>> export
>>>>>
>>>>> PATH=$PATH:$tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin
>>>>>
>>>>> wget http://www.haskell.org/ghc/dist/7.6.2/ghc-7.6.2-src.tar.bz2
>>>>> 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 ghc.mk 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-0.3.0.0...
>>>>> ghc-cabal: /tmp/22147.o: does not exist
>>>>> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
>>>>> make: *** [all] Error 2
>>>>>
>>>>> I am not sure if I need to create a mk/build.mk file using the
>>>>> mk/build.mk.sample, 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 haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

--
Regards,
Austin