Cross compiling for Cortex A9

Karel Gardas karel.gardas at
Fri Aug 1 09:19:20 UTC 2014

OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does 
ghc-stage1 --info tell you?

Aha, you hacked configure, hmm. I don't think this is needed especially 
if you use proper CFLAGS.


On 07/25/14 06:00 AM, Michael Jones wrote:
> I have some progress, and a problem. First, note I am using the 7.8.3
> tar ball, for this discussion here.
> If you read through, you will see a request for help at the end. It
> looks like the cross compilation is trying to build stage2 when it
> shouldn’t.
> In order to get the resulting stage1 cross compiler to have:
> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON],
> armABI = HARD}")
> I hacked this:
> [
> changequote(, )dnl
> changequote([, ])dnl
> ])
> Now, my gcc cross compiler does not default to ARMv7. To compile for my
> Cortex A, I add these options:
> -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon
> -mtune=cortex-a9
> So I need to make sure that when building the libraries with stage1, it
> passes the correct options. To do that:
> [
> AC_MSG_CHECKING([Setting up $2, $3, $4 and $5])
>> arm-poky-*)
> $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon
> -mtune=cortex-a9"
> ;;
> Which results in a stage1 compiler with:
> ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard
> -mfpu=neon -mtune=cortex-a9 -fno-stack-protector”)
> As the build proceeds, all calls to stage1 are completing. Then, the
> build gets to this point:
> "inplace/bin/mkdirhier" compiler/stage2/build//.
> "rm" -f compiler/stage2/build/Config.hs
> Creating compiler/stage2/build/Config.hs ...
> done.
> And I assume this means it is trying to build stage2. Correct me if I am
> wrong.
> Eventually I get a build failure like this:
> -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9
> -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils
> -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI
> -I'/home/mike/ghc-7.8.3/libraries/process/include'
> -I'/home/mike/ghc-7.8.3/libraries/directory/include'
> -I'/home/mike/ghc-7.8.3/libraries/unix/include'
> -I'/home/mike/ghc-7.8.3/libraries/time/include'
> -I'/home/mike/ghc-7.8.3/libraries/containers/include'
> -I'/home/mike/ghc-7.8.3/libraries/bytestring/include'
> -I'/home/mike/ghc-7.8.3/libraries/base/include'
> -I'/home/mike/ghc-7.8.3/rts/dist/build'
> -I'/home/mike/ghc-7.8.3/includes'
> -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c
> compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit
> gcc: error: unrecognized command line option ‘-mthumb-interwork’
> gcc: error: unrecognized command line option ‘-mfloat-abi=hard’
> gcc: error: unrecognized command line option ‘-mfpu=neon’
> make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1
> make: *** [all] Error 2
> It is applying the -march… arguments to the local gcc. I am guessing
> that compiling for stage2 is using the local gcc because stage2 is only
> built when not making a cross compiler.
> Now, in I have:
> BuildFlavour = quick-cross
> Which is supposed to prevent stage2 compilation.
> Something is wrong. Either I need to stop stage2 compilation, if that is
> what this is really doing, or prevent gcc from using the extra
> arguments. But I see no reason to run gcc. Seems like that would only be
> used at stage0 if at all.
> Mike
> On Jul 14, 2014, at 10:12 AM, Karel Gardas <karel.gardas at
> <mailto:karel.gardas at>> wrote:
>> On 07/14/14 04:58 PM, Michael Jones wrote:
>>> Karel,
>>> Thanks. This helps.
>>> If I understand, you have Linux running on a Panda, and on that Panda
>>> system you have gcc, and you compile GHC on the Panda itself, rather
>>> than build a cross compiler. I can see the advantage of building this
>>> way.
>> Correct!
>>> As far as cross compilers, I have a reason for trying to build a
>>> cross compiler, other than the ability to keep the image of the
>>> target small. That is, eventually, I want to be able to compile for
>>> an RTOS and/or bare iron system. I decided that learning to cross
>>> compile for Linux first would be a good approach. Learn the build
>>> system on something known to work. So I probably will not give up on
>>> that.
>> That is right, in future I'd also like to give a try to port GHC to
>> some free RTOS and for this I'd need to use cross-compiling anyway, so
>> I'll be on the same boat...
>>> I got a book on Autoconfig. I’ll just have to dig a level deeper into
>>> the whole build system. Mainly it means learning the M4 system. I
>>> have never used it.
>>> Below are the defines from the command you suggested. Thanks for
>>> that, got me over an ignorance hump. At least this define,
>>> __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study
>>> the macros until I figure out what controls the gcc options passed to
>>> the gcc cross compiler. I guess my question is what actually controls
>>> this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt =
>>> [VFPv3,NEON], armABI = HARD}”)?
>>> Are these controlled by the defines below, or are they controlled by
>>> passing gcc arguments to the gcc compiler when the Haskell compiler
>>> calls gcc?
>> Basically speaking all those are controlled by platform gcc. That
>> means if you pass the right option to your cross-compiling gcc you
>> should also get the same result, so for example if you use:
>> gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16
>> you should get the same settings like me.
>> But anyway, please note that ABI you set to your cross-compiler *have
>> to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-)
>> Cheers,
>> Karel

More information about the Glasgow-haskell-users mailing list