date:20130115

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Karel Gardas


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


Op 15 jan. 2013, om 18:16 heeft Karel Gardas  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



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

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Thijs Alkemade


Op 15 jan. 2013, om 18:16 heeft Karel Gardas  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.

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

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Karel Gardas



Well, just wild guessing what's needed on RPi, but could you who do have 
this board attempt to use attached patch? Don't forget to ./boot as this 
change configure. Also testing it on completely clean tree may be wise 
idea. Also after configure run please check that you do have VFPv2 in 
the ext list. -- this is indeed a wild guess for ARMv6, but as we do the 
same for ARMv7 (guessing VFPv3) I don't think this is show-stopper now...


Please let me know if this is working...

Karel

On 01/15/13 06:25 PM, Ben Gamari wrote:

rocon...@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

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



diff --git a/aclocal.m4 b/aclocal.m4
index 127f528..a2db986 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -356,7 +356,7 @@ AC_DEFUN([GET_ARM_ISA],
 [AC_DEFINE(arm_HOST_ARCH_PRE_ARMv7, 1, [ARM pre v7])
  changequote(, )dnl
  ARM_ISA=ARMv6
- ARM_ISA_EXT="[]"
+ ARM_ISA_EXT="[VFPv2]"
  changequote([, ])dnl
 ],
 [changequote(, )dnl
diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs
index b128c1f..c71546c 100644
--- a/compiler/main/DriverPipeline.hs
+++ b/compiler/main/DriverPipeline.hs
@@ -1453,14 +1453,17 @@ runPhase LlvmLlc input_fn dflags
   else if (elem VFPv3D16 ext)
then ["-mattr=+v7,+vfp3,+d16"]
else []
+   ArchARM ARMv6 ext _ -> if (elem VFPv2 ext)
+  then ["-mattr=+v6,+vfp2"]
+  else ["-mattr=+v6"]
_ -> []
 -- On Ubuntu/Debian with ARM hard float ABI, LLVM's llc still
 -- compiles into soft-float ABI. We need to explicitly set abi
 -- to hard
 abiOpts = case platformArch (targetPlatform dflags) of
-ArchARM ARMv7 _ HARD -> ["-float-abi=hard"]
-ArchARM ARMv7 _ _-> []
-_-> []
+ArchARM _ _ HARD -> ["-float-abi=hard"]
+ArchARM _ _ _-> []
+_-> []
 
 -
 -- LlvmMangle phase
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Ben Gamari

rocon...@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

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

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Karel Gardas



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, rocon...@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, rocon...@theorem.ca wrote:


On Mon, 14 Jan 2013, Thijs Alkemade wrote:


Op 14 jan. 2013, om 17:30 heeft rocon...@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: faile

Re: Error building ghc on raspberry pi.

2013-01-15 Thread roconnor

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, rocon...@theorem.ca wrote:


On Mon, 14 Jan 2013, Thijs Alkemade wrote:


Op 14 jan. 2013, om 17:30 heeft rocon...@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/tm

Re: Error building ghc on raspberry pi.

2013-01-15 Thread roconnor


On Tue, 15 Jan 2013, Thijs Alkemade wrote:



Op 15 jan. 2013, om 17:36 heeft rocon...@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  
``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

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Neil Davies

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, rocon...@theorem.ca wrote:

> On Mon, 14 Jan 2013, Thijs Alkemade wrote:
> 
>> Op 14 jan. 2013, om 17:30 heeft rocon...@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/hsc

Re: Error building ghc on raspberry pi.

2013-01-15 Thread Thijs Alkemade


Op 15 jan. 2013, om 17:36 heeft rocon...@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.

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

Re: Error building ghc on raspberry pi.

2013-01-15 Thread roconnor


On Mon, 14 Jan 2013, Thijs Alkemade wrote:


Op 14 jan. 2013, om 17:30 heeft rocon...@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 VF

Re: Newtype wrappers

2013-01-15 Thread Joachim Breitner

Hi,

Am Montag, den 14.01.2013, 18:09 + schrieb Simon Peyton-Jones:
> I’d appreciate
> 
> ·A sense of whether you care. Does this matter?
> ·Improvements to the design I propose

I do care (but that is no news, given my pestering on #2110 :-)) and
obviously I am happy that things are moving.

What I am still missing here is a way for a container library writer to
say:
"map Age" may be compiled to a noop if foo is known to be a
newtype constructor or deconstructor

With the current proposal, the _user_ of a library has to 
 * know that types Age and Int are actually equivalent
 * introduce and give a name to the [Age] -> [Int] wrapper
 * use it wherever "map Age" is used

The last step can probably replaced by a RULE. But note that all three
steps are a burden on the _user_ of the newtype and the container type
(which most likely come from different libraries). Also, the first step
is a clear breach of abstraction: The user should not have to know
whether Age is a newtype or not, at least not until he wants to actively
work on performance problems, and even then code should not break if a
library switches from newtype to data.

Maybe it is possible to implement this it on top of the current
proposal: How can the author of a container tell the compiler that "map
Foo" or "map unFoo" are safe to be replaced by coercions.

One might argue that this yields unpredictable performance. But it is no
different than other successful tools like list fusion: There, as well,
only the authors of different components need to set up the
corresponding RULES. The user can combine independently developed
functions and they will possibly fuse. And the user does not really know
when and where fusion happens, or what list fusion is, but he knows that
generally, good things happen (just as he expects newtypes to be
generally free) and if he needs to know more, he’ll have to read the
core.

But maybe what I am looking for is not a language feature but a core
compiler pass, analyzing the actual code of functions like map and
discovering that "map Age = [AgeNTC]" is a safe rule.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
  m...@joachim-breitner.de  |  nome...@debian.org  |  GPG: 0x4743206C
  xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Newtype wrappers

2013-01-15 Thread Simon Peyton-Jones

| If you as the library writer don't want to allow unsafe things, then
| don't export the constructor.  Then no one can break your invariants,
| even with newtype malarky.  If you as the the library user go and
| explicitly import the bare Set constructor from (theoretical)
| Data.Set.Unsafe, then you are in the position to break Set's internal
| invariants anyway, and have already accepted the great power / great
| responsibility tradeoff.

I think that there are two separate things going on here, and that's why the 
discussion is confusing.

Suppose we have

module Map( ... ) where
  data Map a b = ...blah blah...

module Age( ... ) where
  newtype Age = MkAge Int

Now suppose we want a newtype wrapper like this

import Map
import Age

newtype wrap foo :: Map Int Bool -> Map Age Bool

Could we write 'foo' by hand? (This is a good criterion, I think.) Only if we 
could see the data constructors of *both* Map *and* Age. In my earlier brief 
message I was only thinking about the 'Age' type, and forgetting about 'Map'.

- If we can't see the data constructor of 'Age' we might miss an invariant that 
Ages are supposed to have.   For example, they might be guaranteed positive.

- If we can't see the data constructors of 'Map', we might miss an invariant of 
Maps. For example, maybe Map is represented as a list of pairs, ordered by the 
keys.  Then, if 'Age' orders in the reverse way to 'Int', it would obviously be 
bad to substitute.

Invariants like these are difficult to encode in the type system, so we use 
"exporting the constructors" as a proxy for "I trust the importer to maintain 
invariants".  The "Internals" module name convention is a signal that you must 
be particularly careful when importing this module; runtime errors may result 
if you screw up.

One possible conclusion: if we have them at all, newtype wrappers should only 
work if you can see the constructors of *both* the newtype, *and* the type you 
are lifting over.  

But that's not very satisfactory either.  

* There are some times (like IO) where it *does* make perfect sense 
  to lift newtypes, but where we really don't want to expose 
  the representation. 

* Actually 'Map' is also a good example: while Map Age Bool should 
  not be converted to Map Int Bool, it'd be perfectly fine to convert 
  Map Int Age to Map Int Int.

* The criterion must be recursive.  For example if we had
 data Map a b = MkMap (InternalMap a b)
  it's no good being able to see the data constructor MkMap; you need to
  see the constructors of InternalMap too.

The right thing is probably to use kinds, and all this is tantalisingly close 
to the system suggested in "Generative type abstraction and type-level 
computation" 
(http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/).  Maybe 
we should be able to *declare* Map to be indexed (rather than parametric) in 
its first parameter.

Interesting stuff.

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

Re: Newtype wrappers

2013-01-15 Thread Gábor Lehel

On Tue, Jan 15, 2013 at 3:15 AM, Iavor Diatchki
 wrote:
> In general, I was never comfortable with GHC's choice to add an axiom
> equating a newtype and its representation type, because it looks unsound to
> me (without any type-functions or newtype deriving).
> For example, consider:
>
> newtype T a = MkT Int
>
> Now, if this generates an axiom asserting that `froall a. T a ~ Int`, then
> we can derive a contradiction:
>
> T Int ~ Int ~ T Char, and hence `Int ~ Char`.
>
> It looks like what we need is a different concept: one that talks about the
> equality of the representations of types, rather then equality of the types
> themselves.
>
> -Iavor

This is what Simon's paper[1] referenced from the wiki is about,
except he uses the terminology "the representations of types" ->
"types", "the types themselves" -> "codes". (IMHO talking about
"representations" and "types", respectively, would be more
accessible.)

[1] http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/
"Generative Type Abstraction and Type-level Computation"


-- 
Your ship was destroyed in a monadic eruption.

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

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Error building ghc on raspberry pi.

Re: Newtype wrappers

RE: Newtype wrappers

Re: Newtype wrappers

13 matches

Site Navigation

Mail list logo

Footer information