Cross compiling for Cortex A9

Karel Gardas karel.gardas at
Sat Aug 2 17:15:08 UTC 2014

IIRC, CFLAGS should be needed only for configure which should detect 
your architecture well and generate appropriate settings file. GHC 
itself should not use them IIRC. If you need something special, then you 
can use mk/

But I'm not expert for cross-compiling GHC, nor for cross-compiling 
using GHC which is the reason why I recommended native compilation 
especially since this is possible and the least problematic way to go...


On 08/ 2/14 04:02 AM, Michael Jones wrote:
> Karel,
> 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.
> Mike
> On Aug 1, 2014, at 3:23 PM, Michael Jones<mike at>  wrote:
>> Karel,
>> On CFLAGS..
>> 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
>>>> ARM_ISA=ARMv7
>>>> 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