Cross compiling for Cortex A9

[Michael Jones]

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 centrum.cz> 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:
>> 
>> 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
>