Hi, find ghc's generated settings file. What FPU is used there? Thanks, Karel On 01/ 9/13 09:47 PM, roconnor@theorem.ca wrote:

Thanks for the advice; However, it had little effect.

I now have the errors:

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1

Anyone else building GHC on a pi?

On Tue, 8 Jan 2013, Thijs Alkemade wrote:

...

Op 8 jan. 2013, om 05:16 heeft roconnor@theorem.ca het volgende geschreven:

...

On Thu, 3 Jan 2013, Thijs Alkemade wrote:

...

I believe I had the same problem, which disappeared after upgrading llvm from 3.0 to 3.1, and using that instead for ./configure.

Hope this helps, Thijs

Thanks, using LLVM 3.1 seems to have improved the siutation, but I'm running into a new error.

Here is the error I get when trying to build GHC 7.6.1 from 7.4.1

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cjjbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1

I get similar errors when building GHC 7.4.1 (patched with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-...).

Any of you encountered this problem before?

Yeah, I had a lot of these. The problem was that GHC has a lot of different "CFLAGS", so finding the right way to pass "-float-abi=hard" to every one of them took some time, but eventually I ended up with the following change to mk/build.mk:

ifeq "$(BuildFlavour)" "quick"

SRC_HC_OPTS = -H64m -O0 -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -fasm GhcLibHcOpts = -O -fasm -optlc-float-abi=hard SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO

endif

(Change the build flavor you are using, of course)

And I ran configure as:

LDFLAGS="-marm -mfloat-abi=hard -mfpu=vfp" CFLAGS="-marm -mfloat-abi=hard -mfpu=vfp" ./configure --with-opt=/usr/bin/opt-3.1 --with-llc=/usr/bin/llc-3.1 --with-ld=`which ld.gold`

(I switched to the gold linker, because ld was running out of RAM often.)

I did eventually finish building stage2, but the final executable segfaulted on start. I haven't investigated much why that happened, the days it takes to rebuild it just made me give up.

Hope this helps, Thijs

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here... I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again... Cheers, Karel On 01/10/13 03:11 AM, roconnor@theorem.ca wrote:

This is the settingings file:

$ cat settings [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads"), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchARM {armISA = ARMv6, armISAExt = [], armABI = HARD}"), ("target word size", "4"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("LLVM llc command", "/home/pi/.nix-profile/bin/llc"), ("LLVM opt command", "/home/pi/.nix-profile/bin/opt") ]

On Wed, 9 Jan 2013, Karel Gardas wrote:

...

Hi,

find ghc's generated settings file. What FPU is used there?

Thanks, Karel

On 01/ 9/13 09:47 PM, roconnor@theorem.ca wrote:

...

Thanks for the advice; However, it had little effect.

I now have the errors:

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1

Anyone else building GHC on a pi?

On Tue, 8 Jan 2013, Thijs Alkemade wrote:

...

Op 8 jan. 2013, om 05:16 heeft roconnor@theorem.ca het volgende geschreven:

...

On Thu, 3 Jan 2013, Thijs Alkemade wrote:

...

I believe I had the same problem, which disappeared after upgrading llvm from 3.0 to 3.1, and using that instead for ./configure.

Hope this helps, Thijs

Thanks, using LLVM 3.1 seems to have improved the siutation, but I'm running into a new error.

Here is the error I get when trying to build GHC 7.6.1 from 7.4.1

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cjjbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1

I get similar errors when building GHC 7.4.1 (patched with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-...).

Any of you encountered this problem before?

Yeah, I had a lot of these. The problem was that GHC has a lot of different "CFLAGS", so finding the right way to pass "-float-abi=hard" to every one of them took some time, but eventually I ended up with the following change to mk/build.mk:

ifeq "$(BuildFlavour)" "quick"

SRC_HC_OPTS = -H64m -O0 -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -fasm GhcLibHcOpts = -O -fasm -optlc-float-abi=hard SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO

endif

(Change the build flavor you are using, of course)

And I ran configure as:

LDFLAGS="-marm -mfloat-abi=hard -mfpu=vfp" CFLAGS="-marm -mfloat-abi=hard -mfpu=vfp" ./configure --with-opt=/usr/bin/opt-3.1 --with-llc=/usr/bin/llc-3.1 --with-ld=`which ld.gold`

(I switched to the gold linker, because ld was running out of RAM often.)

I did eventually finish building stage2, but the final executable segfaulted on start. I haven't investigated much why that happened, the days it takes to rebuild it just made me give up.

Hope this helps, Thijs

On 01/11/13 09:25 PM, roconnor@theorem.ca wrote:

On Thu, 10 Jan 2013, Karel Gardas wrote:

