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.
FYI, I created a wiki page for cross-compiling to Raspberry Pi: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi I have an unregisterised build using LLVM working now (it just worked, modulo the tiny fix for #7622). Cheers, Simon On 21/01/13 16:06, Karel Gardas wrote: On 01/21/13 04:43 PM, rocon...@theorem.ca wrote: So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file. Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch? I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ. Please post your findings here, I'm really curious what is the culprit here... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
Simon Looking at the wiki - I take it that the stage 1 compiler can now be used as native compiler on the RPi? (last line of entry)? Neil On 25 Jan 2013, at 10:46, Simon Marlow marlo...@gmail.com wrote: FYI, I created a wiki page for cross-compiling to Raspberry Pi: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi I have an unregisterised build using LLVM working now (it just worked, modulo the tiny fix for #7622). Cheers, Simon On 21/01/13 16:06, Karel Gardas wrote: On 01/21/13 04:43 PM, rocon...@theorem.ca wrote: So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file. Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch? I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ. Please post your findings here, I'm really curious what is the culprit here... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ 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 25/01/13 11:23, Neil Davies wrote: Simon Looking at the wiki - I take it that the stage 1 compiler can now be used as native compiler on the RPi? (last line of entry)? Do you mean the stage 2 compiler? If so yes - in principle. But in practice the binary-dist machinery doesn't work properly for cross-compilers yet, so it's hard to install it on the RPi. If you have a shared network filesystem then perhaps 'make install' works, or if you copy the build tree to your RPi at the same location as your build machine, then maybe it will work. Cheers, Simon Neil On 25 Jan 2013, at 10:46, Simon Marlow marlo...@gmail.com wrote: FYI, I created a wiki page for cross-compiling to Raspberry Pi: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi I have an unregisterised build using LLVM working now (it just worked, modulo the tiny fix for #7622). Cheers, Simon On 21/01/13 16:06, Karel Gardas wrote: On 01/21/13 04:43 PM, rocon...@theorem.ca wrote: So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file. Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch? I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ. Please post your findings here, I'm really curious what is the culprit here... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ 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.
That's good to hear - we've got AFS and the dev-RPi's are using it… Neil On 25 Jan 2013, at 12:20, Simon Marlow marlo...@gmail.com wrote: On 25/01/13 11:23, Neil Davies wrote: Simon Looking at the wiki - I take it that the stage 1 compiler can now be used as native compiler on the RPi? (last line of entry)? Do you mean the stage 2 compiler? If so yes - in principle. But in practice the binary-dist machinery doesn't work properly for cross-compilers yet, so it's hard to install it on the RPi. If you have a shared network filesystem then perhaps 'make install' works, or if you copy the build tree to your RPi at the same location as your build machine, then maybe it will work. Cheers, Simon Neil On 25 Jan 2013, at 10:46, Simon Marlow marlo...@gmail.com wrote: FYI, I created a wiki page for cross-compiling to Raspberry Pi: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/RaspberryPi I have an unregisterised build using LLVM working now (it just worked, modulo the tiny fix for #7622). Cheers, Simon On 21/01/13 16:06, Karel Gardas wrote: On 01/21/13 04:43 PM, rocon...@theorem.ca wrote: So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file. Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch? I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ. Please post your findings here, I'm really curious what is the culprit here... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ 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 01/21/13 04:43 PM, rocon...@theorem.ca wrote: So the binary-dist has a settings.in file. It is the configure step in the binary-dist that generates the corrupt settings file. Perhaps you've forgotten to regenerate bin-dist configure as you did with build tree configure after applying my patch? I'll try to poke around to see where and why the stage2 compiler and the binary-dist compiler differ. Please post your findings here, I'm really curious what is the culprit here... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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 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?
Karel
[1]: https://ghcarm.wordpress.com/
___
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 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... 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 ___ 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 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?
Thanks!
Karel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
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 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! :-) Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
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 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. Thanks, Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
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.
There have been a few of these bugs recently it seems. If you could: use the stage1 compiler to compile a simple executable, like 'main = return ()' or hello world or whatever. The stage1 compiler can be located in the build directory, under 'inplace/bin/ghc-stage1'. So something like: GHC BUILD/inplace/bin/ghc-stage1 -fforce-recomp hello_world.hs Check if the output executable crashes immediately. If it does, then it is likely a miscompilation of the runtime or libraries somewhere. Otherwise, we'll have to narrow down another way. If it does fail, please use GDB on the executable, and give a backtrace from the crash (using the 'bt' command, after the program has crashed.) You can also try linking with the debug RTS, by passing the -debug and -rtsopts flag to ghc-stage1. Then run again, and see if something else was tripped. You can see all the sanity checks you can enable, if you run the executable using './program.exe +RTS --help'. The debug flags are named things like '-Ds' and '-Da', etc and should be passed to the RTS. On Thu, Jan 17, 2013 at 1:11 PM, rocon...@theorem.ca wrote: 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 -- Regards, Austin ___ 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.
Guys, I've installed raspbian into ubuntu chroot on my panda. Now to simulate what GHC detects on your hardware, could you be so kind and send me output of: uname -m uname -r uname -s uname -v this looks like a needed info for config.guess to detect machine hardware well. Also if you send me output of: sh config.guess it would be great. Everything of course run on your rpi board! Thanks, Karel ___ 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 looked at that route - the issue is that the emulator only has 256M of RAM (and that's not changeable) - so there are going to be build issues with the GHC tool chain - it was then that I moved to real hardware. Neil On 15 Jan 2013, at 17:01, rocon...@theorem.ca wrote: 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 ___ 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.
Ok - I'll put up a machine in a DMZ sometime later today (RPi just arrived by post) . I'll make it available on an non-standard ssh port - I suggest access via ssh-key only. If you want to email me the appropriate line for .ssh/authorizedkeys please do. If you want to encrypt it with gpg, that's fine - use key id FF677414 (neil.dav...@pnsol.com) Neil On 15 Jan 2013, at 17:16, Karel Gardas karel.gar...@centrum.cz wrote: Well, if you make some board available in DMZ I'm certainly interested to run at least configure on it from GHC HEAD to see what we need to hack in order to add support for RPi into GHC HEAD. Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build, but Austin is working on this. I think I can hack support for RPi in the meantime for testing later on fixed GHC HEAD LLVM build... Karel On 01/15/13 06:07 PM, rocon...@theorem.ca wrote: In theory we could try a couple variations of builds at the same time. But at the moment, I'm running low on ideas on what to try. I just got the, extensive, raspbian patches for 7.4.1 and I'm going to browse through them when I get time (apt-get source ghc). On Tue, 15 Jan 2013, Neil Davies wrote: Hi - would another RPi (or even 2 from tomorrow another one arriving) help? I can make them accessible (i.e. in our DMZ) - Neil On 15 Jan 2013, at 16:36, rocon...@theorem.ca wrote: On Mon, 14 Jan 2013, Thijs Alkemade wrote: Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende geschreven: On Thu, 10 Jan 2013, Karel Gardas wrote: Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here... I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again... No change with SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm I still get the error: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get: $ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory What is make really doing here? My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from. libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is the output ld was asked to generate. Apparently, some of the input .o files didn't use VFP register arguments, so ld concluded that the output should also not use VFP register arguments. But then ld encountered a .o file that did use VFP register arguments, and threw an error (something in cbits, so probably built with different CFLAGS). From your flags I'd say you miss -optlc-float-abi=hard. I had it in GhcLibHcOpts, but I'm not sure that is the correct way to ensure it is passed to everything exactly once. Okay, I tried: SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/HSCParser.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/HSCParser.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build
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.
Good! So the patch I already provided is working fine at least w.r.t. change in configure. I've tested it here on my raspbian chroot on pandaboard where I've hacked config.guess to print exactly what you get on real rpi. Now, I'm curious if the hack in DriverPipeline.hs helps too. Were you able to merge the patch into your GHC? And rebuild? What was the result? Thanks, Karel On 01/16/13 08:02 PM, 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 ___ 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 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... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
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.
Op 15 jan. 2013, om 17:36 heeft rocon...@theorem.ca het volgende geschreven: Okay, I tried: SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts= -O -fllvm GhcStage2HcOpts= -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o ... Did you do a `make clean` first? If not, try removing just (some of) the offending .o files, and see if rebuilding just those results in the same error. Thijs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
Hi - would another RPi (or even 2 from tomorrow another one arriving) help? I can make them accessible (i.e. in our DMZ) - Neil On 15 Jan 2013, at 16:36, rocon...@theorem.ca wrote: On Mon, 14 Jan 2013, Thijs Alkemade wrote: Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende geschreven: On Thu, 10 Jan 2013, Karel Gardas wrote: Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here... I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again... No change with SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts= -O -fllvm GhcStage2HcOpts= -O0 -fllvm GhcLibHcOpts = -O -fllvm I still get the error: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get: $ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory What is make really doing here? My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from. libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is the output ld was asked to generate. Apparently, some of the input .o files didn't use VFP register arguments, so ld concluded that the output should also not use VFP register arguments. But then ld encountered a .o file that did use VFP register arguments, and threw an error (something in cbits, so probably built with different CFLAGS). From your flags I'd say you miss -optlc-float-abi=hard. I had it in GhcLibHcOpts, but I'm not sure that is the correct way to ensure it is passed to everything exactly once. Okay, I tried: SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts= -O -fllvm GhcStage2HcOpts= -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/HSCParser.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/HSCParser.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/DirectCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/DirectCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/CrossCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/CrossCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/UtilsCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/UtilsCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Common.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Common.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/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
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: utils/hsc2hs/dist-install/build
Re: Error building ghc on raspberry pi.
Well, if you make some board available in DMZ I'm certainly interested to run at least configure on it from GHC HEAD to see what we need to hack in order to add support for RPi into GHC HEAD. Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build, but Austin is working on this. I think I can hack support for RPi in the meantime for testing later on fixed GHC HEAD LLVM build... Karel On 01/15/13 06:07 PM, rocon...@theorem.ca wrote: In theory we could try a couple variations of builds at the same time. But at the moment, I'm running low on ideas on what to try. I just got the, extensive, raspbian patches for 7.4.1 and I'm going to browse through them when I get time (apt-get source ghc). On Tue, 15 Jan 2013, Neil Davies wrote: Hi - would another RPi (or even 2 from tomorrow another one arriving) help? I can make them accessible (i.e. in our DMZ) - Neil On 15 Jan 2013, at 16:36, rocon...@theorem.ca wrote: On Mon, 14 Jan 2013, Thijs Alkemade wrote: Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende geschreven: On Thu, 10 Jan 2013, Karel Gardas wrote: Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of ARMv6/ARM11 chip here... I'm afraid LLVM is not well guided in your case so could you be so kind and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your build.mk probably and you will need to rebuild everything again... No change with SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm I still get the error: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o I don't really understand what is going on here. The file libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o doesn't even exist, so when I manually run /usr/bin/ld I get: $ /usr/bin/ld libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: cannot find libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o: No such file or directory What is make really doing here? My research suggests that this error is a symptom of trying to link something without the hard-float ABI together with something with a soft-float ABI. But I don't know where libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is coming from. libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o is the output ld was asked to generate. Apparently, some of the input .o files didn't use VFP register arguments, so ld concluded that the output should also not use VFP register arguments. But then ld encountered a .o file that did use VFP register arguments, and threw an error (something in cbits, so probably built with different CFLAGS). From your flags I'd say you miss -optlc-float-abi=hard. I had it in GhcLibHcOpts, but I'm not sure that is the correct way to ensure it is passed to everything exactly once. Okay, I tried: SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts = -O -fllvm GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/HSCParser.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/HSCParser.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/DirectCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/DirectCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/CrossCodegen.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/CrossCodegen.o /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/UtilsCodegen.o does not /usr/bin/ld
Re: Error building ghc on raspberry pi.
rocon...@theorem.ca writes: Okay, I tried: SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts= -O -fllvm GhcStage2HcOpts= -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o I found this as well and have been unable to figure out what in the build system needs to be tweaked. This is ultimately where I gave up on 7.4. Anyone have any ideas what flags this is built with? It seems that neither GhcStage2HcOpts nor GhcLibHcOpts make it to the compiler here, inplace/bin/ghc-stage1 -H64m -Rghc-timing -v-hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2 hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.5.1.0 -package containers-0.4.2.1 -package directory-1.1.0.2 -package process-1.1.0.1 -X Haskell98 -XCPP -XForeignFunctionInterface -no-user-package-conf -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./Main.hs -o utils/hsc2hs/dist-install/build/Main.o Cheers, - Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
Well, just wild guessing what's needed on RPi, but could you who do have this board attempt to use attached patch? Don't forget to ./boot as this change configure. Also testing it on completely clean tree may be wise idea. Also after configure run please check that you do have VFPv2 in the ext list. -- this is indeed a wild guess for ARMv6, but as we do the same for ARMv7 (guessing VFPv3) I don't think this is show-stopper now... Please let me know if this is working... Karel On 01/15/13 06:25 PM, Ben Gamari wrote: rocon...@theorem.ca writes: Okay, I tried: SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2 GhcStage1HcOpts= -O -fllvm GhcStage2HcOpts= -O0 -fllvm GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard and I got the same error at a different build step. I'm not sure if it is earlier or later. It seems still not everything is using the hard-float ABI. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] utils/hsc2hs/dist-install/build/tmp/hsc2hs /usr/bin/ld: error: utils/hsc2hs/dist-install/build/tmp/hsc2hs uses VFP register arguments, utils/hsc2hs/dist-install/build/Main.o does not /usr/bin/ld: failed to merge target specific data of file utils/hsc2hs/dist-install/build/Main.o I found this as well and have been unable to figure out what in the build system needs to be tweaked. This is ultimately where I gave up on 7.4. Anyone have any ideas what flags this is built with? It seems that neither GhcStage2HcOpts nor GhcLibHcOpts make it to the compiler here, inplace/bin/ghc-stage1 -H64m -Rghc-timing -v-hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2 hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.5.1.0 -package containers-0.4.2.1 -package directory-1.1.0.2 -package process-1.1.0.1 -X Haskell98 -XCPP -XForeignFunctionInterface -no-user-package-conf -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc -c utils/hsc2hs/./Main.hs -o utils/hsc2hs/dist-install/build/Main.o Cheers, - Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users diff --git a/aclocal.m4 b/aclocal.m4 index 127f528..a2db986 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -356,7 +356,7 @@ AC_DEFUN([GET_ARM_ISA], [AC_DEFINE(arm_HOST_ARCH_PRE_ARMv7, 1, [ARM pre v7]) changequote(, )dnl ARM_ISA=ARMv6 - ARM_ISA_EXT=[] + ARM_ISA_EXT=[VFPv2] changequote([, ])dnl ], [changequote(, )dnl diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index b128c1f..c71546c 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1453,14 +1453,17 @@ runPhase LlvmLlc input_fn dflags else if (elem VFPv3D16 ext) then [-mattr=+v7,+vfp3,+d16] else [] + ArchARM ARMv6 ext _ - if (elem VFPv2 ext) + then [-mattr=+v6,+vfp2] + else [-mattr=+v6] _ - [] -- On Ubuntu/Debian with ARM hard float ABI, LLVM's llc still -- compiles into soft-float ABI. We need to explicitly set abi -- to hard abiOpts = case platformArch (targetPlatform dflags) of -ArchARM ARMv7 _ HARD - [-float-abi=hard] -ArchARM ARMv7 _ _- [] -_- [] +ArchARM _ _ HARD - [-float-abi=hard] +ArchARM _ _ _- [] +_- [] - -- LlvmMangle phase ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
Op 15 jan. 2013, om 18:16 heeft Karel Gardas karel.gar...@centrum.cz het volgende geschreven: Well, if you make some board available in DMZ I'm certainly interested to run at least configure on it from GHC HEAD to see what we need to hack in order to add support for RPi into GHC HEAD. Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build, but Austin is working on this. I think I can hack support for RPi in the meantime for testing later on fixed GHC HEAD LLVM build... Karel This might be helpful, it's a guide to emulate a raspberry pi using qemu, which I was using to (try to) build GHC: http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ While I haven't done any real measurements, it seemed somewhat faster too on my machine. Thijs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
On 01/15/13 08:56 PM, Thijs Alkemade wrote: Op 15 jan. 2013, om 18:16 heeft Karel Gardaskarel.gar...@centrum.cz het volgende geschreven: Well, if you make some board available in DMZ I'm certainly interested to run at least configure on it from GHC HEAD to see what we need to hack in order to add support for RPi into GHC HEAD. Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build, but Austin is working on this. I think I can hack support for RPi in the meantime for testing later on fixed GHC HEAD LLVM build... Karel This might be helpful, it's a guide to emulate a raspberry pi using qemu, which I was using to (try to) build GHC: http://xecdesign.com/qemu-emulating-raspberry-pi-the-easy-way/ While I haven't done any real measurements, it seemed somewhat faster too on my machine. Indeed, that may be the way. The other may be to debootstrap rasbian into ubuntu chroot on ARMv7 machine for example. I'm curious what configure will report then, i.e. if this will look really like ARMv6 or ARMv7 at the end... Also 1 GHz OMAP4 is still faster in executing ARm code than Qemu/ARM running on my Intel box... :-) Karel ___ 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... 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: Error building ghc on raspberry pi.
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 ___ 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.
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 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.
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 ___ 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.
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 The build is still in stage 1 so it is unclear whether this will fix the original linker error. Cheers, - Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
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.
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 -optlc-mcpu=cortex-a9 GhcLibHcOpts = -O -fllvm -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-float-abi=hard -optlc-mcpu=cortex-a9 You've written -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 twice in your GhcLibHcOpts. Not quite, one is -optc (apparently passed to gcc) and the other is -optlc (passed to llc). Cheers, - Ben ___ 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, 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 the difference between '-optc-...' and '-optlc-...' The first one will pass options onto the C compiler (since you use the GHC executable to compile the RTS and other things, this is necessary.) The first one passes the options onto LLVM's code generator tool, 'llc', so it also gets the ABI options right. -- Regards, Austin ___ 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, 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 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.
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... Once you test it and if succeed we can hack ghc to support it. Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error building ghc on raspberry pi.
Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case
of ARMv6/ARM11 chip here...
I'm afraid LLVM is not well guided in your case so could you be so kind
and test if adding -optlc=-mattr=+vfp2 helps? You need to add it to your
build.mk probably and you will need to rebuild everything again...
Cheers,
Karel
On 01/10/13 03:11 AM, rocon...@theorem.ca wrote:
This is the settingings file:
$ cat settings
[(GCC extra via C opts, -fwrapv),
(C compiler command, /usr/bin/gcc),
(C compiler flags, -fno-stack-protector -Wl,--hash-size=31
-Wl,--reduce-memory-overheads),
(ar command, /usr/bin/ar),
(ar flags, q),
(ar supports at file, YES),
(touch command, touch),
(dllwrap command, /bin/false),
(windres command, /bin/false),
(perl command, /usr/bin/perl),
(target os, OSLinux),
(target arch, ArchARM {armISA = ARMv6, armISAExt = [], armABI = HARD}),
(target word size, 4),
(target has GNU nonexec stack, False),
(target has .ident directive, True),
(target has subsections via symbols, False),
(LLVM llc command, /home/pi/.nix-profile/bin/llc),
(LLVM opt command, /home/pi/.nix-profile/bin/opt)
]
On Wed, 9 Jan 2013, Karel Gardas wrote:
Hi,
find ghc's generated settings file. What FPU is used there?
Thanks,
Karel
On 01/ 9/13 09:47 PM, 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
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.
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, 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 ___ 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.
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/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? 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 ___ 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, 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
Re: Error building ghc on raspberry pi.
(Sorry, forgot to CC the list) Original Message From: Thijs Alkemade m...@thijsalkema.de Sent: Thu Jan 03 10:31:50 CET 2013 To: rocon...@theorem.ca Subject: Re: Error building ghc on raspberry pi. rocon...@theorem.ca wrote: 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.) 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 ___ 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.
rocon...@theorem.ca writes: Some further information it seems that llc is segfaulting: Where did you get your LLVM build from? Did you try running the LLVM testsuite? IIRC, LLVM 3.0 was less than stellar on ARM. - Ben ___ 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.
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 ___ 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: Kind error in GHC-7.4.1, works in GHC-7.2.2
Thank you for the explanation. I now understand the problem. I have rewritten the code using some parenthesis. Thanks, Roel 2012/2/10 Simon Peyton-Jones simo...@microsoft.com: It should not have worked before. Consider I# $ 3# ($) is a polymorphic function and takes two *pointer* arguments. If we actually called it with I# and 3# as arguments we might seg-fault when we call the GC when allocating the box. Polymorphic type variables (in this case in the type of ($)) can only be instantiated with boxed types. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Kind error in GHC-7.4.1, works in GHC-7.2.2
Hello,
I have some code that compiled fine in GHC-7.2.2 but fails in
GHC-7.4.1 with a kind error.
{-# LANGUAGE MagicHash, NoImplicitPrelude, PackageImports #-}
import base Data.Function ( ($) )
import base GHC.Exts ( Int(I#) )
import base Prelude ( Integral, fromIntegral, toInteger )
import integer-gmp GHC.Integer.Logarithms ( integerLogBase# )
intLog :: (Integral a) = a - a
intLog x = fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
This results in the following error:
Couldn't match kind `#' against `*'
In the second argument of `($)', namely
`I# $ integerLogBase# 10 (toInteger x)'
In the expression:
fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
In an equation for `intLog':
intLog x = fromIntegral $ I# $ integerLogBase# 10 (toInteger x)
Simply eliminating some $'s using parenthesis solves the problem:
intLog x = fromIntegral $ I# (integerLogBase# 10 (toInteger x))
Why do I get the above kind error? Could it be a bug in GHC?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: error building GHC Head
I am informed that the google gold linker does not like relative paths https://bugzilla.redhat.com/show_bug.cgi?id=635935 I uninstalled the gold linker and all is well now. On Wed, Sep 14, 2011 at 9:11 PM, Greg Weber g...@gregweber.info wrote: I just cloned GHC from github and tried to build it for the first time. I get the below result where the build tool says that existing object files are missing. I haven't touched a Makefile in a long time- help here is very appreciated. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all 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 -split-objs -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/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__1.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/.o::CString(void) /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__3.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__4.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__5.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__6.o collect2: ld returned 1 exit status make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1 make: *** [all] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
error building GHC Head
I just cloned GHC from github and tried to build it for the first time. I get the below result where the build tool says that existing object files are missing. I haven't touched a Makefile in a long time- help here is very appreciated. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all 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 -split-objs -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/CString.hs -o libraries/ghc-prim/dist-install/build/GHC/CString.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__1.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/.o::CString(void) /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__3.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__4.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__5.o /usr/bin/ld: error: cannot find libraries/ghc-prim/dist-install/build/GHC/CString_o_split/CString__6.o collect2: ld returned 1 exit status make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1 make: *** [all] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Type error in GHC-7 but not in GHC-6.12.3
| foo :: (forall s. ST s a) - a
| foo st = ($) runST st
This is a motivating example for type inference that can deal with
impredicative types. Consider the type of ($):
($) :: forall p q. (p-q) - p - q
In the example we need to instantiate 'p' with (forall s. ST s a), and that's
what impredicative polymorphism means: instantiating a type variable with a
polymorphic type.
Sadly, I know of no system of reasonable complexity that can typecheck 'foo'
unaided. There are plenty of complicated systems, and I have been a co-author
on papers on at least two, but they are all Too Jolly Complicated to live in
GHC. We did have an implementation of boxy types, but I took it out when
implementing the new typechecker. Nobody understood it.
However, people so often write
runST $ do ...
that in GHC 7 I implemented a special typing rule, just for infix uses of ($).
Just think of
(f $ x) as a new syntactic form, with the obvious typing rule, and away you go.
It's very ad hoc, because it's absolutely specific to ($), and I'll take it out
if you all hate it, but it's in GHC 7 for now.
Anyway, that's why you encountered the puzzling behaviour you describe below.
Simon
| -Original Message-
| From: Bas van Dijk [mailto:v.dijk@gmail.com]
| Sent: 30 October 2010 21:14
| To: glasgow-haskell-users@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Re: Type error in GHC-7 but not in GHC-6.12.3
|
| On Sat, Oct 30, 2010 at 1:57 AM, Bas van Dijk v.dijk@gmail.com wrote:
| I could isolate it a bit more if you want.
|
| And so I did. The following is another instance of the problem I'm
| having but set in a more familiar setting:
|
| {-# LANGUAGE RankNTypes #-}
|
| import Control.Monad.ST
|
| foo :: (forall s. ST s a) - a
| foo st = ($) runST st
|
| Couldn't match expected type `forall s. ST s a'
| with actual type `ST s a'
| In the second argument of `($)', namely `st'
|
| Note that: 'foo st = runST st' type checks as expected.
|
| Surprisingly 'foo st = runST $ st' also type checks!
|
| I find the latter surprising because according to the report[1]: e1 op
| e2 = (op) e1 e2. So either both should type check or both should fail.
|
| I guess that a RULE somewhere eliminates the ($) before the
| type-checker kicks in. I do find that a little strange because I
| thought RULES where applied after type checking.
|
| Regards,
|
| Bas
|
| [1] http://www.haskell.org/onlinereport/exps.html#operators
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Type error in GHC-7 but not in GHC-6.12.3
OK now I see.
You are using impredicative polymorphism. As I mentioned in my last message
I've simplified the treatment of impredicativity to follow (more or less) QML:
http://research.microsoft.com/en-us/um/people/crusso/qml/
In the call to useWhich
useWhich devs withDevice p f
you can see that
withDevice ∷ Monad pr
⇒ Device
→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
→ pr α
useWhich ∷ ∀ k desc e (m ∷ * → *) α
. (GetDescriptor e desc)
⇒ [e]
→ (e → k → m α)
→ (desc → Bool)
→ k
→ m α
So it follows that you must instantiate
k = (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
Arguably GHC should complain at this point unless you use
-XImpredicativePolymorphism, but it doesn't.
Now, the arguemnnt 'f' in the call, is apparently compatible with this type
*except* that f's type is instantiated. What you want is a way to say don't
instantiate f here. QML provides a way to do that, via a rigid type
signature, but GHC currently does not. (Pressure of time, plus impredicativity
is a somewhat obscure feature.)
So I guess I should implement rigid type signatures. As ever the problem is
syntax.
To work around this, use a newtype to the forall in the last argument of
useWhich.
Simon
| -Original Message-
| From: Bas van Dijk [mailto:v.dijk@gmail.com]
| Sent: 30 October 2010 00:58
| To: glasgow-haskell-users@haskell.org
| Cc: Simon Peyton-Jones
| Subject: Re: Type error in GHC-7 but not in GHC-6.12.3
|
| On Fri, Oct 29, 2010 at 5:42 PM, Simon Peyton-Jones
| simo...@microsoft.com wrote:
| That looks odd.
|
| Can you isolate it for us? The easiest thing is usually to start with the
| offending code:
| withDeviceWhich ∷
| ∀ pr α
| . MonadCatchIO pr
| ⇒ USB.Ctx
| → (USB.DeviceDesc → Bool)
| → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
| → pr α
| withDeviceWhich ctx p f = do
| devs ← liftIO $ USB.getDevices ctx
| useWhich devs withDevice p f
|
| Now add local definitions for each of the functions mentioned, with
definition foo
| = undefined.
|
| useWhich ∷
| ∀ k desc e (m ∷ * → *) α
| . (GetDescriptor e desc, MonadIO m)
| ⇒ [e]
| → (e → k → m α)
| → (desc → Bool)
| → k
| → m α
| useWhich = undefined.
|
| Now all you need is the types involved, and you can probably define them as
|
| data RegionT s pr a
|
| etc
|
| That should give a standalone test case.
|
| Thanks!
|
| SImon
|
|
| Ok, Here's the more isolated program which still gives the same error
| as the full usb-safe (on the latest ghc-HEAD (7.1.20101029)):
|
|
| USBSafeTest.hs:39:57:
| Couldn't match expected type `forall s.
| RegionalDeviceHandle (RegionT s pr)
| - RegionT s pr α'
| with actual type `RegionalDeviceHandle (RegionT s pr)
| - RegionT s pr α'
| In the fourth argument of `useWhich', namely `f'
| In the expression: useWhich devs withDevice p f
| In the expression:
| do { devs - return [Device];
|useWhich devs withDevice p f }
|
|
| {-# LANGUAGE UnicodeSyntax
|, KindSignatures
|, RankNTypes
|, MultiParamTypeClasses
|, FunctionalDependencies
| #-}
|
| import Data.List (find)
|
| data Ctx = Ctx
| data Device = Device
| data DeviceDesc = DeviceDesc
| data RegionalDeviceHandle (r ∷ * → *) = RegionalDeviceHandle
| data RegionT s (pr ∷ * → *) α = RegionT
|
| instance Monad pr ⇒ Monad (RegionT s pr) where
| return = undefined
| (=) = undefined
|
| runRegionT ∷ (∀ s. RegionT s pr α) → pr α
| runRegionT = undefined
|
| openDevice ∷ Device → RegionT s pr (RegionalDeviceHandle (RegionT s pr))
| openDevice = undefined
|
| withDevice ∷ Monad pr
|⇒ Device
|→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
|→ pr α
| withDevice dev f = runRegionT $ openDevice dev = f
|
| withDeviceWhich ∷ ∀ pr α
| . Monad pr
| ⇒ Ctx
| → (DeviceDesc → Bool)
| → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
| → pr α
| withDeviceWhich ctx p f = do devs ← return [Device]
| useWhich devs withDevice p f
|
| useWhich ∷ ∀ k desc e (m ∷ * → *) α
| . (GetDescriptor e desc)
| ⇒ [e]
| → (e → k → m α)
| → (desc → Bool)
| → k
| → m α
| useWhich ds w p f = case find (p . getDesc) ds of
| Nothing → error not found
| Just d → w d f
|
| class GetDescriptor α desc | α → desc, desc → α where
| getDesc ∷ α → desc
|
| instance GetDescriptor Device DeviceDesc where
| getDesc = undefined
|
|
| I could isolate it a bit more if you want.
|
| Thanks,
|
| Bas
Re: Type error in GHC-7 but not in GHC-6.12.3
(resending this to the list because this failed yesterday because of
the mailinglist downtime)
On Sat, Oct 30, 2010 at 1:57 AM, Bas van Dijk v.dijk@gmail.com wrote:
I could isolate it a bit more if you want.
And so I did. The following is another instance of the problem I'm
having but set in a more familiar setting:
{-# LANGUAGE RankNTypes #-}
import Control.Monad.ST
foo :: (forall s. ST s a) - a
foo st = ($) runST st
Couldn't match expected type `forall s. ST s a'
with actual type `ST s a'
In the second argument of `($)', namely `st'
Note that: 'foo st = runST st' type checks as expected.
Surprisingly 'foo st = runST $ st' also type checks!
I find the latter surprising because according to the report[1]: e1 op
e2 = (op) e1 e2. So either both should type check or both should fail.
I guess that a RULE somewhere eliminates the ($) before the
type-checker kicks in. I do find that a little strange because I
thought RULES where applied after type checking.
Regards,
Bas
[1] http://www.haskell.org/onlinereport/exps.html#operators
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Type error in GHC-7 but not in GHC-6.12.3
Hello, I'm updating my usb-safe package for GHC-7: darcs get http://code.haskell.org/~basvandijk/code/usb-safe It depends on the HEAD version of regions: darcs get http://code.haskell.org/~basvandijk/code/regions I think I'm suffering from the new implied MonoLocalBinds extension (I'm using GADTs) as described in: http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 However, I'm not sure this is the problem because I'm not using local bindings and use explicit type signatures everywhere. I try to make a small isolated example when I have time but for now let's use the actual definitions: The following function type-checked fine in GHC-6.12.3 but fails in GHC-7.1.20101027: withDeviceWhich ∷ ∀ pr α . MonadCatchIO pr ⇒ USB.Ctx → (USB.DeviceDesc → Bool) → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α) → pr α withDeviceWhich ctx p f = do devs ← liftIO $ USB.getDevices ctx useWhich devs withDevice p f The error I get is: Couldn't match expected type `forall s. RegionalDeviceHandle (RegionT s pr) - RegionT s pr α' with actual type `RegionalDeviceHandle (RegionT s pr) - RegionT s pr α' In the fourth argument of `useWhich', namely `f' These are the types and definitions of the other functions involved: useWhich ∷ ∀ k desc e (m ∷ * → *) α . (GetDescriptor e desc, MonadIO m) ⇒ [e] → (e → k → m α) → (desc → Bool) → k → m α useWhich ds w p f = case find (p ∘ getDesc) ds of Nothing → throw USB.NotFoundException Just d → w d f withDevice ∷ MonadCatchIO pr ⇒ USB.Device → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α) → pr α withDevice dev f = runRegionT $ openDevice dev = f Note that when I inline the definition of useWhich it type-checks fine: withDeviceWhich ctx p f = do devs ← liftIO $ USB.getDevices ctx case find (p ∘ getDesc) devs of Nothing → throw USB.NotFoundException Just d → withDevice d f Since I'm not using local bindings and use explicit type signatures everywhere, I'm not sure MonoLocalBinds is the problem. Note that other applications of useWhich which also use RankNTypes type-check just fine in both GHC-6.12.3 and GHC-7.1.20101027: --- setConfigWhich ∷ ∀ pr cr α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ RegionalDeviceHandle pr → (USB.ConfigDesc → Bool) → (∀ sCfg. ConfigHandle sCfg → cr α) → cr α setConfigWhich h = useWhich (getConfigs h) setConfig getConfigs ∷ RegionalDeviceHandle r → [Config r] setConfig ∷ ∀ pr cr α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ Config pr → (∀ sCfg. ConfigHandle sCfg → cr α) → cr α --- withInterfaceWhich ∷ ∀ pr sCfg α . MonadCatchIO pr ⇒ ConfigHandle sCfg → (USB.Interface → Bool) → (∀ s. RegionalInterfaceHandle sCfg (RegionT s pr) → RegionT s pr α) → pr α withInterfaceWhich h = useWhich (getInterfaces h) withInterface getInterfaces ∷ ConfigHandle sCfg → [Interface sCfg] withInterface ∷ ∀ pr sCfg α . MonadCatchIO pr ⇒ Interface sCfg → (∀ s. RegionalInterfaceHandle sCfg (RegionT s pr) → RegionT s pr α) → pr α --- setAlternateWhich ∷ ∀ pr cr sCfg α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ RegionalInterfaceHandle sCfg pr → (USB.InterfaceDesc → Bool) → (∀ sAlt. AlternateHandle sAlt pr → cr α) → cr α setAlternateWhich h = useWhich (getAlternates h) setAlternate getAlternates ∷ RegionalInterfaceHandle sCfg r → [Alternate sCfg r] setAlternate ∷ ∀ pr cr sCfg α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ Alternate sCfg pr → (∀ sAlt. AlternateHandle sAlt pr → cr α) → cr α --- I'm happy to provide more info when needed. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error in GHC-7 but not in GHC-6.12.3
On Fri, Oct 29, 2010 at 5:42 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
That looks odd.
Can you isolate it for us? The easiest thing is usually to start with the
offending code:
withDeviceWhich ∷
∀ pr α
. MonadCatchIO pr
⇒ USB.Ctx
→ (USB.DeviceDesc → Bool)
→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
→ pr α
withDeviceWhich ctx p f = do
devs ← liftIO $ USB.getDevices ctx
useWhich devs withDevice p f
Now add local definitions for each of the functions mentioned, with
definition foo = undefined.
useWhich ∷
∀ k desc e (m ∷ * → *) α
. (GetDescriptor e desc, MonadIO m)
⇒ [e]
→ (e → k → m α)
→ (desc → Bool)
→ k
→ m α
useWhich = undefined.
Now all you need is the types involved, and you can probably define them as
data RegionT s pr a
etc
That should give a standalone test case.
Thanks!
SImon
Ok, Here's the more isolated program which still gives the same error
as the full usb-safe (on the latest ghc-HEAD (7.1.20101029)):
USBSafeTest.hs:39:57:
Couldn't match expected type `forall s.
RegionalDeviceHandle (RegionT s pr)
- RegionT s pr α'
with actual type `RegionalDeviceHandle (RegionT s pr)
- RegionT s pr α'
In the fourth argument of `useWhich', namely `f'
In the expression: useWhich devs withDevice p f
In the expression:
do { devs - return [Device];
useWhich devs withDevice p f }
{-# LANGUAGE UnicodeSyntax
, KindSignatures
, RankNTypes
, MultiParamTypeClasses
, FunctionalDependencies
#-}
import Data.List (find)
data Ctx = Ctx
data Device = Device
data DeviceDesc = DeviceDesc
data RegionalDeviceHandle (r ∷ * → *) = RegionalDeviceHandle
data RegionT s (pr ∷ * → *) α = RegionT
instance Monad pr ⇒ Monad (RegionT s pr) where
return = undefined
(=) = undefined
runRegionT ∷ (∀ s. RegionT s pr α) → pr α
runRegionT = undefined
openDevice ∷ Device → RegionT s pr (RegionalDeviceHandle (RegionT s pr))
openDevice = undefined
withDevice ∷ Monad pr
⇒ Device
→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
→ pr α
withDevice dev f = runRegionT $ openDevice dev = f
withDeviceWhich ∷ ∀ pr α
. Monad pr
⇒ Ctx
→ (DeviceDesc → Bool)
→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
→ pr α
withDeviceWhich ctx p f = do devs ← return [Device]
useWhich devs withDevice p f
useWhich ∷ ∀ k desc e (m ∷ * → *) α
. (GetDescriptor e desc)
⇒ [e]
→ (e → k → m α)
→ (desc → Bool)
→ k
→ m α
useWhich ds w p f = case find (p . getDesc) ds of
Nothing → error not found
Just d → w d f
class GetDescriptor α desc | α → desc, desc → α where
getDesc ∷ α → desc
instance GetDescriptor Device DeviceDesc where
getDesc = undefined
I could isolate it a bit more if you want.
Thanks,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-paths package build error with GHC 6.12.1 RC2
On 24/11/2009 03:16, Daniel Schüssler wrote: Hi, see below. Greetings, Daniel $ cabal install ghc-paths Resolving dependencies... [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/dist/setup/Main.o ) /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: `preMakefile' is not a (visible) constructor field name cabal: Error: some packages failed to install: ghc-paths-0.1.0.5 failed during the configure step. The exception was: ExitFailure 1 Fixed version 0.1.0.6 uploaded to Hackage. Thanks for the report! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-paths package build error with GHC 6.12.1 RC2
Thanks :) Greetings, Daniel On Tuesday 24 November 2009 12:16:18 Simon Marlow wrote: On 24/11/2009 03:16, Daniel Schüssler wrote: Hi, see below. Greetings, Daniel $ cabal install ghc-paths Resolving dependencies... [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/dist/setup/Main.o ) /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: `preMakefile' is not a (visible) constructor field name cabal: Error: some packages failed to install: ghc-paths-0.1.0.5 failed during the configure step. The exception was: ExitFailure 1 Fixed version 0.1.0.6 uploaded to Hackage. Thanks for the report! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-paths package build error with GHC 6.12.1 RC2
Hi, see below. Greetings, Daniel $ cabal install ghc-paths Resolving dependencies... [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/dist/setup/Main.o ) /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: `preMakefile' is not a (visible) constructor field name cabal: Error: some packages failed to install: ghc-paths-0.1.0.5 failed during the configure step. The exception was: ExitFailure 1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Error building GHC 6.8.3 with MinGW 4.2.1-2 dw2
I try to build a lite version (e.g. no extra libs) of GHC 6.8.3, I'm using MinGW GCC 4.2.1-2 with dwarf-2 exception and pre-compiled GHC 6.8.3. Here's my configure: sh configure --prefix=/c/ghc-new CFLAGS='-s -O2' LDFLAGS='-s -O2' --with-gmp-includes=/usr/local/gmp/include --with-gmp-libraries=/usr/local/gmp/lib And my make: make bootstrap3 But in the middle, I got this: Preprocessing library hpc-0.5.0.1... In file included from D:/Sources/ghc/ghc-6.8.3-lite/includes/Stg.h:183, from D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:19, from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Regs.h:28:17: error: gmp.h: No such file or directory In file included from D:/Sources/ghc/ghc-6.8.3-lite/includes/Stg.h:183, from D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:19, from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Regs.h:121: error: expected specifier-qua lifier-list before 'MP_INT' In file included from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:203: error: expected ')' before '*' token D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:204: error: expected ')' before '*' token compiling dist\build\Trace\Hpc\Reflect_hsc_make.c failed command was: gcc -c -mno-cygwin -D__GLASGOW_HASKELL__=608 -ID:/Sources/ghc/ghc-6 .8.3-lite/includes -ID:/Sources/ghc/ghc-6.8.3-lite/gmp/gmpbuild -I/usr/local/gmp /include -D__GLASGOW_HASKELL__=608 dist\build\Trace\Hpc\Reflect_hsc_make.c -o di st\build\Trace\Hpc\Reflect_hsc_make.o make[2]: Entering directory `/d/Sources/ghc/ghc-6.8.3-lite/libraries/hpc' make[2]: *** No targets specified and no makefile found. Stop. make[2]: Leaving directory `/d/Sources/ghc/ghc-6.8.3-lite/libraries/hpc' make[1]: *** [make.library.hpc] Error 2 make[1]: Leaving directory `/d/Sources/ghc/ghc-6.8.3-lite/libraries' make: *** [stage1] Error 2 As you can see above, I have gmp installed under /usr/local/gmp. However, this is not the gmp that comes with GHC (version 4.2.1, mine is 4.2.2). PS: I must comment these two lines in IOManager.h: 12: extern void* GetCurrentFiber ( void ); 13: extern void* GetFiberData ( void ); or an error about static declaration follows non-static declaration will come up. -- View this message in context: http://www.nabble.com/Error-building-GHC-6.8.3-with-MinGW-4.2.1-2-dw2-tp18190163p18190163.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 5/2/07, Bertram Felgenhauer [EMAIL PROTECTED] wrote:
...
I have two patches that should fix this:
...
Thanks, I applied base-install-includes.patch.
(Cabal-fix-installIncludeFiles.patch was already applied according to
darcs.)
However, in order to apply the patches I did a new checkout of GHC
without the --partial. This seemed to have pulled a few new patches
that break my build again.
I fixed the first error (I darcs send the patch):
./compiler/coreSyn/CoreUtils.lhs 262
-mkAltExpr DEFAULT = panic mkAltExpr
+mkAltExpr DEFAULT _ _ = panic mkAltExpr
This leaves the second error when building base:
Building base-2.1...
GHC/Exts.hs:29:1:
Not in scope: type constructor or class `IsString'
If I import Data.String in GHC/Exts.hs I get the following error:
Building base-2.1...
ghc-6.7.20070502: panic! (the 'impossible' happened)
(GHC version 6.7.20070502 for i386-unknown-linux):
mkWWcpr: not a product base:Data.Typeable.TypeRep{tc r3eN}
What can be the problem?
regards,
Bas van Dijk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Error compiling GHC/Num.lhs
the base library is in a bit of a sad state.
I think I have fixed it. Try pulling (both compiler and libraries) and try
again
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Bas van Dijk
| Sent: 03 May 2007 11:32
| To: Bertram Felgenhauer
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Error compiling GHC/Num.lhs
|
| On 5/2/07, Bertram Felgenhauer [EMAIL PROTECTED] wrote:
| ...
| I have two patches that should fix this:
| ...
|
| Thanks, I applied base-install-includes.patch.
| (Cabal-fix-installIncludeFiles.patch was already applied according to
| darcs.)
|
| However, in order to apply the patches I did a new checkout of GHC
| without the --partial. This seemed to have pulled a few new patches
| that break my build again.
|
| I fixed the first error (I darcs send the patch):
|
| ./compiler/coreSyn/CoreUtils.lhs 262
| -mkAltExpr DEFAULT = panic mkAltExpr
| +mkAltExpr DEFAULT _ _ = panic mkAltExpr
|
|
| This leaves the second error when building base:
|
| Building base-2.1...
|
| GHC/Exts.hs:29:1:
| Not in scope: type constructor or class `IsString'
|
| If I import Data.String in GHC/Exts.hs I get the following error:
|
| Building base-2.1...
| ghc-6.7.20070502: panic! (the 'impossible' happened)
| (GHC version 6.7.20070502 for i386-unknown-linux):
| mkWWcpr: not a product base:Data.Typeable.TypeRep{tc r3eN}
|
| What can be the problem?
|
| regards,
|
| Bas van Dijk
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 5/3/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: I think I have fixed it... You did, thanks very much! GHC now builds and install without any errors, jippy! Thanks, Bas van Dijk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
Bas van Dijk wrote: However the build now crashes when running Haddock on Cabal: ... ifBuildable/ifBuildable Cabal setup/Setup haddock Preprocessing library Cabal-1.1.7... Running Haddock for Cabal-1.1.7... Warning: cannot use package base-2.1: ghc-pkg failed dist/build/tmp/Distribution/PreProcess.hs:Distribution/PreProcess.hs: 115:1: parse error in doc string: [TokSpecial '/',TokString build,TokSpecial ''] make[1]: *** [doc.library.Cabal] Error 1 make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' make: *** [stage1] Error 2 Thanks, I think I've fixed this one now. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote:
Thanks, I think I've fixed this one now.
You did indeed, thanks!
Now I get another error when compiling main/GHC.hs:
../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64
-opta-march=athlon64 -istage2/utils -istage2/basicTypes
-istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename
-istage2/typecheck -istage2/deSugar -istage2/coreSyn
-istage2/specialise -istage2/simplCore -istage2/stranal
-istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main
-istage2/profiling -istage2/parser -istage2/cprAnalysis
-istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen
-istage2/ghci -Istage2 -DGHCI -package template-haskell
-DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE
-cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package
unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot
-fasm -H16M '-#include cutils.h' -package-name ghc-6.7.20070502
-fgenerics-c main/GHC.hs -o stage2/main/GHC.o -ohi
stage2/main/GHC.hi
main/GHC.hs:2223:50:
Couldn't match expected type `InteractiveContext'
against inferred type `[Name]'
In the sixth argument of `ResumeHandle', namely `names'
In the expression:
ResumeHandle
breakMVar statusMVar final_names final_ic resume_ic names
In the definition of `res':
res = ResumeHandle
breakMVar statusMVar final_names final_ic resume_ic names
main/GHC.hs:2230:54:
Couldn't match expected type `InteractiveContext'
against inferred type `[Name]'
In the `hsc_IC' field of a record
In the second argument of `writeIORef', namely
`hsc_env {hsc_IC = final_ic}'
In the expression: writeIORef ref (hsc_env {hsc_IC = final_ic})
main/GHC.hs:2270:26:
Constructor `ResumeHandle' should have 7 arguments, but has been given 6
In the pattern:
ResumeHandle breakMVar
statusMVar
final_names
final_ic
resume_ic
names
In the definition of `resume':
resume (Session ref)
(res@(ResumeHandle breakMVar
statusMVar
final_names
final_ic
resume_ic
names))
= do hsc_env - readIORef ...
writeIORef ... (...)
ghc: 119216100 bytes, 25 GCs, 6699552/13740056 avg/max bytes
residency (4 samples), 27M in use, 0.00 INIT (0.00 elapsed), 0.49 MUT
(0.54 elapsed), 0.33 GC (0.34 elapsed) :ghc
make[2]: *** [stage2/main/GHC.o] Error 1
make[2]: Leaving directory `/home/bas/development/haskell/ghc/compiler'
make[1]: *** [stage2] Error 2
make[1]: Leaving directory `/home/bas/development/haskell/ghc'
make: *** [bootstrap2] Error 2
regards,
Bas van Dijk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
Bas van Dijk wrote: On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote: Thanks, I think I've fixed this one now. You did indeed, thanks! Now I get another error when compiling main/GHC.hs: ../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64 -opta-march=athlon64 -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE -threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -package Cabal -ignore-package lang -recomp -Rghc-timing -Onot -fasm -H16M '-#include cutils.h' -package-name ghc-6.7.20070502 -fgenerics-c main/GHC.hs -o stage2/main/GHC.o -ohi stage2/main/GHC.hi main/GHC.hs:2223:50: Couldn't match expected type `InteractiveContext' against inferred type `[Name]' In the sixth argument of `ResumeHandle', namely `names' In the expression: ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names In the definition of `res': res = ResumeHandle breakMVar statusMVar final_names final_ic resume_ic names I believe this one is now fixed, sorry about that. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote: I believe this one is now fixed, sorry about that. No problem. I'm now able to successfully make GHC. Thanks about that! However 'make install' fails: $ make install ... ifBuildable/ifBuildable base setup/Setup install copy directory 'dist/doc/html/base' to '/home/bas/share/ghc/doc/html/base'. ... copy dist/build/HSbase-2.1.o to /home/bas/lib/base-2.1/ghc-6.7.20070502/HSbase-2.1.o Registering base-2.1... Reading package info from .installed-pkg-config ... done. ghc-pkg: /home/bas/lib/base-2.1/ghc-6.7.20070502/include doesn't exist or isn't a directory (use --force to override) make[1]: *** [install.library.base] Error 1 make: *** [install] Error 1 The directory: /home/bas/lib/base-2.1/ghc-6.7.20070502/include indeed does not exists. What can be the problem? regards, Bas van Dijk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
[Note: Sorry if this is a duplicate. I originally sent the patches inline in the mail, but the resulting mail grew rather big and is awaiting moderators approval now. (moderators: no need to approve it)] Bas van Dijk wrote: On 5/2/07, Simon Marlow [EMAIL PROTECTED] wrote: I believe this one is now fixed, sorry about that. No problem. I'm now able to successfully make GHC. Thanks about that! However 'make install' fails: $ make install ... ifBuildable/ifBuildable base setup/Setup install copy directory 'dist/doc/html/base' to '/home/bas/share/ghc/doc/html/base'. ... copy dist/build/HSbase-2.1.o to /home/bas/lib/base-2.1/ghc-6.7.20070502/HSbase-2.1.o Registering base-2.1... Reading package info from .installed-pkg-config ... done. ghc-pkg: /home/bas/lib/base-2.1/ghc-6.7.20070502/include doesn't exist [...] I'm sorry, that's my fault. I have two patches that should fix this: One for libraries/Cabal, http://int-e.home.tlink.de/haskell/Cabal-fix-installIncludeFiles.patch and another for libraries/base: http://int-e.home.tlink.de/haskell/base-install-includes.patch The semantics for the includes: and install-includes: fields in cabal files has changed; the patch against base adds an install-includes field to the base.cabal file that uses the new semantics. I was going to send this patch in now anyway. I'm afraid I missed the interaction of the install directory and the package registration, and obviously I didn't test this properly. So I revert the behaviour back to always creating the include directory. Bertram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
On 4/29/07, Ian Lynagh [EMAIL PROTECTED] wrote:
Hi Bas,
On Sun, Apr 29, 2007 at 11:54:35AM +, Bas van Dijk wrote:
I'm trying to build GHC from darcs. Unfortunately compilation fails
with the following error:
...
cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1)
in GHC/Num.lhs at line 27 col 1
make[1]: *** [doc.library.base] Error 1
make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries'
make: *** [stage1] Error 2
...
The following is the part where the error occurs in
libraries/base/GHC/Num.lhs :
...
#include MachDeps.h
#if SIZEOF_HSWORD == 4
This is a cpphs bug - IIRC it wasn't recursively expanding
SIZEOF_HSWORD. Either install cpphs from darcs (I don't think there is a
release with the fix yet) or uninstall it so that cpp is used instead.
Thanks
Ian
After uninstalling cpphs the error no longer occurs, thanks!
However the build now crashes when running Haddock on Cabal:
...
ifBuildable/ifBuildable Cabal setup/Setup haddock
Preprocessing library Cabal-1.1.7...
Running Haddock for Cabal-1.1.7...
Warning: cannot use package base-2.1:
ghc-pkg failed
dist/build/tmp/Distribution/PreProcess.hs:Distribution/PreProcess.hs:
115:1: parse error in doc string: [TokSpecial '/',TokString
build,TokSpecial '']
make[1]: *** [doc.library.Cabal] Error 1
make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries'
make: *** [stage1] Error 2
The respected code from libraries/Cabal/Distribution/PreProcess.hs
(line 115 and onwards a bit):
data PreProcessor = PreProcessor {
-- Is the output of the pre-processor platform independent? eg happy
output
-- is portable haskell but c2hs's output is platform dependent.
-- This matters since only platform independent generated code can
be
-- inlcuded into a source tarball.
platformIndependent :: Bool,
-- TODO: deal with pre-processors that have implementaion dependent
output
-- eg alex and happy have --ghc flags. However we can't really
inlcude
-- ghc-specific code into supposedly portable source tarballs.
runPreProcessor :: (FilePath, FilePath) -- Location of the source
file relative to a base dir
- (FilePath, FilePath) -- Output file name,
relative to an output base dir
- Int -- verbosity
- IO ()-- Should exit if the preprocessor fails
}
Do I maybe need a newer Haddock for this? Currently I have version
0.8. Installing darcs version right now...
Thanks,
Bas van Dijk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Error compiling GHC/Num.lhs
Hello, I'm trying to build GHC from darcs. Unfortunately compilation fails with the following error: ... cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1) in GHC/Num.lhs at line 27 col 1 make[1]: *** [doc.library.base] Error 1 make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' make: *** [stage1] Error 2 ... The following is the part where the error occurs in libraries/base/GHC/Num.lhs : ... #include MachDeps.h #if SIZEOF_HSWORD == 4 #define LEFTMOST_BIT 2147483648 #define DIGITS 9 #define BASE 10 #elif SIZEOF_HSWORD == 8 #define LEFTMOST_BIT 9223372036854775808 #define DIGITS 18 #define BASE 100 #else #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1) -- DIGITS should be the largest integer such that 10^DIGITS LEFTMOST_BIT -- BASE should be 10^DIGITS. Note that ^ is not available yet. #endif ... Note that in build.mk I set BuildFlavour = quick and I also tried building it with the following options added: SRC_HC_OPTS += -optc-march=athlon64 -opta-march=athlon64 SRC_CC_OPTS += -march=athlon64 What can be the problem? Thanks, Bas van Dijk Some info on my system (please ask for more if you need it): $ uname -a Linux bassbox 2.6.20-gentoo-r6 #1 PREEMPT Thu Apr 19 10:53:57 CEST 2007 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux $ gcc --version gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error compiling GHC/Num.lhs
Hi Bas, On Sun, Apr 29, 2007 at 11:54:35AM +, Bas van Dijk wrote: I'm trying to build GHC from darcs. Unfortunately compilation fails with the following error: ... cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1) in GHC/Num.lhs at line 27 col 1 make[1]: *** [doc.library.base] Error 1 make[1]: Leaving directory `/home/bas/development/haskell/ghc/libraries' make: *** [stage1] Error 2 ... The following is the part where the error occurs in libraries/base/GHC/Num.lhs : ... #include MachDeps.h #if SIZEOF_HSWORD == 4 This is a cpphs bug - IIRC it wasn't recursively expanding SIZEOF_HSWORD. Either install cpphs from darcs (I don't think there is a release with the fix yet) or uninstall it so that cpp is used instead. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bad interface file error with GHC RC2
Krasimir Angelov wrote: Building with -package-name comlib-0.1 helps. I saw that Cabal from HEAD is passing the full package id to GHC but the version compiled in ghc-6.5.20061001 is passing just the package name. Maybe the change wasn't merged in GHC-6.6 branch or the bundle wasn't build from the actual sources. I just looked in the Cabal sources from the 6.6 branch: let ghcArgs = pkg_conf ++ [-package-name, showPackageId (package pkg_descr) ] So it certainly passes the entire package ID (including the version) to GHC. So I'm confused! Could you perhaps have an old Setup binary left in your build tree? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bad interface file error with GHC RC2
I am using something like this: c:\ghc\ghc-6.5.20061001\bin\runghc Setup.lhs for building. So an old binary shouldn't matter. With -v option I saw that: -package comlib is passed. Is it possible to have .tar.gz bundle compiled with an old Cabal? I suppose that runghc is always using ghc from its own directory instead of those in the path. Cheers, Krasimir On 10/5/06, Simon Marlow [EMAIL PROTECTED] wrote: Krasimir Angelov wrote: Building with -package-name comlib-0.1 helps. I saw that Cabal from HEAD is passing the full package id to GHC but the version compiled in ghc-6.5.20061001 is passing just the package name. Maybe the change wasn't merged in GHC-6.6 branch or the bundle wasn't build from the actual sources. I just looked in the Cabal sources from the 6.6 branch: let ghcArgs = pkg_conf ++ [-package-name, showPackageId (package pkg_descr) ] So it certainly passes the entire package ID (including the version) to GHC. So I'm confused! Could you perhaps have an old Setup binary left in your build tree? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bad interface file error with GHC RC2
On 10/4/06, Ian Lynagh [EMAIL PROTECTED] wrote: Did it work with earlier RCs? It was working with a version slightly older than RC1. Definitely with a version without the advanced packages support. Does comlib get wired into the compiler at all? I had a similar problem with base, where the compiler had the package name wired in: compiler/main/PackageConfig.hs: basePackageId = fsToPackageId FSLIT(base) but cabal was building it with -package-name base-2.0 To solve it I put -package-name base in ghc-options in the cabal file. Thanks Ian I am sure comlib isn't wired into the compiler. Perhaps there is a problem with Cabal somewhere. I will try to put custom -package-name option. If that works I will take a look into Cabal. Cheers, Krasimir ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bad interface file error with GHC RC2
Building with -package-name comlib-0.1 helps. I saw that Cabal from HEAD is passing the full package id to GHC but the version compiled in ghc-6.5.20061001 is passing just the package name. Maybe the change wasn't merged in GHC-6.6 branch or the bundle wasn't build from the actual sources. Cheers, Krasimir On 10/4/06, Krasimir Angelov [EMAIL PROTECTED] wrote: On 10/4/06, Ian Lynagh [EMAIL PROTECTED] wrote: Did it work with earlier RCs? It was working with a version slightly older than RC1. Definitely with a version without the advanced packages support. Does comlib get wired into the compiler at all? I had a similar problem with base, where the compiler had the package name wired in: compiler/main/PackageConfig.hs: basePackageId = fsToPackageId FSLIT(base) but cabal was building it with -package-name base-2.0 To solve it I put -package-name base in ghc-options in the cabal file. Thanks Ian I am sure comlib isn't wired into the compiler. Perhaps there is a problem with Cabal somewhere. I will try to put custom -package-name option. If that works I will take a look into Cabal. Cheers, Krasimir ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bad interface file error with GHC RC2
When I tried to build VSHaskell with the RC2 version of GHC I got the following error: src\lib\Registry.hsc:30:0: Bad interface file: C:\Program Files\Haskell\comlib-0.1\ghc-6.5.20061001/Com Dll.hi Something is amiss; requested module comlib-0.1:ComDll differs from nam e found in the interface file comlib:ComDll Am I doing something wrong or it is a bug? The COM library is built using Cabal. Cheers, Krasimir ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Linking error in GHC 6.4.2 snapshot of 21 April (mingw).
When I downloaded and unpacked the latest GHC snapshot of the STABLE branch for Windows (ghc-6.4.2.20060421-i386-unknown-mingw32.tar.gz), I got the following error trying to start GHCi: ___ ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base-1.0 ... linking ... : c:/ghc/GHC-64~1.2/HSbase1.o: unknown symbol `_sqrtf' : unable to load package `base-1.0' ___ The complaint about _sqrtf also shows up when I try to compile/link anything with ghc; so the problem is bigger than just not being able to use GHCi. The GHC is installed in c:\ghc\ghc-6.4.2, the PATH begins with c:\ghc\ghc-6.4.2;c:\ghc\ghc-6.4.2\bin;c:\ghc\ghc-6.4.2\gcc-lib; LIBRARY_PATH is set to c:\ghc\ghc-6.4.2\gcc-lib I know for sure that the 6.4.2 snapshot of a couple of weeks ago worked fine, so I wonder what might be wrong with the latest one. I would appreciate any hints. Cheers, Cyril ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Linking error in GHC 6.4.2 snapshot of 21 April (mingw).
This solves the problem, thanks! Cyril Simon Marlow wrote: Cyril Schmidt wrote: When I downloaded and unpacked the latest GHC snapshot of the STABLE branch for Windows (ghc-6.4.2.20060421-i386-unknown-mingw32.tar.gz), I got the following error trying to start GHCi: Loading package base-1.0 ... linking ... : c:/ghc/GHC-64~1.2/HSbase1.o: unknown symbol `_sqrtf' : unable to load package `base-1.0' Sigbjorn's candidate installer doesn't have this problem: http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-2-20060421.msi It's a bug in 6.4.2, sadly. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error in GHC
Thanks Lemmih. I already fixed this error. The module declaration in my Main file was giving it a wrong name (not Main).Thank you. Lemmih [EMAIL PROTECTED] escreveu: On 1/18/06, Tays Soares wrote: I'm trying to run the following sequence on ghc 6.4: ghc -fglasgow-exts --make Main ghc -o exec Main.o Exemplo1.o But I always get this error message after the second command: /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main': : undefined reference to `__stginit_ZCMain' /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main': : undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status Please , does anybody know what can I do to fix it?Does your main module contain a function called "main"? Does "ghc-fglasgow-exts --make Main -o exec" work?--Friendly, LemmihTays Cristina do Amaral Pales Soares Yahoo! doce lar. Faça do Yahoo! sua homepage.___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Error in GHC
I'm trying to run the following sequence on ghc 6.4: ghc -fglasgow-exts --make Main ghc -o exec Main.o Exemplo1.oBut I always get this error message after the second command:/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main':: undefined reference to `__stginit_ZCMain'/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main':: undefined reference to `ZCMain_main_closure'collect2: ld returned 1 exit statusPlease, does anybody know what can I do to fix it?ThanksTays Cristina do Amaral Pales Soares Yahoo! doce lar. Faça do Yahoo! sua homepage.___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
