- Glasgow-haskell-users

Using old code generator
by Roman Cheplyaka 12 Apr '13

12 Apr '13

Hi, I'm looking for a workaround for #7574 [1] (I run into it when trying to build the 'statistics' package with profiling enabled with GHC HEAD.) The symptom is ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130407 for i386-unknown-linux): allocateRegsAndSpill: Cannot read from uninitialized register %vI_cCdO [1]: http://hackage.haskell.org/trac/ghc/ticket/7574 Do I understand correctly that this bug is specific to the new codegen? If so, is it possible to ask the compiler to use the old codegen? Is it okay to mix together packages compiled with both codegens? Thanks, Roman

2 2

Does GHC on cygwin have an I/O manager?
by kudah 08 Apr '13

08 Apr '13

I've been desperate to get any semblance of I/O performance from Haskell on Windows. Does ghc still build under cygwin, and if so, does the cygwin build have a working I/O manager? Also, is it possible yet to build a ghc cross-compiler targeting windows?

2 2

Problems installing 7.6.2 on MACOS
by Dominic Steinitz 07 Apr '13

07 Apr '13

Hi, I followed the instructions pointed to from here: http://www.haskell.org/ghc/download_ghc_7_6_2#macosx_x86_64 > bash-3.2$ ./configure --prefix=/Library/Haskell > bash-3.2$ sudo make install But sadly I get: > bash-3.2$ ghc-pkg list > ghc-pkg: missing --global-package-db option, location of global package database unknown and > bash-3.2$ ghc --make nnClassifier.lhs -O2 > ghc: missing -B<dir> option Any advice on how to get 7.6.2 working would be much appreciated. Dominic. Here's some more information: > bash-3.2$ which ghc-pkg > /Library/Haskell/lib/ghc-7.6.2/ghc-pkg > bash-3.2$ which ghc > /Library/Haskell/lib/ghc-7.6.2/ghc 7.4.1 still works fine: > bash-3.2$ ghc-pkg-7.4.1 list > /Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/lib/ghc-7.4.1/package.conf.d: > Cabal-1.14.0 > GLUT-2.1.2.1 > bash-3.2$ ghc-7.4.1 --make nnClassifier.lhs -O2 -fforce-recomp > [1 of 6] Compiling MatrixPlus ( MatrixPlus.hs, MatrixPlus.o ) > [2 of 6] Compiling NeuralNet ( NeuralNet.hs, NeuralNet.o ) > [3 of 6] Compiling Backprop ( Backprop.hs, Backprop.o ) > [4 of 6] Compiling MarineExplore ( MarineExplore.hs, MarineExplore.o ) > [5 of 6] Compiling Runner ( Runner.hs, Runner.o ) > [6 of 6] Compiling Main ( nnClassifier.lhs, nnClassifier.o ) > Linking nnClassifier ... > ld: warning: directory not found for option '-L/opt/local/lib/' > bash-3.2$ ./nnClassifier > Reading training labels... > Read 100 labels[(1,0),(2,1),(3,0),(4,1),(5,0),(6,0),(7,1),(8,0),(9,1),(10,0)] > Reading training images... > 9:9 > 9:9

2 2

Allowing (Char ~ Bool => Void)?
by Shachaf Ben-Kiki 05 Apr '13

05 Apr '13

