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
Hi Sean,
On Mon, Dec 10, 2012 at 04:04:34PM +0100, Sean Leather wrote:
On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote:
Please test as much as possible; bugs are much cheaper if we find them
before the release!
I tried to build the source tarball on Mac OS X 10.5.8. I used GHC
On Thu, Dec 13, 2012 at 12:31:09PM +0100, Goetz Isenmann wrote:
This change
https://github.com/ghc/ghc/commit/106f0434144199276add8860c146c542cc67513b
is missing for a success build on DragonFly-3.2/x86_64
Thanks, I've merged it to the 7.6 branch now.
Thanks
Ian
On Tue, Jan 08, 2013 at 08:10:18PM +, Duncan Coutts wrote:
Either way, lemme know if this is all fine, and I'll make the 0.10.0.2
release.
Looks good, thanks! I've updated the GHC 7.6 repo to match the tag.
Thanks
Ian
___
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
I just did a clean build of my cross-compiling GHC with --prefix set in the
top-level ./configure call.
When I run `make install` I get:
/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg
--force --global-package-db
If there is anything useful I can do - shout.
Given the time it takes to do each rebuild on a raspberry pi - this is real
dedication!
Neil
On 12 Jan 2013, at 17:01, rocon...@theorem.ca wrote:
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
Karel Gardas karel.gar...@centrum.cz writes:
On 01/11/13 09:25 PM, rocon...@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
Quoting Stephen Paul Weber singpol...@singpolyma.net:
Is there a way to tell cabal to refuse to upgrade a package? I'd
like to pin my `bytestring` to the version that shipped with my GHC.
cabal install --constraint bytestring installed
~d
___
Quoting Shachaf Ben-Kiki shac...@gmail.com:
You can put constraint: bytestring == version in ~/.cabal/config.
Alternatively you can run one `cabal install --constraint bytestring
== version` command.
Keep in mind the following subtle difference between this constraint
and the installed
Is there any way to set the paths in my cabal-install config relative to
$HOME or similar? I tried ~ and $HOME and neither of those worked.
--
Stephen Paul Weber, @singpolyma
See http://singpolyma.net for how I prefer to be contacted
edition right joseph
Hey,
I am still investigating the segfaults of the exectuable produced by ghc
to arm-linux-androideabi cross compiler.
I need help. Can someone tell me if my conclusions are correct?
The crash happens here:
Dump of assembler code for function stg_returnToStackTop:
0x003f059c +0: push
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
On Sat, 12 Jan 2013, rocon...@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
What version of GHC did you build?
On Sat, 12 Jan 2013, Ben Gamari wrote:
Karel Gardas karel.gar...@centrum.cz writes:
On 01/11/13 09:25 PM, rocon...@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
rocon...@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
On Sat, 12 Jan 2013, Ben Gamari wrote:
rocon...@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,
rocon...@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
On Sat, Jan 12, 2013 at 10:23 PM, rocon...@theorem.ca wrote:
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. Notice
On Sat, Jan 12, 2013 at 10:29 PM, Austin Seipp mad@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
___
Glasgow-haskell-users
20 matches
Mail list logo
