Cross compiling for Cortex A9

[Karel Gardas]

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:
>
> AC_DEFUN([GET_ARM_ISA],
> [
> changequote(, )dnl
> ARM_ISA=ARMv7
> ARM_ISA_EXT="[VFPv3,NEON]"
> 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_DEFUN([FPTOOLS_SET_C_LD_FLAGS],
> [
> 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:
>
> gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a
> -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 build.mk 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 centrum.cz
> <mailto:karel.gardas at centrum.cz>> 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
>