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 <m...@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.gar...@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.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 >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users