...

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

Add it to the GhcLibHcOpts?

Probably too, I'm not the expert here, just make sure you use this option for any ghc invocation which invokes llc to get consistent vfp usage in your object files... Once you test it and if succeed we can hack ghc to support it. Karel

What version of GHC did you build? On Sat, 12 Jan 2013, Ben Gamari wrote:

Karel Gardas <karel.gardas@centrum.cz> writes:

...

On 01/11/13 09:25 PM, roconnor@theorem.ca wrote:

...

On Thu, 10 Jan 2013, Karel Gardas wrote:

...

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

Add it to the GhcLibHcOpts?

Probably too, I'm not the expert here, just make sure you use this option for any ghc invocation which invokes llc to get consistent vfp usage in your object files...

I've been struggling with this class of error recently as well.

After several failed builds I arrived at the following on my Pandaboard,

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-float-abi=hard -optlc-mcpu=cortex-a9

I've found it's best to set both gcc and llc arguments as they tend to disagree when you least expect it. I'm not sure whether SRC_HC_OPTS is too large a hammer, but it seems to work for me.

Cheers,

- Ben

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Sat, 12 Jan 2013, Ben Gamari wrote:

roconnor@theorem.ca writes:

...

What version of GHC did you build?

This was building from the ghc-7.4 branch. That being said, after this build finished I noticed that the resulting stage 2 compiler wasn't invoking llc with the correct parameters, resulting in the same linker error when doing builds.

This might have been due to the fact that I changed `build.mk` several times mid-build. I'm currently waiting for a clean rebuild. However, I'm now using a more specific configuration as passing `-optlc-float-abi=hard` in `HC_SRC_OPTS` caused the stage 0 build to fail with,

... *** LLVM Compiler: 'llc-3.0' '-O1' '-relocation-model=static' '/tmp/ghc25792_0/ghc25792_0.bc' '-o' '/tmp/ghc25792_0/ghc25792_0.lm_s' '-float-abi=hard' '-mcpu=cortex-a9' '-mattr=+v7,+vfp3,+d16' '-float-abi=hard' llc-3.0: for the -float-abi option: may only occur zero or one times!

I'm not really sure where this second `-float-abi=hard` is coming from, but using the following in `build.mk` works around the issue,

SRC_HC_OPTS = -H64m -Rghc-timing GhcStage1HcOpts = -O -fvia-C GhcStage2HcOpts = -O0 -fllvm -keep-llvm-files -debug -DDEBUG -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-float-abi=hard -optlc-mcpu=cortex-a9 GhcLibHcOpts = -O -fllvm -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-float-abi=hard -optlc-mcpu=cortex-a9

You've written "-optc-mfloat-abi=hard -optc-mcpu=cortex-a9" twice in your GhcLibHcOpts. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Sat, Jan 12, 2013 at 10:29 PM, Austin Seipp <mad.one@gmail.com> wrote:

The first one passes the options onto LLVM's code generator tool, 'llc', so it also gets the ABI options right.

s/first/second/ -- Regards, Austin

On Sun, 13 Jan 2013, Neil Davies wrote:

Sounds like we're close - I must admit I've slightly lost track of the things that need to be done.

Can we start collecting the pre-conditionds and steps, when each complete build takes best part of a day, its difficult to keep the context.

So - taking the ghc 7.4.1 that is part of raspian wheezy (pkg version 7.4.1-4+rpi1) which depends upon (amongst others) llvm-3.0 (pkg version 3.0-10), can we capture the changes?

Which version of LLVM is being used?

I'm using LLVM 3.1 and gcc 4.6.3 and ghc 7.4.1.

Which ghc source(s) are you starting from?

ghc-7.6.1 with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-... applied, fixing the hunks in compiler/main/DriverPipeline.hs by hand.

What files did you need to touch in the make process? Please supply diffs

I've been fiddling with various parmameters in mk/build.mk.

Anything else?

I haven't got it compiling yet. Oh I'm currently using the raspian distriubtion with uses the hard-float ABI, but my end-goal is to bootstrap a nix package. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

roconnor@theorem.ca writes:

On Sat, 12 Jan 2013, Ben Gamari wrote:

...

SRC_HC_OPTS = -H64m -Rghc-timing GhcStage1HcOpts = -O -fvia-C GhcStage2HcOpts = -O0 -fllvm -keep-llvm-files -debug -DDEBUG -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-float-abi=hard -optlc-mcpu=cortex-a9 GhcLibHcOpts = -O -fllvm -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-float-abi=hard -optlc-mcpu=cortex-a9

You've written "-optc-mfloat-abi=hard -optc-mcpu=cortex-a9" twice in your GhcLibHcOpts.