Is there a good reason that GHC doesn't allow any value of type (Char ~ Bool => Void), even undefined? There are various use cases for this. It's allowed indirectly, via GADT pattern matches -- "foo :: Is Char Bool -> Void; foo x = case x of {}" (with EmptyCase in HEAD) -- but not directly. One thing this prevents, for instance, is CPSifying GADTs: data Foo a = a ~ Char => A | a ~ Bool => B -- valid newtype Bar a = Bar { runBar :: forall r. (a ~ Char => r) -> (a ~ Bool => r) -> r } -- unusable Trying to use a type like the latter in practice runs into problems quickly because one needs to provide an absurd value of type (Char ~ Bool => r), which is generally impossible (even if we're willing to cheat with ⊥!). It seems that this sort of thing should be doable. Shachaf

4 6

ImplicitParams and MonoLocalBinds
by Roman Cheplyaka 03 Apr '13

03 Apr '13

The value of the following expression let ?y = 2 in let p = ?y in let ?y = 1 in p depends on whether the second binding is generalised. MonomorphismRestriction makes it not generalise, hence the value is 2. What surprises me is that MonoLocalBinds doesn't have this effect. Prelude> :set -XImplicitParams -XNoMonomorphismRestriction -XMonoLocalBinds Prelude> let ?y = 2 in let p = ?y in let ?y = 1 in p 1 What's going on here? Roman

3 4

Re: porting to uClibc-based 686 Linux
by Dubiousjim 03 Apr '13

03 Apr '13

On Wed, Apr 03, 2013 at 09:56:58AM -0400, Dubiousjim wrote: > Ok, with all of that, the build completes. And the build ghc-stage2 > (which I temporarily named inplace/lib/ghc-stage2.exe, but now let's > restore it to its original name) does in fact execute on the target > machine: > > $ inplace/lib/ghc-stage2 --version > The Glorious Glasgow Haskell Compilation System, version 7.6.2 > $ inplace/lib/ghc-stage2 --interactive > ghc-stage2: missing -B<dir> option > $ cat ~/hello.hs > main = putStrLn "Hello World!\n" > $ inplace/lib/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello > $ ./hello > Can't modify application's text section; use the GCC option -fPIE > for > position-independent executables. > > That's as far as I've got for now. Hopefully someone will have > bothered to read this far and have some suggestions for what I should be > doing differently, or how to proceed from here, to get the compiled > ghc-stage2 really working on the target machine, so that I can use it to > compile ghc on the target machine directly. Oh, in fact I'm closer than I thought. The error I reported as: > $ inplace/lib/ghc-stage2 -B./inplace/lib --interactive > GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... ghc-stage2: mmap 442368 bytes at (nil): > Operation not permitted > ghc-stage2: Try specifying an address with +RTS -xm<addr> -RTS is in fact due to my forgetfulness. My target system uses PaX kernel security, and so compilers like ghc have to be tweaked before they can be used: $ paxctl -c inplace/lib/ghc-stage2 $ paxctl -m inplace/lib/ghc-stage2 $ inplace/bin/ghc-stage2 -B./inplace/lib --interactive GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> Yay, the interpreter works! But there's still something funny with the binaries generated by the compiler. That means I can't yet use this ghc to directly recompile ghc on my target system. $ cat ~/hello.hs main = putStrLn "Hello World!\n" $ rm -f hello $ inplace/bin/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello [1 of 1] Compiling Main ( /home/jim/hello.hs, /home/jim/hello.o ) [flags changed] Linking hello ... $ ./hello Can't modify application's text section; use the GCC option -fPIE for position-independent executables. Seems like I'm close, but not quite there yet. Supplying the flag -fPIE to ghc when building hello says: ghc-stage2: unrecognised flags: -fPIE The flag -fPIC on the other hand is accepted, but then the generated binary hello still fails with the same error. -- dubiousjim(a)gmail.com

1 0

Re: porting to uClibc-based 686 Linux
by Dubiousjim 03 Apr '13

03 Apr '13

I've gotten somewhat further cross-compiling 7.6.2 sources, though still not all the way. I also tried following the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting with these sources, but couldn't get them to work either. This continues to log my efforts to follow the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling One thing I notice by comparing the 7.6.2 sources and the pre-release sources available at http://www.haskell.org/ghc/dist/current/dist/ghc-7.7-src.tar.bz2 is that the instructions at the wiki webpage just cited are tailored to the post-7.6.2 sources. Some of the configure settings should be different for 7.6.2. In particular, I had been using this: is that the instructions at the wiki webpage just cited are tailored to the post-7.6.2 sources. Some of the configure settings should be different for 7.6.2. In particular, I had been using this: ./configure --target=i686-buildroot-linux-uclibc --disable-largefile as the wiki pages seem to suggest. But now I see that I should also be setting --host for 7.6.2, and also supplying an --alien=<script> option. The latter is a script you need to write which will run on the host and take arguments of the form "run <cmd> <more arguments...>". It should then copy "<cmd>" to the target machine and execute "<cmd> <more arguments...>" there, passing through its stdout. Here is the alien script I'm using: #!/bin/sh -x TARGET=its.ip.address CMD=$2 shift 2 scp "$CMD" ${USER}@${TARGET}:alien.cache/ ssh ${USER}@${TARGET} alien.cache/"${CMD##*/}" "$@" That relies on the presence of a folder alien.cache in ${USER}'s home directory on the target machine. It also relies on your being able to ssh from host to target without requiring a password. This script seems to be invoked twice during my builds, for mkGHCConstants mkDerivedConstants There's a third time I think it should be invoked but isn't, and then I have to invoke it manually. (This is explained below.) So here are the steps I'm following now. Most everything described in my preceding email still seems to be necessary; I'm including those steps here as well. > To refresh, I'm trying to bootstrap from a working ghc (now I have 7.6.2 > installed on the host) on a typical Linux 686 host system, glibc-based, > to get a ghc that can be installed on a similar target system, differing > in that it uses uclibc instead of glibc. > > I have a working cross-compiler, and seem to have everything else I need > to have installed on my host. I did have to make sure that my > cross-compiler tree had gmp and libiconv and ncurses installed in it. > > I also had to edit the file /usr/lib/ghc-7.6.2/include/ghcautoconf.h > on my host system. This was #defining _FILE_OFFSET_BITS to 64, but the > uclibc on my target system wasn't compiled with large file support, > hence I thought the uclibc in my cross-compiler toolchain shouldn't be > either. But then that #define in the host's ghcautoconf.h was > conflicting. So I just commented it out for the time being. > > > Here's what I've done, on the host, from a clean detar of the ghc 7.6.2 > sources. > > I made this change at three locations in ghc's topmost > configure script, to get it to recognize my cross-compiler tag > "i686-buildroot-linux-uclibc": > > case "$build_vendor" in > - pc|gentoo) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 > + pc|gentoo|buildroot) # like i686-pc-linux-gnu and > i686-gentoo-freebsd8 > BuildVendor="unknown" > ;; > > (The other two locations are for $host_vendor and $target_vendor. Maybe > it's only necessary to do this for $target_vendor.) > > Next, here is my mk/build.mk file: > > # Fast build with optimised libraries, no profiling (RECOMMENDED): > BuildFlavour = quick > ... > # An unregisterised, optimised build of ghc, for porting: > # BuildFlavour = unreg > ... > > The rest as in mk/build.mk.sample > Next, the configure scripts for > libraries/{base,directory,integer-gmp,old-time,process,terminfo,time,unix} > would stall, complaining that the C compiler didn't generate > binaries they could execute. I fixed that by patching those configure > scripts like this---I don't know if this is correct, it may be the > source of my later troubles. On the other hand, I don't know how else > to get past the configure scripts failing. Adding switches like --host > and --host="" to my original configure, as an error message suggests, > seems to have no effect. > > @@ -2833,7 +2833,7 @@ > test $ac_status = 0; }; }; then > cross_compiling=no > else > - if test "$cross_compiling" = maybe; then > + if true || test "$cross_compiling" = maybe; then > cross_compiling=yes > else > { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in > \`$ac_pwd':" >&5 > Next, I had to make this patch to libraries/haskeline/cbits/h_wcwidth.c, > else I would get errors about types like size_t not being recognized. (I > forget the exact error.) > > @@ -59,6 +59,7 @@ > * Latest version: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c > */ > > +#include <stddef.h> > #include <wchar.h> > > struct interval { Here is the actual error message this patch avoids: "inplace/bin/mkdirhier" libraries/haskeline/dist-install/build/cbits//. HC [stage 1] libraries/haskeline/dist-install/build/cbits/h_wcwidth.o libraries/haskeline/cbits/h_wcwidth.c:70:31: error: unknown type name 'wchar_t' libraries/haskeline/cbits/h_wcwidth.c:122:26: error: unknown type name 'wchar_t' libraries/haskeline/cbits/h_wcwidth.c:207:1: error: unknown type name 'wchar_t' libraries/haskeline/cbits/h_wcwidth.c:207:48: error: unknown type name 'size_t' libraries/haskeline/cbits/h_wcwidth.c:230:30: error: unknown type name 'wchar_t' libraries/haskeline/cbits/h_wcwidth.c:298:1: error: unknown type name 'wchar_t' libraries/haskeline/cbits/h_wcwidth.c:298:52: error: unknown type name 'size_t' Ok, so here are the steps I'm currently using to configure and build: export PATH=${PATH}:/path/to/my/cross-compiler make distclean ./configure --host=i686-buildroot-linux-uclibc \ --target=i686-buildroot-linux-uclibc --disable-largefile \ --with-alien=/path/to/alien make As I mentioned in my previous email, at a certain point the build tries to execute: libraries/integer-gmp/cbits/mkGmpDerivedConstants > \ libraries/integer-gmp/cbits/GmpDerivedConstants.h where the first is a binary it generated using the cross-compiler. This won't run on the host system. Now we can run it by issuing the following command on the host: /path/to/alien run libraries/integer-gmp/cbits/mkGmpDerivedConstants > \ libraries/integer-gmp/cbits/GmpDerivedConstants.h As I also mentioned in my previous email, the build will also fail unless I add the following lines to libraries/base/include/HsBaseConfig.h: #define HTYPE_DOUBLE Double #define HTYPE_FLOAT Float That's based on what I see in my host system. The HsBaseConfig.h file is only generated during the build, so you can't make this change ahead of time; you have to wait for the build to fail, make the change, and then reissue "make". Now, with the new configure options, this build continues past stage1 and proceeds to build stage2 as well. However, it gets stuck while trying to build these binaries: utils/ghctags/dist-install/build/Main.o libraries/haskell98/dist-install/build/Prelude.o libraries/haskell2010/dist-install/build/Prelude.o It gets stuck because it tries to execute the inplace/lib/ghc-stage2 it has built, but this will only run on the target machine. What a pain. I was able to hack around this in an ugly way. I'll explain what I did, but it depends on the fact that my host environment is a chroot inside my target. You don't want to do this at home. So inside my home directory on the TARGET environment, I did this. CROSSPATH is the absolute path to my cross-compiler i686-buildroot-linux-uclibc-gcc in my host environment (that is, where / is the base of the chroot, not the base of the target's filesystem). GHCSOURCE is the absolute path to my ghc-7.6.2 source tree in the same host environment. mkdir -p ${CROSSPATH%/*} ln -s `which gcc` ${CROSSPATH} ln -s /path/on/target/to/host/chroot/$GHCSOURCE/libraries Then inside the ghc-7.6.2 folder in the host environment, I moved inplace/lib/ghc-stage2 to inplace/lib/ghc-stage2.exe and installed the following script as inplace/lib/ghc-stage2: #!/bin/sh -x TARGET=its.ip.address CMD=$0 ssh ${USER}@${TARGET} "${CMD}.exe" "$@" I also had to make $GHCSOURCE on my target machine be a symlink to /path/on/target/to/host/chroot/$GHCSOURCE. This will get me a bit further in the make process. There are two commands that fail even this way, and that I have to run manually on the target machine, to build utils/ghctags/dist-install/build/Main.o. Ok, with all of that, the build completes. And the build ghc-stage2 (which I temporarily named inplace/lib/ghc-stage2.exe, but now let's restore it to its original name) does in fact execute on the target machine: $ inplace/lib/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.6.2 $ inplace/lib/ghc-stage2 --interactive ghc-stage2: missing -B<dir> option $ inplace/lib/ghc-stage2 -B./inplace/lib --interactive GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... ghc-stage2: mmap 442368 bytes at (nil): Operation not permitted ghc-stage2: Try specifying an address with +RTS -xm<addr> -RTS $ cat ~/hello.hs main = putStrLn "Hello World!\n" $ inplace/lib/ghc-stage2 -B./inplace/lib ~/hello.hs -o hello $ ./hello Can't modify application's text section; use the GCC option -fPIE for position-independent executables. That's as far as I've got for now. Hopefully someone will have bothered to read this far and have some suggestions for what I should be doing differently, or how to proceed from here, to get the compiled ghc-stage2 really working on the target machine, so that I can use it to compile ghc on the target machine directly. -- dubiousjim(a)gmail.com

1 0

Re: porting to uClibc-based 686 Linux
by Dubiousjim 02 Apr '13

02 Apr '13

I've shifted my attempts to cross-compile to the 7.6.2 sources. Here I'm having better success with the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling, though it still takes some fiddling and in the end I am still getting stuck. To refresh, I'm trying to bootstrap from a working ghc (now I have 7.6.2 installed on the host) on a typical Linux 686 host system, glibc-based, to get a ghc that can be installed on a similar target system, differing in that it uses uclibc instead of glibc. I have a working cross-compiler, and seem to have everything else I need to have installed on my host. I did have to make sure that my cross-compiler tree had gmp and libiconv and ncurses installed in it. I also had to edit the file /usr/lib/ghc-7.6.2/include/ghcautoconf.h on my host system. This was #defining _FILE_OFFSET_BITS to 64, but the uclibc on my target system wasn't compiled with large file support, hence I thought the uclibc in my cross-compiler toolchain shouldn't be either. But then that #define in the host's ghcautoconf.h was conflicting. So I just commented it out for the time being. Here's what I've done, on the host, from a clean detar of the ghc 7.6.2 sources. I made this change at three locations in ghc's topmost configure script, to get it to recognize my cross-compiler tag "i686-buildroot-linux-uclibc": case "$build_vendor" in - pc|gentoo) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 + pc|gentoo|buildroot) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 BuildVendor="unknown" ;; (The other two locations are for $host_vendor and $target_vendor. Maybe it's only necessary to do this for $target_vendor.) Next, here is my mk/build.mk file: # Fast build with optimised libraries, no profiling (RECOMMENDED): BuildFlavour = quick ... # An unregisterised, optimised build of ghc, for porting: # BuildFlavour = unreg ... The rest as in mk/build.mk.sample Next, I had to make this patch to libraries/haskeline/cbits/h_wcwidth.c, else I would get errors about types like size_t not being recognized. (I forget the exact error.) @@ -59,6 +59,7 @@ * Latest version: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c */ +#include <stddef.h> #include <wchar.h> struct interval { Next, the configure scripts for libraries/{base,directory,integer-gmp,old-time,process,terminfo,time,unix} would stall, complaining that the C compiler didn't generate binaries they could execute. I fixed that by patching those configure scripts like this---I don't know if this is correct, it may be the source of my later troubles. On the other hand, I don't know how else to get past the configure scripts failing. Adding switches like --host and --host="" to my original configure, as an error message suggests, seems to have no effect. @@ -2833,7 +2833,7 @@ test $ac_status = 0; }; }; then cross_compiling=no else - if test "$cross_compiling" = maybe; then + if true || test "$cross_compiling" = maybe; then cross_compiling=yes else { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5 Here are the steps I'm using to configure and build: export PATH=${PATH}:/path/to/my/cross-compiler make distclean ./configure --target=i686-buildroot-linux-uclibc --disable-largefile make -k There are two further tweaks I have to make, during the build. I have to edit libraries/base/include/HsBaseConfig.h, and add the following lines: #define HTYPE_DOUBLE Double #define HTYPE_FLOAT Float That's based on what I see in my host system. Without these lines, the build won't complete. Also, at a certain point the build tries to execute: libraries/integer-gmp/cbits/mkGmpDerivedConstants > \ libraries/integer-gmp/cbits/GmpDerivedConstants.h where the first is a binary it generated using the cross-compiler. This won't run on the host system, so I have to manually run it on the target system. (Easy to do because the host is running in a chroot on the target.) Ok, with all that, I do get a build that completes successfully. However, there is no stage2 ghc. And if I do: make install DESTDIR=/somewhere the ghc that gets installed is linked against the glibc on my host system, rather that the uclibc I'm targetting. Sigh. Is there just some final step that I'm missing? Is my build.mk file wrong? Are my patches to the library configure files messing things up? If so, how else should I work around their failing when in vanilla condition? Sigh.

1 0

Re: porting to uClibc-based 686 Linux
by Dubiousjim 01 Apr '13

01 Apr '13

On Mon, Apr 01, 2013 at 01:11:20PM -0400, Dubiousjim wrote: > However, this fails at the following point: > > "" -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER > -D__GLASGOW_HASKELL__=704 -Iincludes -DNO_REGS > -DUSE_MINIINTERPRETER > -Iincludes -Iincludes/dist-derivedconstants/header > -Iincludes/dist-ghcconstants/header -Irts -DNOSMP -c > includes/mkDerivedConstants.c -o > includes/dist-derivedconstants/build/mkDerivedConstants.o > /bin/sh: : Permission denied > make[1]: *** > [includes/dist-derivedconstants/build/mkDerivedConstants.o] > Error 127 > make: *** [bootstrapping-files] Error 2 > > I don't know if it's a variable that's supposed to point to $CC that's > coming up "", or one that's supposed to point to ghc. I'm guessing the > latter. I can't proceed with the porting instructions at this point > because includes/dist-derivedconstants is empty (just an empty build > dir), and includes/dist-ghcconstants doesn't exist yet. > > > Any advice on how to proceed further using either of the strategies I > described (cross-compiling, or bootstrapping using using unregisterised > intermediate C files), would be welcomed. I got past that point by re-entering the failing command line by hand, and changing the leading "" to "gcc". I had to do that a couple of times (four). Then I can proceed to copy some include files to the host, run make on the host, make a tarball of various generated files. (One problem here: the instructions say to add compiler/main/Config.hs to the tarball, but that doesn't exist in this sourcetree. I'm guessing they meant compiler/stage2/build/Config.hs.) Then we untar that tarball back on the target machine, and proceed with the instructions. I come across a bunch more of the weird commands starting with "". A few of them have the form: "" configure ... At first I thought that was trying to be "sh configure ..." but the configure script complains that it doesn't recognize all the passed flags. Perhaps it should be not the configure script in the topmost directory, but one in a subdirectory? In any case, by running these commands: $ touch compiler/stage1/package-data.mk $ touch ghc/stage1/package-data.mk I can avoid those invocations. Not sure if there is something here I should be building but am missing. There are a lot more commands that make tries to run that start with "" and which seem to be trying to invoke gcc. (Plenty of times make *does* invoke "/usr/bin/gcc", as it ought to. But there are a bunch of times that it misses, and instead says "". Weird.) By correcting these all to "gcc", I'm able to get a lot further in the process. Here's where I'm stuck now. The instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting say to run these from the sourcetree on the target system: $ make all_ghc_stage2 2>&1 | tee c.log $ make inplace/bin/ghc-pkg 2>&1 | tee gp.log $ make inplace/lib/unlit NOTE: building inplace/bin/ghc-pkg currently fails. This has to be fixed. Here's how far I've gotten, with all my fiddling: $ make all_ghc_stage2 ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all_ghc_stage2 find: libraries/haskell98/dist-install/build: No such file or directory find: libraries/haskell98/dist-install/build: No such file or directory find: libraries/haskell2010/dist-install/build: No such file or directory find: libraries/haskell2010/dist-install/build: No such file or directory "cp" -p includes/dist-ghcconstants/build/tmp/mkGHCConstants inplace/bin/mkGHCConstants make[1]: *** No rule to make target `libraries/Cabal/Cabal/dist-install/build/Paths_Cabal.o', needed by `libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.14.0.a'. Stop. make: *** [all_ghc_stage2] Error 2 $ make inplace/bin/ghc-pkg ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final inplace/bin/ghc-pkg find: libraries/haskell98/dist-install/build: No such file or directory find: libraries/haskell98/dist-install/build: No such file or directory find: libraries/haskell2010/dist-install/build: No such file or directory find: libraries/haskell2010/dist-install/build: No such file or directory make[1]: *** No rule to make target `libraries/Cabal/Cabal/dist-install/build/Paths_Cabal.o', needed by `libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.14.0.a'. Stop. make: *** [inplace/bin/ghc-pkg] Error 2 $ make inplace/lib/unlit ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final inplace/lib/unlit find: libraries/haskell98/dist-install/build: No such file or directory find: libraries/haskell98/dist-install/build: No such file or directory find: libraries/haskell2010/dist-install/build: No such file or directory find: libraries/haskell2010/dist-install/build: No such file or directory "cp" -p utils/unlit/dist/build/tmp/unlit inplace/lib/unlit Looks like until I build Paths_Cabal.o (how?), I'm still not going to get a working stage2 ghc or a ghc-pkg. As before, any advice would be very welcome. -- dubiousjim(a)gmail.com

1 0

porting to uClibc-based 686 Linux
by Dubiousjim 01 Apr '13

01 Apr '13

My preferred system is a 686 Linux distro based on uClibc. No ghc binaries available yet there. I'd like to remedy that. I have ghc 7.4.2 running on an 686 Linux distro based on glibc (and also on two different versions of Mac OS X, but they seem more distant and so less likely to be helpful). In fact, ghc 7.6.2 binaries are also available for that system, but I'd like to keep in synch with the last released Haskell platform (which is what I've got on the Macs). That's supposed to be updated in May, so if it's only possible to port ghg >= 7.6.x to my target system, that won't be so terrible. I'm hoping though to be able to port a ghc < 7.8.x, because I don't expect to see that version in any soon-to-be-released Haskell platform. (I mention this because http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation says: "Support for cross-compilation works reasonably well in 7.8.1. Previous versions had various issues which are usually work-aroundable.") Ok, so I'm getting stuck trying to build a version of ghc that will run on the target, uClibc-based system. I have a working cross-compiler. (In fact, I have two, one built using crosstools-NG, the other built using buildroot.) My target identifier is "i686-buildroot-linux-uclibc". I've tried the method for cross-compiling ghc posted here: http://hackage.haskell.org/trac/ghc/wiki/Building/CrossCompiling I had to tweak the configure script to not complain about the "buildroot" vendor id. Here is the content of my mk/build.mk file: BuildFlavour = unreg ... ifeq "$(BuildFlavour)" "unreg" GhcUnregisterised = YES GhcWithNativeCodeGen = NO # SRC_HC_OPTS = -O -H64m # GhcStage1HcOpts = -O # GhcStage2HcOpts = -O2 # GhcLibHcOpts = -O2 SRC_HC_OPTS = -O -H64m -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 -fasm SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO endif Using the following commands: $ export PATH=${PATH}:/path/to/my/cross/compiler $ make clean $ ./configure --target=i686-buildroot-linux-uclibc $ make will successfully build ghc. However, the inplace/lib/ghc-stage2 it generates won't run on the target system. (Neither will the utils/ghc-pkg/dist/build/ghc-pkg, this will be relevant later.) Checking these with ldd says "not a dynamic executable." Checking them with objdump -p gives NEEDED lines like this: ... NEEDED libc.so.6 ... which indicates that they're linking against the glibc on my host, rather than the uClibc of my cross-compiler toolchain. Perhaps I'm doing something wrong, or perhaps the build system distributed with ghc 7.4.2 just doesn't yet properly support cross-compiling. It's strange though that the build completes without any errors. grepping the Makefiles doesn't show any evidence that it's using my cross-compiler. Do I need to make links using the target identifier "i386-unknown-linux-..." to my actual tools "i686-buildroot-linux-uclibc-..."? The web instructions say: If you need to specify the tools explicitly, then you can say $ ./configure --target=<target> --with-gcc=<gcc> \ --with-ld=<ld> --with-nm=<nm> --with-objdump=<objdump> However, if I specify my cross-compiler tools in this way, the build breaks already at the configure step, because the binaries generated won't run on the host. Alright, that isn't working. I also tried instead to use the older instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting This requires some tweaking, then at a certain point in this process I also get stuck. What I had to tweak: * The instructions say to copy an executable pwd to utils/ghc-pwd/ghc-pwd on the target, then run: $ perl boot $ ./configure --enable-hc-boot --build=<plat> \ --host=<plat> --target=<plat> However, the configure process still tries to build ghc-pwd and of course fails, since there's no ghc on the target to build it with. I comment out the line in the configure script which tries to build ghc-pwd and make sure that GHC_PWD points to my replacement pwd (which can't be at the location the configure script tries to make GHC_PWD point to, since that keeps getting clobbered). * Ok, so we get past the ghc-pwd issue and the configure continues. But then I get stuck with ghc-pkg: $ ./configure --enable-hc-boot --build=i386-unknown-linux \ --host=i386-unknown-linux --target=i386-unknown-linux ... checking for ghc... no checking build system type... i386-unknown-linux-gnu checking host system type... i386-unknown-linux-gnu checking target system type... i386-unknown-linux-gnu GHC build : i386-unknown-linux GHC host : i386-unknown-linux GHC target : i386-unknown-linux configure: Building in-tree ghc-pwd checking for path to top of build tree... /home/jim/ghc-7.4.2 checking for gcc... /usr/bin/gcc ... checking for i386-unknown-linux-gcc... /usr/bin/gcc checking whether the C compiler works... yes ... checking whether we are cross compiling... no ... checking version of gcc... 4.7.2 ... checking for ghc-pkg matching ... configure: error: Cannot find matching ghc-pkg Well of course there's no ghc-pkg, because I'm trying to port ghc to this system! I checked the ghc-pkg I (tried to) build with the cross-compiler toolchain, earlier, but this (contrary to my intention) links against the libc on its host, and so won't run on the target either. * Ok, so let's hack the configure script to skip building ghc-pkg too. Then configure completes successfully on the target. The next step is to: $ cd libraries/integer-gmp $ ./configure $ cd .. $ make bootstrapping-files However, this fails at the following point: "" -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -D__GLASGOW_HASKELL__=704 -Iincludes -DNO_REGS -DUSE_MINIINTERPRETER -Iincludes -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -DNOSMP -c includes/mkDerivedConstants.c -o includes/dist-derivedconstants/build/mkDerivedConstants.o /bin/sh: : Permission denied make[1]: *** [includes/dist-derivedconstants/build/mkDerivedConstants.o] Error 127 make: *** [bootstrapping-files] Error 2 I don't know if it's a variable that's supposed to point to $CC that's coming up "", or one that's supposed to point to ghc. I'm guessing the latter. I can't proceed with the porting instructions at this point because includes/dist-derivedconstants is empty (just an empty build dir), and includes/dist-ghcconstants doesn't exist yet. Any advice on how to proceed further using either of the strategies I described (cross-compiling, or bootstrapping using using unregisterised intermediate C files), would be welcomed. -- Dubiousjim dubiousjim(a)gmail.com -- dubiousjim(a)gmail.com

1 0