Cross compiling for Cortex A9

[Michael Jones]

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 proclivis.com> 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 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
>> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users