<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>I have some progress, and a problem. First, note I am using the 7.8.3 tar ball, for this discussion here.</div><div><br></div><div>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.</div><div><br></div><div>In order to get the resulting stage1 cross compiler to have:</div><div><br></div><div><div> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}")</div></div><div><br></div><div>I hacked this:</div><div><br></div><div><div>AC_DEFUN([GET_ARM_ISA],</div><div>[</div><div>    changequote(, )dnl</div><div>    ARM_ISA=ARMv7</div><div>    ARM_ISA_EXT="[VFPv3,NEON]"</div><div>    changequote([, ])dnl</div><div>    [ARM_ABI="HARD"]</div><div>])</div></div><div><br></div><div>Now, my gcc cross compiler does not default to ARMv7. To compile for my Cortex A, I add these options:</div><div><br></div><div>-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9</div><div><br></div><div>So I need to make sure that when building the libraries with stage1, it passes the correct options. To do that:</div><div><br></div><div><div>AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS],</div><div>[</div><div>    AC_MSG_CHECKING([Setting up $2, $3, $4 and $5])</div></div><div>…</div><div><div>    arm-poky-*)</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>$2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9"</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>;;</div></div><div><br></div><div><br></div><div>Which results in a stage1 compiler with:</div><div><br></div><div> ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector”)</div><div><br></div><div>As the build proceeds, all calls to stage1 are completing. Then, the build gets to this point:</div><div><br></div><div><div>"inplace/bin/mkdirhier" compiler/stage2/build//.</div><div>"rm" -f compiler/stage2/build/Config.hs  </div><div>Creating compiler/stage2/build/Config.hs ... </div><div>done.</div></div><div><br></div><div>And I assume this means it is trying to build stage2. Correct me if I am wrong.</div><div><br></div><div>Eventually I get a build failure like this:</div><div><br></div><div><div>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</div><div>gcc: error: unrecognized command line option ‘-mthumb-interwork’</div><div>gcc: error: unrecognized command line option ‘-mfloat-abi=hard’</div><div>gcc: error: unrecognized command line option ‘-mfpu=neon’</div><div>make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1</div><div>make: *** [all] Error 2</div></div><div><br></div><div>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.</div><div><br></div><div>Now, in build.mk I have:</div><div><br></div><div>BuildFlavour  = quick-cross</div><div><br></div><div>Which is supposed to prevent stage2 compilation.</div><div><br></div><div>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.</div><div><br></div><div>Mike</div><br><div><div>On Jul 14, 2014, at 10:12 AM, Karel Gardas <<a href="mailto:karel.gardas@centrum.cz">karel.gardas@centrum.cz</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 07/14/14 04:58 PM, Michael Jones wrote:<br><blockquote type="cite">Karel,<br><br>Thanks. This helps.<br><br>If I understand, you have Linux running on a Panda, and on that Panda<br>system you have gcc, and you compile GHC on the Panda itself, rather<br>than build a cross compiler. I can see the advantage of building this<br>way.<br></blockquote><br>Correct!<br><br><blockquote type="cite">As far as cross compilers, I have a reason for trying to build a<br>cross compiler, other than the ability to keep the image of the<br>target small. That is, eventually, I want to be able to compile for<br>an RTOS and/or bare iron system. I decided that learning to cross<br>compile for Linux first would be a good approach. Learn the build<br>system on something known to work. So I probably will not give up on<br>that.<br></blockquote><br>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...<br><br><blockquote type="cite">I got a book on Autoconfig. I’ll just have to dig a level deeper into<br>the whole build system. Mainly it means learning the M4 system. I<br>have never used it.<br><br>Below are the defines from the command you suggested. Thanks for<br>that, got me over an ignorance hump. At least this define,<br>__ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study<br>the macros until I figure out what controls the gcc options passed to<br>the gcc cross compiler. I guess my question is what actually controls<br>this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt =<br>[VFPv3,NEON], armABI = HARD}”)?<br><br>Are these controlled by the defines below, or are they controlled by<br>passing gcc arguments to the gcc compiler when the Haskell compiler<br>calls gcc?<br></blockquote><br>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:<br><br>gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16<br><br>you should get the same settings like me.<br><br>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. :-)<br><br>Cheers,<br>Karel</div></blockquote></div><br></body></html>