Re: Error building ghc on raspberry pi.
On Mon, 21 Jan 2013, rocon...@theorem.ca wrote:
On Mon, 21 Jan 2013, Karel Gardas wrote:
On 01/21/13 12:49 AM, rocon...@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.''
___
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.
On Mon, 21 Jan 2013, Karel Gardas wrote: On 01/21/13 12:49 AM, rocon...@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.'' ___ 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.
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).
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.
Karel, maybe you should try deploying a binary-dist on your panda board?
--
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
Re: Error building ghc on raspberry pi.
On Sun, 20 Jan 2013, Karel Gardas wrote:
On 01/20/13 07:17 PM, rocon...@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?
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
Karel
[1]: https://ghcarm.wordpress.com/
--
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
Re: Error building ghc on raspberry pi.
On Sun, 20 Jan 2013, Karel Gardas wrote: On 01/20/13 07:50 PM, rocon...@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... both the settings and inplace/lib/settings are correct in my build tree. This suggests taht binary-dist is buggy. 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 -- 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
Re: Error building ghc on raspberry pi.
On Sun, 20 Jan 2013, Karel Gardas wrote:
On 01/20/13 07:17 PM, rocon...@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.''
___
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.
On Sun, 20 Jan 2013, Karel Gardas wrote:
On 01/20/13 08:27 PM, rocon...@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.''
___
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.
On Sun, 20 Jan 2013, Karel Gardas wrote:
On 01/20/13 08:27 PM, rocon...@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?
Main.hs is
main = putStrLn Hello World.
--
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
Re: Error building ghc on raspberry pi.
On Thu, 17 Jan 2013, rocon...@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.'' ___ 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.
On Fri, 18 Jan 2013, Karel Gardas wrote: On 01/18/13 05:49 PM, rocon...@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.'' ___ 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.
On Wed, 16 Jan 2013, Karel Gardas wrote: On 01/16/13 08:12 PM, rocon...@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
Re: Error building ghc on raspberry pi.
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. 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.'' ___ 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.
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 -- 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
Re: Error building ghc on raspberry pi.
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. Thanks, Karel On 01/16/13 08:02 PM, rocon...@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 -- 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
Re: Error building ghc on raspberry pi.
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
Re: Error building ghc on raspberry pi.
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 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
Re: Error building ghc on raspberry pi.
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:
Re: Error building ghc on raspberry pi.
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.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Building ghc on raspberry pi.
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-for-ARM-hard-float-ABI-fixes-5914.patch 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.'' ___ 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.
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, 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 -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.'' ___ 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.
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.'' ___ 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.
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 -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? Wait, never mind, I somehow failed to apply your option during the build. I will try again. -- 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
Re: Error building ghc on raspberry pi.
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 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.'' ___ 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.
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, 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.'' ___ 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.
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
Re: Error building ghc on raspberry pi.
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 rocon...@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-for-ARM-hard-float-ABI-fixes-5914.patch). 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 -- 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
Re: Error building ghc on raspberry pi.
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, rocon...@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 rocon...@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-for-ARM-hard-float-ABI-fixes-5914.patch).
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,
Re: Error building ghc on raspberry pi.
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/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 I get similar errors when building GHC 7.4.1 (patched with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support-for-ARM-hard-float-ABI-fixes-5914.patch). Any of you encountered this problem before? -- 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
Error building ghc on raspberry pi.
I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l) and I get the following error: inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.-optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc6324_0/ghc6324_0.bc -o /tmp/ghc6324_0/ghc6324_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc6324_0/ghc6324_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' /tmp/ghc6324_0/ghc6324_0.lm_s: openBinaryFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 Anyone have any thoughts on what might be the matter and what I can do to fix it. (If only openBinaryFile said which file doesn't exist.) -- 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
Re: Error building ghc on raspberry pi.
Thanks for your help, but unfortunately this isn't the issue Filesystem Size Used Avail Use% Mounted on /dev/sda2 924G 584G 294G 67% /tmp So there is pleanty of room on temp. BTW, I also tried building it twice and I got the same error at the same place. On Wed, 2 Jan 2013, Jeremy Shaw wrote: My random guess is that /tmp is mounted using tmpfs (aka a RAM drive) and it got full. Try remounting /tmp to use the sdcard instead ? On Wed, Jan 2, 2013 at 7:32 PM, rocon...@theorem.ca wrote: I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l) and I get the following error: inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc6324_0/ghc6324_0.bc -o /tmp/ghc6324_0/ghc6324_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc6324_0/ghc6324_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' /tmp/ghc6324_0/ghc6324_0.lm_s: openBinaryFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 Anyone have any thoughts on what might be the matter and what I can do to fix it. (If only openBinaryFile said which file doesn't exist.) -- 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.'' ___ 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.
Some further information it seems that llc is segfaulting: pi@raspberrypi /tmp/ghc-7.4.1 $ llc -O3 -relocation-model=static /tmp/ghc7189_0/ghc7189_0.bc -o /tmp/ghc7189_0/ghc7189_0.lm_s Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc7189_0/ghc7189_0.bc -o /tmp/ghc7189_0/ghc7189_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc7189_0/ghc7189_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' Segmentation fault pi@raspberrypi /tmp/ghc-7.4.1 $ llc --version Low Level Virtual Machine (http://llvm.org/): llvm version 3.0 (Debian 3.0-10)Optimized build. Built Jul 26 2012 (20:20:52). Host: arm-unknown-linux-gnueabihf Host CPU: (unknown) Registered Targets: alpha- Alpha [experimental] arm - ARM bfin - Analog Devices Blackfin [experimental] c- C backend cellspu - STI CBEA Cell SPU [experimental] cpp - C++ backend mblaze - MBlaze mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel msp430 - MSP430 [experimental] ppc32- PowerPC 32 ppc64- PowerPC 64 ptx32- PTX (32-bit) [Experimental] ptx64- PTX (64-bit) [Experimental] sparc- Sparc sparcv9 - Sparc V9 systemz - SystemZ thumb- Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore- XCore On Wed, 2 Jan 2013, rocon...@theorem.ca wrote: I'm trying to build ghc-7.4.1 using ghc-7.4.1 on my raspberry pi (armv6l) and I get the following error: inplace/bin/ghc-stage1 -H32m -O-package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-conf -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o Stack dump: 0. Program arguments: llc -O3 -relocation-model=static /tmp/ghc6324_0/ghc6324_0.bc -o /tmp/ghc6324_0/ghc6324_0.lm_s 1. Running pass 'Function Pass Manager' on module '/tmp/ghc6324_0/ghc6324_0.bc'. 2. Running pass 'ARM Instruction Selection' on function '@ghczmprim_GHCziTypes_Czh_info' /tmp/ghc6324_0/ghc6324_0.lm_s: openBinaryFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 Anyone have any thoughts on what might be the matter and what I can do to fix it. (If only openBinaryFile said which file doesn't exist.) -- 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
Re: How to describe this bug?
On Tue, 10 Jul 2012, Sönke Hahn wrote: Hi! I've discovered a strange bug that violates simple equational reasoning. Basically, something similar to this: let a = f x in a == f x While this code as it stands doesn't quite illustrate the referential transparency error, since == isn't guarenteed to return True on the same floating point value (see NaN), with a small tweek we can turn into an example that does illustrate the lack of referential transparency: (let a = f x in a == f x) == (let a = f x in a == a) or also perhaps (let a = f x in a == f x) == (f x == f x) If either of these return False than it is an error of referential transparency since equality on equivalent Bool expressions is always supposed to return True or diverge. -- 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
Re: RFC: migrating to git
On Tue, 11 Jan 2011, Simon Marlow wrote: Thanks for this. I distilled your example into a shell script that uses git, and demonstrates that git gets the merge wrong: http://hpaste.org/42953/git_mismerge I've posted an annotation at http://hpaste.org/paste/42953/git_mismerge_annotation#p42966 which shows the difference between pulling patches one at a time, and pulling both patches together. Still, git could get this merge right, it just doesn't (I know there are more complex cases that would be very hard for git to get right). I suspect that in practice this rarely matters, because context-based merging usually does the right thing. The operative word being *usually*. Remember what Dijkstra said. :) -- 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
Re: [Haskell] Expecting more inlining for bit shifting
On Tue, 17 Oct 2006, John Meacham wrote:
On Mon, Oct 09, 2006 at 03:54:41PM +0100, Ian Lynagh wrote:
It might be possible, but it sounds tricky. I guess it would have to go
something like try inlining this, run the simplifier, see if it got
small enough, if not back out, which could waste a lot of work if it
fails in lots of cases.
I would think the easiest way to go about this would be to extend the
rules pragma.
{-# RULES shift/const-inline forall x y# . shift x y# = ... #-}
I'm not sure this approach is best. In my case the ... needs to be the
entire body of the shift code. It would be ridiculous to have two copies
of the same code. What would be better is a hint pragma that says,
``inline me if the following set of parameters are literals''.
--
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
Re: foldl laziness support. Reply
Although this doesn't answer your question, I think it is releated. When implementing SHA, I need to create a recursive function to append the length of a string to the string. This function needed to be strict, because it needed to accumulted the length of the string, and it needed to be lazy, because it needed to re-emmit the characters that it consumed. I have a short discussion about this at http://r6.livejournal.com/91508.html. -- 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
Re: Compiling GHC disabling the type checker
On Mon, 16 Oct 2006, Simon Marlow wrote: There's one restriction that I know of: you should be careful not to cast a function value to a non-function type (except a polymorphic type), because the two have incompatible representations when it comes to seq and case. And of course, you should never cast an unboxed value to a boxed type or vice versa. Apart from these, I think you should be fine to unsafeCoerce# away. Coq's extraction mechinism uses the type () whenever it encounters a dependent type that it cannot make a Haskell type for. Thus, all sorts of functions end up getting cast to () types. Would it be safer to cast things to ``() - ()'', or perhaps a single polymorphic variable ``a''? -- 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
RE: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote:
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
Do you think it should be that general? I was thinking the discount
should only apply in the situtation where a case expression contains an
expression with one free varaible that is a function argument, and all
operations are primitive.
So I was thinking the right place to patch is in sizeExpr:
size_up (Case (Var v) _ _ alts)
| v `elem` top_args
= ...
And make this branch activate is a wider range of circumstances. SamB
is/was working on such a patch.
But making sure that all operations are primitive is not quite right, for
instance in
f :: Int - ...
f x | gcd x 21 1 = ...
we cannot give x an argument discount because (gcd (5::Int) 21) is not
rewritten into 1 (for some strange reason).
So, is there a way of deciding if a primitive op will be rewritten if all
its arguements are given?
--
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
RE: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote: The constant-folding rules for the primops are all in prelude/PrelRules.lhs in function primOpRules. Please add more rules. For example, I see that x +# 0 = x is not in there! It is in libraries/base/GHC/Base.lhs x# +# 0# forall x#. x# +# 0# = x# -- 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
Re: [Haskell] Expecting more inlining for bit shifting
On Wed, 11 Oct 2006, Samuel Bronson wrote:
branch. I've got a patch that seems like it ought to do a bettter job,
but it doesn't seem to give the $wrotate functions any discount (the
$wshift functions having been tagged by the {-# INLINE shift #-} pragmas
I added all over). Unfortunately I left it at home and I'm at school
right now :-(. It does get run sometimes, but I'm not sure if it is run
for rotate or that its results are kept...
The problem with rotate is that it is:
(W32# x#) `rotate` (I# i#)
| i'# ==# 0# = W32# x#
| otherwise = W32# (narrow32Word# ((x# `shiftL#` i'#) `or#`
(x# `shiftRL#` (32# -# i'#
where
i'# = word2Int# (int2Word# i# `and#` int2Word# 31#)
The i'# gets inlined, so the case statement isn't actually actually doing
an analysis on i#, rather it is doing an analysis on
i# `and#` 31#.
So this lends support to SPJ's view that we need to check to see if a
variable is being used in an application of a primop that can be
evaluated, and all the other arguements are literals.
--
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
RE: [Haskell] Expecting more inlining for bit shifting
On Tue, 10 Oct 2006, Simon Peyton-Jones wrote: That's precisely what GHC does. My explanation before was too brief, sorry. The algorithm is described in Secrets of the GHC inliner http://research.microsoft.com/%7Esimonpj/Papers/inlining/index.htm But it still only makes a specialised copy if the function is small enough. Obviously a great big function with a tiny specialisation opportunity would be a poor candidate. Do you mean if the resulting function if ``small enough'', or the original function is small enough? Anyhow I will look at the paper. | I must say I'm extremely disappointed with this. I believe I was taught | in my undergraduate CS program (but perhaps I wasn't) that one ought not | to make these sorts of trivial hand optimisations, because compilers are | smart enough to figure out these sorts of things by themselves, and they | know more about that target platform that you do. In particular the | propaganda about side-effect-free functional languages was a promise that | they would use the strong types and side-effect-freeness to do all sorts | of wonderful optimisations. Well I think if you use -ddump-simpl you'll see a program that often looks pretty different to the one you wrote. I often have difficulty figuring out just how GHC managed to transform the source program into the optimised one. I should metion that I feel that GHC does do a great optimisation job considering. It manages to transform a language, largely based on abstract mathematics, into something that a Von Neumann can run in practise. This is, of course, and amasing feat. I am just going to have to learn that the comipler won't do optimisations that I think it ought to figure out. So I will either have to start writing hand tunned non-portable, potentially unsafe code, or figure out how to extend GHC optimizer. I prefer the later. -- 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
RE: [Haskell] Expecting more inlining for bit shifting
On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: Turns out that 'shift' is just too big to be inlined. (It's only called once, but you have exported it too.) You can see GHC's inlining decisions by saying -ddump-inlinings. To make GHC keener to inline, use an INLINE pragma, or increase the inlining size threshold e.g. -funfolding-threshold=12 Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? PS, is there a way to mark an imported instance of a class function (Data.Bits.shift for Data.Word.Word32) to be inlined? -- 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
Re: [Haskell] Expecting more inlining for bit shifting
Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? It might be possible, but it sounds tricky. I guess it would have to go something like try inlining this, run the simplifier, see if it got small enough, if not back out, which could waste a lot of work if it fails in lots of cases. I would have imagined an optimisation step that only activates when a constructor is passed into a function to see if it produces a branch that can be precomputed, and then tries to determine if it is worth making a specialized function with that case eliminated. Or possibly having each function inspected to see if it has branches that could be eliminated if a constructor was passed as an argument. I must say I'm extremely disappointed with this. I believe I was taught in my undergraduate CS program (but perhaps I wasn't) that one ought not to make these sorts of trivial hand optimisations, because compilers are smart enough to figure out these sorts of things by themselves, and they know more about that target platform that you do. In particular the propaganda about side-effect-free functional languages was a promise that they would use the strong types and side-effect-freeness to do all sorts of wonderful optimisations. However, it seems the truth of the matter is that an advanced compiler such as GHC cannot even optimise away the bounds checks occurring when shifting by a constant number of bits. -- 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
