Re: porting to uClibc-based 686 Linux
Just to follow-up on my earlier emails about trying to port GHC to a uClibc-based Linux, I finally did get this working, on both x86 and x86_64. There were a bunch of small stumbling blocks and one big one that I finally traced to the fact that the native gcc on my target system had the Gentoo hardening patches, and one needed to supply a -nopie option to selectively disable these. (This was counter-intuitive because the error messages made it seem that what was wanted was to *enable* PIE compiling, not to disable it.) I finally identified this issue when reading http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml. Anyway, I've written up what it took to port GHC to our system on our distro's wiki: http://wiki.alpinelinux.org/wiki/Porting_GHC_to_Alpine Perhaps that might help others attempting similar feats, or might help the ghc devs working on the build system to make this less painful in the future. -- dubious...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: porting to uClibc-based 686 Linux
On Wed, Apr 17, 2013 at 11:18:52PM +0100, Ian Lynagh wrote: On Fri, Apr 05, 2013 at 11:12:38PM -0400, Dubiousjim wrote: target$ inplace/bin/ghc-stage2 -o hello-cross hello.hs [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello-cross ... target$ ./hello-cross Can't modify application's text section; use the GCC option -fPIE for position-independent executables. You can pass -fPIE to gcc by using the -optc-fPIE flag. Thanks Ian Thanks Ian. There's much I don't fully understand about ghc, but I read somewhere that the -optc-* options would only be applied when building via intermediate C files, which isn't happening in the compilation process specified above. Is this incorrect, or have I misunderstood something? In any event, adding -optc-fPIE doesn't remove the error message. That error message is kicked up by uclibc, on account of the hello-cross binary having a TEXTREL section, which I understand it shouldn't have if we're generating PIE or PIC code. The instruction to use the GCC option -fPIE is just uclibc's suggestion as to how to avoid this. I also tried adding -fPIE or -fPIC to the C compiler flags section in inplace/lib/settings, but this didn't resolve the issue. I also tried using BuildFlavour = unreg in mk/build.mk, but this didn't resolve the issue. What I thought to try next is to add llvm/clang to my cross-compiler toolchain, and try building with the -fllvm flag in SRC_HC_OPTS. Other suggestions will be much welcomed. Thanks. -- dubious...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: porting to uClibc-based 686 Linux
Am posting this follow-up to two mailing lists, because I've inquired
about it on both. Previous messages are at:
*
http://www.haskell.org/pipermail/glasgow-haskell-users/2013-April/023912.html
* http://lists.alpinelinux.org/alpine-devel/1699.html
I have seemed to successfully cross-compile a stage2 ghc for my target
system, an i686 Linux based on uClibc. One issue I don't think I've
mentioned before is that the target system uses a kernel with grsecurity
and PaX, and that involves patching the toolchain as well. However my
cross-compiling toolchain doesn't have any such tweaks applied. This
will be relevant below. Another potential issue is that my host system,
a different i686 Linux based on glibc, is running inside a chroot on my
target system. I don't think this is in fact responsible for any
problems, but I thought I should mention it.
So I last wrote on the glasgow-haskell mailing list:
On Wed, Apr 03, 2013 at 10:55:14AM -0400, Dubiousjim wrote:
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.
Krzysztof replied to me offline (thanks Krzysztof!), but I still haven't
managed to get this to work.
I started thinking the difficulty came from the grsecurity or PaX
features of my target system. Maybe the toolchain on the target system
had been configured in a way to build binaries that would work ok on
that system, but ghc wasn't yet so configured, and that's why the
binaries compiled by ghc don't work. I wrote to my target system's
mailing list (alpine-de...@lists.alpinelinux.org) expressing this fear.
There was also some evidence against this hypothesis. (Test binaries I
built using the cross-compiling toolchain, which hadn't been tweaked in
the way the toolchain on the target system had, did build binaries that
executed fine on the target; but perhaps this was just because the test
programs were too simple.) But since I didn't know what was going on,
this seemed worth exploring.
However, I'm pretty confident I've now ruled this explanation out. Even
if I build and boot from a vanilla kernel, binaries generated by the
ghc-stage2 in question still fail with the error message I reported.
So then I started trying to track down the error message in any sources
or binaries on my system. Couldn't find it kernel or ghc sources. I did
find it though in the source code for the uClibc library. It's from
lines 614-681 of the file uClibc-0.9.33.2/ldso/ldso/ldso.c:
- start ---
/* At this point we are now free to examine the user application,
* and figure out which libraries are supposed to be called. Until
* we have this list, we will not be completely ready for dynamic
* linking.
*/
/* Find the runtime load address of the main executable. This may
be
* different from what the ELF header says for ET_DYN/PIE
executables.
*/
{
unsigned int idx;
ElfW(Phdr) *phdr = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val;
for (idx = 0; idx auxvt[AT_PHNUM].a_un.a_val; idx++, phdr++)
if (phdr-p_type == PT_PHDR) {
DL_INIT_LOADADDR_PROG(app_tpnt-loadaddr,
auxvt[AT_PHDR].a_un.a_val - phdr-p_vaddr);
break;
}
if (DL_LOADADDR_BASE(app_tpnt-loadaddr))
_dl_debug_early(Position Independent Executable:
app_tpnt-loadaddr=%x\n,
DL_LOADADDR_BASE(app_tpnt-loadaddr));
}
/*
* This is used by gdb to locate the chain of shared libraries that
are
* currently loaded.
*/
debug_addr = _dl_zalloc(sizeof(struct r_debug));
ppnt = (ElfW(Phdr) *) auxvt[AT_PHDR].a_un.a_val;
for (i = 0; i auxvt[AT_PHNUM].a_un.a_val; i++, ppnt++) {
if (ppnt-p_type == PT_GNU_RELRO) {
relro_addr = ppnt-p_vaddr;
relro_size = ppnt-p_memsz;
}
if (!app_mapaddr (ppnt-p_type == PT_LOAD)) {
app_mapaddr = DL_RELOC_ADDR (app_tpnt-loadaddr,
ppnt-p_vaddr);
}
if (ppnt-p_type == PT_DYNAMIC) {
dpnt = (ElfW(Dyn) *) DL_RELOC_ADDR(app_tpnt-loadaddr,
ppnt-p_vaddr
Re: porting to uClibc-based 686 Linux
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
Re: porting to uClibc-based 686 Linux
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 -Bdir 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 -xmaddr -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. -- dubious...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: porting to uClibc-based 686 Linux
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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
porting to uClibc-based 686 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 dubious...@gmail.com -- dubious...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: porting to uClibc-based 686 Linux
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 21 | tee c.log $ make inplace/bin/ghc-pkg 21 | 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
