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.gar...@centrum.cz
<mailto:karel.gar...@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
