Ben,

I ran into a snag trying to use the options you suggested. First, I was not sure where to use the flags, so I pasted a piece of my build.mk. You can correct it if I have it wrong.

I also get a compile error that I pasted after the build.mk text.

I have not made any changes except in aclocal.m4 so that my configure can recognize the target. It can’t figure out the tools, so I add options for all of them. The tools are for the target. That was my interpretation of the wiki. It finds the host tools on its own.

add eabi support in aclocal.m4...
autoreconf
./configure --target=arm-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc --with-ld=arm-poky-linux-gnueabi-ld --with-nm=arm-poky-linux-gnueabi-nm --with-ar=arm-poky-linux-gnueabi-ar --with-ranlib=arm-poky-linux-gnueabi-ranlib

# -------- A Fast build configured for cross-compilation ----------------------

ifeq "$(BuildFlavour)" "quick-cross"

SRC_HC_OPTS        = -H64m -O0 -auto-all -caf-all -prof
GhcStage1HcOpts    = -O -fllvm -auto-all -caf-all -prof
GhcStage2HcOpts    = -O0 -fllvm
GhcLibHcOpts       = -O -fllvm -auto-all -caf-all -prof
SplitObjs          = NO
HADDOCK_DOCS       = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS   = NO
BUILD_DOCBOOK_PDF  = NO
INTEGER_LIBRARY    = integer-simple
Stage1Only         = YES

DYNAMIC_BY_DEFAULT   = NO
DYNAMIC_GHC_PROGRAMS = NO

endif

echo "compiler_stage1_depfile_haskell_EXISTS = YES" >> compiler/stage1/build/.depend-v.haskell.tmp
for dir in compiler/stage1/build/./ compiler/stage1/build/CodeGen/ compiler/stage1/build/CodeGen/Platform/ compiler/stage1/build/Hoopl/ compiler/stage1/build/Llvm/ compiler/stage1/build/LlvmCodeGen/ compiler/stage1/build/PPC/ compiler/stage1/build/RegAlloc/ compiler/stage1/build/RegAlloc/Graph/ compiler/stage1/build/RegAlloc/Linear/ compiler/stage1/build/RegAlloc/Linear/PPC/ compiler/stage1/build/RegAlloc/Linear/SPARC/ compiler/stage1/build/RegAlloc/Linear/X86/ compiler/stage1/build/RegAlloc/Linear/X86_64/ compiler/stage1/build/SPARC/ compiler/stage1/build/SPARC/CodeGen/ compiler/stage1/build/Vectorise/ compiler/stage1/build/Vectorise/Builtins/ compiler/stage1/build/Vectorise/Generic/ compiler/stage1/build/Vectorise/Monad/ compiler/stage1/build/Vectorise/Type/ compiler/stage1/build/Vectorise/Utils/ compiler/stage1/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done
grep -v ' : [a-zA-Z]:/' compiler/stage1/build/.depend-v.haskell.tmp > compiler/stage1/build/.depend-v.haskell.tmp2
sed -e '/hs$/ p' -e '/hs$/ s/o /hi /g' -e '/hs$/ s/:/ : %hi: %o /' -e '/hs$/ s/^/$(eval $(call hi-rule,/' -e '/hs$/ s/$/))/' -e '/hs-boot$/ p' -e '/hs-boot$/ s/o-boot /hi-boot /g' -e '/hs-boot$/ s/:/ : %hi-boot: %o-boot /' -e '/hs-boot$/ s/^/$(eval $(call hi-rule,/' -e '/hs-boot$/ s/$/))/' compiler/stage1/build/.depend-v.haskell.tmp2 > compiler/stage1/build/.depend-v.haskell
utils/ghc-pkg/ghc.mk:46: warning: overriding commands for target `install_utils/ghc-pkg_dist_wrapper'
utils/ghc-pkg/ghc.mk:37: warning: ignoring old commands for target `install_utils/ghc-pkg_dist_wrapper'
make[1]: *** No rule to make target `libraries/terminfo/dist-boot/build/System/Console/Terminfo.p_hi', needed by `utils/ghc-pkg/dist/build/Main.o'.  Stop.



On Jul 9, 2014, at 2:27 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:

Michael Jones <mike@proclivis.com> writes:

I am having problems building a GHC cross compiler for Linux (Yocto on
a Wandboard) running on a Cortex A9, and need some advice on how to
debug it.

Sorry for the delay, almost overlooked this one!

The cross compiler produces an executable that runs on the Target, but
fails to print. So I need help coming up with a strategy to narrow
down the root cause.

Some details:

The application:

main = do
   putStrLn "Haskell start"


The command line options work. The program runs, and I can step
through assembly. Debug data is printed to the console. But putStrLn
fails, and program enters an infinite loop.

Hmmm, very peculiar. I would probably begin by compiling with `-auto-all
-caf-all -prof` and run the resulting executable with `+RTS -xc`. SIGINT
the process after a second or so and see what the backtrace looks like.

While worth trying, this probably won't help too much as your problem is
likely RTS-related. You might try stracing the executable and see if it
is ever even trying a syscall.

Unfortunately, I doubt it is as the program appears to be hitting heap
and stack overflows. This is quite perplexing. I'm going to try to
reproduce the issue on my end.

Cheers,

- Ben