Cross compiling for Cortex A9

Michael Jones mike at
Sat Aug 2 02:02:28 UTC 2014


I think I proved that make dies early if CFLAGS has these options. The local gcc does not support ARM related flags.

I am trying to build the tool chain with —with-arch= and —with-tune== so that it defaults to my target. This will bypass any GHC build issues.


On Aug 1, 2014, at 3:23 PM, Michael Jones <mike at> wrote:

> Karel,
> When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler?
> Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen.
> Mike
> Sent from my iPad
>> On Aug 1, 2014, at 3:19 AM, Karel Gardas <karel.gardas at> wrote:
>> 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.
>> Karel
>>> 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
>>> [ARM_ABI="HARD"]
>>> ])
>>> 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
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list