Not quite, one is -optc (apparently passed to gcc) and the other is -optlc (passed to llc). Cheers, - Ben

I've tried to build 6.12.3, 7.4.1, 7.4.2, and 7.6.1, with a few various patches, and I'm stuck in the final stage with errors like: /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not I'm rebuilding with Karel's latest suggestion now. On Sat, 12 Jan 2013, Neil Davies wrote:

Hi

I've found myself wanting to get GHC 7.4.2 (need TemplateHaskell for something) working on the rapberry pi - can you (or anyone out there) share where you are at?

My starting point is the raspian image of 2012-12-18-wheezy-raspian that has GHC 7.4.1 on it...

Neil

On 11 Jan 2013, at 20:25, roconnor@theorem.ca wrote:

...

On Thu, 10 Jan 2013, Karel Gardas wrote:

...

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

Add it to the GhcLibHcOpts?

...

Cheers, Karel

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Thu, 10 Jan 2013, Karel Gardas wrote:

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

Done. What would you like to see? -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Thu, 10 Jan 2013, Karel Gardas wrote:

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

No change with SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm I still get the error: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get: $ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory What is make really doing here? My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Mon, 14 Jan 2013, Thijs Alkemade wrote:

Op 14 jan. 2013, om 17:30 heeft roconnor@theorem.ca het volgende geschreven:

...

On Thu, 10 Jan 2013, Karel Gardas wrote:

...

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

No change with

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm

I still get the error:

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o

I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get:

$ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory

What is make really doing here?

My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from.

libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is the output ld was asked to generate. Apparently, some of the input .o files didn't use VFP register arguments, so ld concluded that the output should also not use VFP register arguments. But then ld encountered a .o file that did use VFP register arguments, and threw an error (something in cbits, so probably built with different CFLAGS).

From your flags I'd say you miss -optlc-float-abi=hard. I had it in GhcLibHcOpts, but I'm not sure that is the correct way to ensure it is passed to everything exactly once.

