I ran the same program on my dev linux and compared it to see if there were
clues.
On my dev box (Ubuntu) here are some snippets of the log (working app)
new task (taskCount: 1)
cap 0: created thread 1
new bound thread (1)
cap 0: schedule()
cap 0: running thread 1 (ThreadRunGHC)
New weak
To be complete, there is an old link on compiling for arm, and it recommends
this build process:
$ chmod ugo+rx build-ghc-arm.sh
Edit build-ghc-arm.sh to fix EOF
$ ./build-ghc-arm.sh -j4
$ make test
$ sudo make install
$ arm-poky-linux-gnueabi-ghc --info
This way of building produces the same
IIRC, CFLAGS should be needed only for configure which should detect
your architecture well and generate appropriate settings file. GHC
itself should not use them IIRC. If you need something special, then you
can use mk/build.mk
But I'm not expert for cross-compiling GHC, nor for
On 08/ 2/14 07:04 AM, Michael Jones wrote:
,(target arch,ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI =
HARD})
,(target word size,4)
this looks good, but I hope you got it on clean tree, i.e. without your
configure hack...
Karel
Karel,
My configure hack is now limited to two hacks on GHC 7.8.3. The vendor “pokey,
and the ARM settings that make the target architecture correct. I also enabled
profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean.
I am getting a stack overflow during execution
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.
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,
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
Karel,
I was able to get GHC to compile by rebuilding the gcc cross compiler using
—with-arch= and —with-tune=
However, it is not a satisfactory solution, because if a gcc toolchain uses
multilibs, adding those options does not make sense. In the case of the Yocto
toolchain, it does not use
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
On 07/12/14 07:27 AM, Michael Jones wrote:
Karel,
I have failed to figure out how to make this happen:
(target arch, ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI =
HARD}”)
This is result of running ./configure on arm/ubuntu12.04 -- so I don't
cross-compile, but rather compile
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!
I'm not sure if this is already solved, but if you cross-compile to A9,
why do you use ARMv5 platform OS?
(target arch,ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD})
this looks really strange. armABI HARD, that means FP data in FP regs,
still no VFP in armISAExt and even armISA
Karel,
Not solved yet, but I did not notice the target problem. It is obvious once
pointed out. I’ll try to fix that and try again and report back.
Thanks,
Mike
On Jul 11, 2014, at 4:35 AM, Karel Gardas karel.gar...@centrum.cz wrote:
I'm not sure if this is already solved, but if you
Karel,
I have failed to figure out how to make this happen:
(target arch, ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI =
HARD}”)
I have added poky to the list of vendors in aclocal.m4 then configured like
this:
/configure --target=arm-poky-linux-gnueabi
Michael Jones m...@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
hrmmm, i seem to recall it being said that you need to use the GOLD linker
on ARM. (i think some of this is detailed in
http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html )
,(ld command,arm-poky-linux-gnueabi-ld)
is that GOLD?
On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones
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.
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
could you share the output of ghc --info?
On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones m...@proclivis.com wrote:
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.
The cross compiler produces
I am pasting both the info from the HOST and TARGET compilers:
HOST
[(Project name,The Glorious Glasgow Haskell Compilation System)
,(GCC extra via C opts, -fwrapv)
,(C compiler command,/usr/bin/gcc)
,(C compiler flags, -fno-stack-protector -Wl,--hash-size=31
20 matches
Mail list logo