Okay, I tried: SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/HSCParser.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/HSCParser.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/DirectCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/DirectCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/CrossCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/CrossCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/UtilsCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/UtilsCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Common.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Common.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/C.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/C.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Flags.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Flags.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Paths_hsc2hs.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Apply.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Apply.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Exception.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Exception.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(HeapStackCheck.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(HeapStackCheck.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(PrimOps.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(PrimOps.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgMiscClosures.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgMiscClosures.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStartup.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStartup.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStdThunks.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStdThunks.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Updates.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Updates.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(AutoApply.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(AutoApply.o) collect2: ld returned 1 exit status <<ghc: 10689448 bytes, 2 GCs, 95944/95944 avg/max bytes residency (1 samples), 62M in use, 0.00 INIT (0.00 elapsed), 0.81 MUT (9.41 elapsed), 0.13 GC (0.13 elapsed) :ghc>> make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2 -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Tue, 15 Jan 2013, Thijs Alkemade wrote:

Op 15 jan. 2013, om 17:36 heeft roconnor@theorem.ca het volgende geschreven:

...

Okay, I tried:

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard

and I got the same error at a different build step. I'm not sure if it is earlier or later.

It seems still not everything is using the hard-float ABI.

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o ...

Did you do a `make clean` first? If not, try removing just (some of) the offending .o files, and see if rebuilding just those results in the same error.

I did a make clean first I'm afarid. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

Hi - would another RPi (or even 2 from tomorrow another one arriving) help? I can make them accessible (i.e. in our DMZ) - Neil On 15 Jan 2013, at 16:36, roconnor@theorem.ca wrote:

On Mon, 14 Jan 2013, Thijs Alkemade wrote:

...

Op 14 jan. 2013, om 17:30 heeft roconnor@theorem.ca het volgende geschreven:

...

On Thu, 10 Jan 2013, Karel Gardas wrote:

...

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

No change with

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm

I still get the error:

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o

I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get:

$ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory

What is make really doing here?

My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from.

libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is the output ld was asked to generate. Apparently, some of the input .o files didn't use VFP register arguments, so ld concluded that the output should also not use VFP register arguments. But then ld encountered a .o file that did use VFP register arguments, and threw an error (something in cbits, so probably built with different CFLAGS).

From your flags I'd say you miss -optlc-float-abi=hard. I had it in GhcLibHcOpts, but I'm not sure that is the correct way to ensure it is passed to everything exactly once.

Okay, I tried:

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard

and I got the same error at a different build step. I'm not sure if it is earlier or later.

It seems still not everything is using the hard-float ABI.

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/HSCParser.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/HSCParser.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/DirectCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/DirectCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/CrossCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/CrossCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/UtilsCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/UtilsCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Common.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Common.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/C.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/C.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Flags.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Flags.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Paths_hsc2hs.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Apply.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Apply.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Exception.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Exception.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(HeapStackCheck.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(HeapStackCheck.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(PrimOps.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(PrimOps.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgMiscClosures.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgMiscClosures.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStartup.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStartup.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStdThunks.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStdThunks.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Updates.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Updates.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(AutoApply.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(AutoApply.o) collect2: ld returned 1 exit status <<ghc: 10689448 bytes, 2 GCs, 95944/95944 avg/max bytes residency (1 samples), 62M in use, 0.00 INIT (0.00 elapsed), 0.81 MUT (9.41 elapsed), 0.13 GC (0.13 elapsed) :ghc>> make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Well, if you make some board available in DMZ I'm certainly interested to run at least configure on it from GHC HEAD to see what we need to hack in order to add support for RPi into GHC HEAD. Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build, but Austin is working on this. I think I can hack support for RPi in the meantime for testing later on fixed GHC HEAD LLVM build... Karel On 01/15/13 06:07 PM, roconnor@theorem.ca wrote:

In theory we could try a couple variations of builds at the same time. But at the moment, I'm running low on ideas on what to try.

I just got the, extensive, raspbian patches for 7.4.1 and I'm going to browse through them when I get time (apt-get source ghc).

On Tue, 15 Jan 2013, Neil Davies wrote:

...

Hi - would another RPi (or even 2 from tomorrow another one arriving) help?

I can make them accessible (i.e. in our DMZ) -

Neil

On 15 Jan 2013, at 16:36, roconnor@theorem.ca wrote:

...

On Mon, 14 Jan 2013, Thijs Alkemade wrote:

...

Op 14 jan. 2013, om 17:30 heeft roconnor@theorem.ca het volgende geschreven:

...

On Thu, 10 Jan 2013, Karel Gardas wrote:

...

Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here...

I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again...

No change with

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm

I still get the error:

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o

I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get:

$ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory

What is make really doing here?

My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from.

libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is the output ld was asked to generate. Apparently, some of the input .o files didn't use VFP register arguments, so ld concluded that the output should also not use VFP register arguments. But then ld encountered a .o file that did use VFP register arguments, and threw an error (something in cbits, so probably built with different CFLAGS).

From your flags I'd say you miss -optlc-float-abi=hard. I had it in GhcLibHcOpts, but I'm not sure that is the correct way to ensure it is passed to everything exactly once.

Okay, I tried:

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard

and I got the same error at a different build step. I'm not sure if it is earlier or later.

It seems still not everything is using the hard-float ABI.

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/HSCParser.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/HSCParser.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/DirectCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/DirectCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/CrossCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/CrossCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/UtilsCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/UtilsCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Common.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Common.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/C.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/C.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Flags.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Flags.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Paths_hsc2hs.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Apply.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Apply.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Exception.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Exception.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(HeapStackCheck.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(HeapStackCheck.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(PrimOps.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(PrimOps.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgMiscClosures.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgMiscClosures.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStartup.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStartup.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStdThunks.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(StgStdThunks.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Updates.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(Updates.o) /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(AutoApply.o) does not /usr/bin/ld: failed to merge target specific data of file /tmp/ghc-7.6.1b/rts/dist/build/libHSrts.a(AutoApply.o) collect2: ld returned 1 exit status <<ghc: 10689448 bytes, 2 GCs, 95944/95944 avg/max bytes residency (1 samples), 62M in use, 0.00 INIT (0.00 elapsed), 0.81 MUT (9.41 elapsed), 0.13 GC (0.13 elapsed) :ghc>> make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 01/15/13 08:56 PM, Thijs Alkemade wrote:

Op 15 jan. 2013, om 18:16 heeft Karel Gardas<karel.gardas@centrum.cz> het volgende geschreven:

...

Well, if you make some board available in DMZ I'm certainly interested to run at least configure on it from GHC HEAD to see what we need to hack in order to add support for RPi into GHC HEAD.

Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build, but Austin is working on this. I think I can hack support for RPi in the meantime for testing later on fixed GHC HEAD LLVM build...

Karel

This might be helpful, it's a guide to emulate a raspberry pi using qemu, which I was using to (try to) build GHC:

http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/

While I haven't done any real measurements, it seemed somewhat faster too on my machine.

Indeed, that may be the way. The other may be to debootstrap rasbian into ubuntu chroot on ARMv7 machine for example. I'm curious what configure will report then, i.e. if this will look really like ARMv6 or ARMv7 at the end... Also 1 GHz OMAP4 is still faster in executing ARm code than Qemu/ARM running on my Intel box... :-) Karel

Guys, I've installed raspbian into ubuntu chroot on my panda. Now to simulate what GHC detects on your hardware, could you be so kind and send me output of: uname -m uname -r uname -s uname -v this looks like a needed info for config.guess to detect machine hardware well. Also if you send me output of: sh config.guess it would be great. Everything of course run on your rpi board! Thanks, Karel

Good! So the patch I already provided is working fine at least w.r.t. change in configure. I've tested it here on my raspbian chroot on pandaboard where I've hacked config.guess to print exactly what you get on real rpi. Now, I'm curious if the hack in DriverPipeline.hs helps too. Were you able to merge the patch into your GHC? And rebuild? What was the result? Thanks, Karel On 01/16/13 08:02 PM, roconnor@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:

...

Guys,

I've installed raspbian into ubuntu chroot on my panda. Now to simulate what GHC detects on your hardware, could you be so kind and send me output of:

uname -m

armv6l

...

uname -r

3.6.11+

...

uname -s

Linux

...

uname -v

#346 PREEMPT Fri Dec 28 00:50:33 GMT 2012

...

this looks like a needed info for config.guess to detect machine hardware well.

Also if you send me output of:

sh config.guess

armv6l-unknown-linux-gnueabihf

...

it would be great.

Everything of course run on your rpi board!

Thanks, Karel

On 01/16/13 08:12 PM, roconnor@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:

...

Good! So the patch I already provided is working fine at least w.r.t. change in configure. I've tested it here on my raspbian chroot on pandaboard where I've hacked config.guess to print exactly what you get on real rpi.

Now, I'm curious if the hack in DriverPipeline.hs helps too.

Were you able to merge the patch into your GHC? And rebuild? What was the result?

I'm still trying to figure out the correct usage of -optlc-float-abi=hard in mk/build.mk. I've ben getting a lot of errors about two occurances of the float-abi=hard flag.

You should not IMHO. My patch should solve all your issues. :-) The only issue you may get is that your distro ghc will compile for soft-float ABI and your compiled GHC will compile to hard-float and object files will get mixed somewhere. But I trust your distro ghc builders that this is not the case so both GHCs should compile using hard-float. So issue solved, at least should be. Now I'm just waiting if you verify this or not so I'm either able to submit the patch for inclusion or hack it more... Karel

There have been a few of these bugs recently it seems. If you could: use the stage1 compiler to compile a simple executable, like 'main = return ()' or hello world or whatever. The stage1 compiler can be located in the build directory, under 'inplace/bin/ghc-stage1'. So something like: <GHC BUILD>/inplace/bin/ghc-stage1 -fforce-recomp hello_world.hs Check if the output executable crashes immediately. If it does, then it is likely a miscompilation of the runtime or libraries somewhere. Otherwise, we'll have to narrow down another way. If it does fail, please use GDB on the executable, and give a backtrace from the crash (using the 'bt' command, after the program has crashed.) You can also try linking with the debug RTS, by passing the -debug and -rtsopts flag to ghc-stage1. Then run again, and see if something else was tripped. You can see all the sanity checks you can enable, if you run the executable using './program.exe +RTS --help'. The debug flags are named things like '-Ds' and '-Da', etc and should be passed to the RTS. On Thu, Jan 17, 2013 at 1:11 PM, <roconnor@theorem.ca> wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:

...

On 01/16/13 08:12 PM, roconnor@theorem.ca wrote:

...

On Wed, 16 Jan 2013, Karel Gardas wrote:

...

Good! So the patch I already provided is working fine at least w.r.t. change in configure. I've tested it here on my raspbian chroot on pandaboard where I've hacked config.guess to print exactly what you get on real rpi.

Now, I'm curious if the hack in DriverPipeline.hs helps too.

Were you able to merge the patch into your GHC? And rebuild? What was the result?

I'm still trying to figure out the correct usage of -optlc-float-abi=hard in mk/build.mk. I've ben getting a lot of errors about two occurances of the float-abi=hard flag.

You should not IMHO. My patch should solve all your issues. :-) The only issue you may get is that your distro ghc will compile for soft-float ABI and your compiled GHC will compile to hard-float and object files will get mixed somewhere. But I trust your distro ghc builders that this is not the case so both GHCs should compile using hard-float. So issue solved, at least should be. Now I'm just waiting if you verify this or not so I'm either able to submit the patch for inclusion or hack it more...

The first run of the stage2 compilier fails with a segfault:

HC [stage 2] utils/ghctags/dist-install/build/Main.o /bin/sh: line 1: 30064 Segmentation fault "inplace/bin/ghc-stage2" -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -iutils/ghctags/dist-install/build/autogen -Iutils/ghctags/dist-install/build -Iutils/ghctags/dist-install/build/autogen -package ghc -no-user-package-db -rtsopts -odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -hisuf hi -osuf o -hcsuf hc -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.o make[1]: *** [utils/ghctags/dist-install/build/Main.o] Error 139

make: *** [all] Error 2

using

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Regards, Austin

On Thu, 17 Jan 2013, roconnor@theorem.ca wrote:

On Thu, 17 Jan 2013, Austin Seipp wrote:

...

There have been a few of these bugs recently it seems. If you could: use the stage1 compiler to compile a simple executable, like 'main = return ()' or hello world or whatever.

The stage1 compiler can be located in the build directory, under 'inplace/bin/ghc-stage1'. So something like:

<GHC BUILD>/inplace/bin/ghc-stage1 -fforce-recomp hello_world.hs

Check if the output executable crashes immediately. If it does, then it is likely a miscompilation of the runtime or libraries somewhere. Otherwise, we'll have to narrow down another way.

$ inplace/bin/ghc-stage1 -fforce-recomp /tmp/Main.hs [1 of 1] Compiling Main ( /tmp/Main.hs, /tmp/Main.o ) Linking /tmp/Main ... $ /tmp/Main Segmentation fault

...

If it does fail, please use GDB on the executable, and give a backtrace from the crash (using the 'bt' command, after the program has crashed.)

I'll get back to you on this.

I don't know much about gdb, but $ /usr/bin/gdb /tmp/Main GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/Main...done. (gdb) run Starting program: /tmp/Main [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x003a732c in stg_returnToStackTop () (gdb) quit A debugging session is active. Inferior 1 [process 17097] will be killed. Quit anyway? (y or n) y

...

You can also try linking with the debug RTS, by passing the -debug and -rtsopts flag to ghc-stage1. Then run again, and see if something else was tripped. You can see all the sanity checks you can enable, if you run the executable using './program.exe +RTS --help'. The debug flags are named things like '-Ds' and '-Da', etc and should be passed to the RTS.

-- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Fri, 18 Jan 2013, Karel Gardas wrote:

On 01/18/13 05:49 PM, roconnor@theorem.ca wrote:

...

I don't know much about gdb, but

$ /usr/bin/gdb /tmp/Main GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /tmp/Main...done. (gdb) run Starting program: /tmp/Main [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault. 0x003a732c in stg_returnToStackTop ()

And here you need to use `bt' command to show us a call stack which leads to crash.

(gdb) run Starting program: /tmp/Main [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x003a732c in stg_returnToStackTop () (gdb) bt #0 0x003a732c in stg_returnToStackTop () #1 0x0042f6d0 in MainCapability () #2 0x0042f6d0 in MainCapability () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) quit -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On 01/20/13 07:17 PM, roconnor@theorem.ca wrote:

On Wed, 16 Jan 2013, Karel Gardas wrote:

...

You should not IMHO. My patch should solve all your issues. :-) The only issue you may get is that your distro ghc will compile for soft-float ABI and your compiled GHC will compile to hard-float and object files will get mixed somewhere. But I trust your distro ghc builders that this is not the case so both GHCs should compile using hard-float. So issue solved, at least should be. Now I'm just waiting if you verify this or not so I'm either able to submit the patch for inclusion or hack it more...

I switched to using llvm-3.0 from rasbian, and made a lot of progress. (In retrospect I built llvm-3.1 using nix, and it was in a completely different toolchain than the rest of the build. I should have known that it wouldn't work).

Ehm, building LLVM on your own is always a risky business. See my blog[1] for more details especially find the post where I compare quality of various LLVM builds using various optimization options...

I was able to complete the build of ghc-7.6.1 using Karel's patch and

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

I was able to make binary-dist after doing

mkdir compiler/stage2/doc

However after unpacking the binary distribution and doing a make install I get:

Installing library in /tmp/bindist/lib/ghc-7.6.1/ghc-prim-0.3.0.0 ghc-cabal: Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = }" make[1]: *** [install_packages] Error 1 make: *** [install] Error 2

And in particular the installed ghc gives the error:

$ bin/ghc Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = }"

Sounds to me like Karel's patch is almost, but not quite there.

Looks like you do have corrupted settings file. Recover it by adding "HARD" following "armABI = ", so result should be: ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}" That's all what's needed, honestly speaking I don't know why it's screwed on your board.

Karel, maybe you should try deploying a binary-dist on your panda board?

Sorry? What's "binary-dist"? And why I should do that? And what exactly do you mean by "deploying"? And on what OS? Ubuntu or Raspbian run in Ubuntu chroot? Karel [1]: https://ghcarm.wordpress.com/

On 01/20/13 07:50 PM, roconnor@theorem.ca wrote:

...

...

Karel, maybe you should try deploying a binary-dist on your panda board?

Sorry? What's "binary-dist"? And why I should do that? And what exactly do you mean by "deploying"? And on what OS? Ubuntu or Raspbian run in Ubuntu chroot?

What I'm suggesting is that if you want to try to reproduce my corrupt setting file error and ammend your patch for including in GHC, you should after making ghc-7.6.1 (or whatever version you are building) do a

make binary-dist # this will product a ghc-7.6.1-arm-unknown-linux.tar.bz2 file

extract ghc-7.6.1-arm-unknown-linux.tar.bz2 in some temporary directory.

in that extracted directory run

./configue --prefix=<some temporary directory> make install

Aha, I understand, but could you be so kind and first verify that the settings file you do have inside your build tree is the same exactly like the settings file distributed with your bin dist? If not, then make binary-dist is somehow buggy. If yes, then the configure is buggy and its surprising you've been able to build ghc at all... Sorry, I cannot test it here as my 7.6.1 build on ARM is already gone due to hard-drive space constraints here as it freed space for GHC i386/x64 solaris cross-compilation tests... Thanks, Karel

On Sun, 20 Jan 2013, Karel Gardas wrote:

On 01/20/13 07:17 PM, roconnor@theorem.ca wrote:

...

On Wed, 16 Jan 2013, Karel Gardas wrote:

...

You should not IMHO. My patch should solve all your issues. :-) The only issue you may get is that your distro ghc will compile for soft-float ABI and your compiled GHC will compile to hard-float and object files will get mixed somewhere. But I trust your distro ghc builders that this is not the case so both GHCs should compile using hard-float. So issue solved, at least should be. Now I'm just waiting if you verify this or not so I'm either able to submit the patch for inclusion or hack it more...

I switched to using llvm-3.0 from rasbian, and made a lot of progress. (In retrospect I built llvm-3.1 using nix, and it was in a completely different toolchain than the rest of the build. I should have known that it wouldn't work).

Ehm, building LLVM on your own is always a risky business. See my blog[1] for more details especially find the post where I compare quality of various LLVM builds using various optimization options...

...

I was able to complete the build of ghc-7.6.1 using Karel's patch and

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

I was able to make binary-dist after doing

mkdir compiler/stage2/doc

However after unpacking the binary distribution and doing a make install I get:

Installing library in /tmp/bindist/lib/ghc-7.6.1/ghc-prim-0.3.0.0 ghc-cabal: Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = }" make[1]: *** [install_packages] Error 1 make: *** [install] Error 2

And in particular the installed ghc gives the error:

$ bin/ghc Failed to read "target arch" value "ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = }"

Sounds to me like Karel's patch is almost, but not quite there.

Looks like you do have corrupted settings file. Recover it by adding "HARD" following "armABI = ", so result should be:

ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"

Okay, I patched the settings filed generted by ./configure in the binary-dist and rank make install which completed. However, pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp/bindist $ ./Main Segmentation fault pi@raspberrypi /tmp/bindist $ cat Main.hs main = putStrLn "Hello World." Damn it. So close. I don't know how make install succeded without segfaulting. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Sun, 20 Jan 2013, Karel Gardas wrote:

On 01/20/13 08:27 PM, roconnor@theorem.ca wrote:

...

...

Looks like you do have corrupted settings file. Recover it by adding "HARD" following "armABI = ", so result should be:

ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"

Okay, I patched the settings filed generted by ./configure in the binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp/bindist $ ./Main Segmentation fault pi@raspberrypi /tmp/bindist $ cat Main.hs main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without segfaulting.

Sigh! Go back to your build tree and try the same thing with inplace/bin/ghc-stage2 and let us know if this works or not. BTW: What's in Main.hs?

pi@raspberrypi /tmp $ ghc-7.6.1c/inplace/bin/ghc-stage2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp $ ./Main Hello World. The stage2 compiler works fine inplace. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

On Mon, 21 Jan 2013, Karel Gardas wrote:

On 01/21/13 12:49 AM, roconnor@theorem.ca wrote:

...

On Sun, 20 Jan 2013, Karel Gardas wrote:

...

...

Okay, I patched the settings filed generted by ./configure in the binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp/bindist $ ./Main Segmentation fault pi@raspberrypi /tmp/bindist $ cat Main.hs main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without segfaulting.

Sigh! Go back to your build tree and try the same thing with inplace/bin/ghc-stage2 and let us know if this works or not. BTW: What's in Main.hs?

pi@raspberrypi /tmp $ ghc-7.6.1c/inplace/bin/ghc-stage2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp $ ./Main Hello World.

The stage2 compiler works fine inplace.

OK, so binary-dist not only corrupted your settings file, but also somehow your compiler. Nice to see you are able to get working compiler on your RPi board. Congratulations! :-)

Thanks. :) So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file. I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

FYI, I created a wiki page for cross-compiling to Raspberry Pi: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi I have an unregisterised build using LLVM working now (it just worked, modulo the tiny fix for #7622). Cheers, Simon On 21/01/13 16:06, Karel Gardas wrote:

On 01/21/13 04:43 PM, roconnor@theorem.ca wrote:

...

So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file.

Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch?

...

I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ.

Please post your findings here, I'm really curious what is the culprit here...

Karel

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 25/01/13 11:23, Neil Davies wrote:

Simon

Looking at the wiki - I take it that the stage 1 compiler can now be used as "native" compiler on the RPi? (last line of entry)?

Do you mean the stage 2 compiler? If so yes - in principle. But in practice the binary-dist machinery doesn't work properly for cross-compilers yet, so it's hard to install it on the RPi. If you have a shared network filesystem then perhaps 'make install' works, or if you copy the build tree to your RPi at the same location as your build machine, then maybe it will work. Cheers, Simon

Neil

On 25 Jan 2013, at 10:46, Simon Marlow <marlowsd@gmail.com> wrote:

...

FYI, I created a wiki page for cross-compiling to Raspberry Pi:

http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi

I have an unregisterised build using LLVM working now (it just worked, modulo the tiny fix for #7622).

Cheers, Simon

On 21/01/13 16:06, Karel Gardas wrote:

...

On 01/21/13 04:43 PM, roconnor@theorem.ca wrote:

...

So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file.

Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch?

...

I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ.

Please post your findings here, I'm really curious what is the culprit here...

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

On Mon, 21 Jan 2013, roconnor@theorem.ca wrote:

On Mon, 21 Jan 2013, Karel Gardas wrote:

...

On 01/21/13 12:49 AM, roconnor@theorem.ca wrote:

...

On Sun, 20 Jan 2013, Karel Gardas wrote:

...

...

Okay, I patched the settings filed generted by ./configure in the binary-dist and rank make install which completed. However,

pi@raspberrypi /tmp/bindist $ bin/ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp/bindist $ ./Main Segmentation fault pi@raspberrypi /tmp/bindist $ cat Main.hs main = putStrLn "Hello World."

Damn it. So close. I don't know how make install succeded without segfaulting.

Sigh! Go back to your build tree and try the same thing with inplace/bin/ghc-stage2 and let us know if this works or not. BTW: What's in Main.hs?

pi@raspberrypi /tmp $ ghc-7.6.1c/inplace/bin/ghc-stage2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... pi@raspberrypi /tmp $ ./Main Hello World.

The stage2 compiler works fine inplace.

OK, so binary-dist not only corrupted your settings file, but also somehow your compiler. Nice to see you are able to get working compiler on your RPi board. Congratulations! :-)

Thanks. :)

So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file.

I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ.

I replaced the lib/ghc-7.6.1/settings built from the binary-dist which read: [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector "), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "@ArSupportsAtFile@"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"), ("target word size", "4"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] With the settings file from the build: [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads"), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("perl command", "/usr/bin/perl"), ("target os", "OSLinux"), ("target arch", "ArchARM {armISA = ARMv6, armISAExt = [VFPv2], armABI = HARD}"), ("target word size", "4"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("LLVM llc command", "/usr/bin/llc-3.0"), ("LLVM opt command", "/usr/bin/opt-3.0") ] and now ghc builds executables that do not segfault! It seem that the configure program in the binary-dist needs some patching. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

roconnor@theorem.ca writes:

Okay, I tried:

SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard

and I got the same error at a different build step. I'm not sure if it is earlier or later.

It seems still not everything is using the hard-float ABI.

===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o

I found this as well and have been unable to figure out what in the build system needs to be tweaked. This is ultimately where I gave up on 7.4. Anyone have any ideas what flags this is built with? It seems that neither GhcStage2HcOpts nor GhcLibHcOpts make it to the compiler here, "inplace/bin/ghc-stage1" -H64m -Rghc-timing -v -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2 hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.5.1.0 -package containers-0.4.2.1 -package directory-1.1.0.2 -package process-1.1.0.1 -X Haskell98 -XCPP -XForeignFunctionInterface -no-user-package-conf -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./Main.hs -o utils/hsc2hs/dist-install/build/Main.o Cheers, - Ben