- Glasgow-haskell-users

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

ghc and aarch64?
by Jens Petersen 26 Mar '13

26 Mar '13

I am curious if anyone has started or is planning to work on porting GHC to the new ARM 64bit architecture AArch64 for Linux? Jens

3 3

Re: Libffi errors while cross-compiling GHC 7.6.2 (Stage 1)
by Nikita Karetnikov 24 Mar '13

24 Mar '13

> Is /usr/bin/gcc a MIPS cross-compiler? If not, how do you expect it > to work? Right, I wasn't using a cross-compiler. That's the problem. I haven't succeeded in cross-building yet. I'm using a distro with a non-common directory structure and I still have to figure out how to specify both GCCs. But it has nothing to do with the ticket. So I've just closed it. I apologize for the noise.

1 0

Compiled code
by migmit 23 Mar '13

23 Mar '13

Suppose I compiled some module and kept it's .hi and .o files. Is it possible to use this module in my program if the source code was deleted for some reason? Seems like the answer is "yes" — by creating a fake .hs file (with no real content) and touch-in .hi and .o files I tricked ghc so that it didn't attempt to recompile the module, so the information in .hi and .o files is sufficient. But ghc insists on having the .hs file around, and I didn't find a way to turn it off. Is there any? Or there is a specific reason not to have it?

1 0

Release plans
by Ian Lynagh 21 Mar '13

21 Mar '13

Hi all, Thank you to everyone who gave us feedback on when we should release 7.8.1, and on future release plans in general. We've looked at all the responses, and we think that the best plan is to continue to make major releases annually, with minor "patch-level" releases between them. Additionally, we may recommend particular snapshots, and provide binary builds for all tier-1 platforms, for people who wish to test new features etc in HEAD. There is more detail on how all this will work here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Releases We will therefore aim for a 7.8.1 release in October. We do not currently expect to make a 7.6.3 release, although that may change if serious bugs in 7.6.2 are discovered. Would a 7.7.x recommended snapshot be useful to you? Tell us if you want one. Compared to 7.6 it would contain: * polykinded Typeable library * major improvements in DPH (vectorisation avoidance, new vectoriser) * type holes * rebindable list syntax * major changes to the type inference engine * type level natural numbers * overlapping type families * the new code generator * support for vector (SSE/AVX) instructions * Scheduler changes to the RTS to improve latency Is it worth us putting out a preview, or are you happy to work from the nightly snapshots and wait for the full release in October? Thanks Ian

8 10

Polymorphic implicit parameters
by Roman Cheplyaka 21 Mar '13

21 Mar '13

I'm curious as to why GHC doesn't accept the following (contrived) module: {-# LANGUAGE ImplicitParams, RankNTypes #-} f :: (?g :: (forall a . a -> a)) => a -> a f = ?g The error message is: Illegal polymorphic or qualified type: forall a. a -> a In the type signature for `f': f :: ?g :: (forall a. a -> a) => a -> a It's not a big deal since one can wrap the polymorphism in a newtype, but it's somewhat unexpected. Roman

2 2

ANNOUNCE: GHC 7.6.2 Release Candidate 1
by Ian Lynagh 21 Mar '13

21 Mar '13

We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

8 12

Does GHC 7.8 make targeting bare metal ARM any easier?
by Jeremy Shaw 20 Mar '13

20 Mar '13

There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy

3 2

scope invariants in core
by Ranjit Jhala 18 Mar '13

18 Mar '13

Hi all, I have been manipulating CoreExpr to convert it to A-Normal Form. Mostly, things have been working fine, but I hit an error this morning of the form: lq_anf__d11u is out of scope where lq_anf__d11u is a binder I have introduced in the transformed expression Data.ByteString.Internal.c_strlen = (\ (ds_d11l :: GHC.Ptr.Ptr Foreign.C.Types.CChar) -> case ds_d11l of lq_anf__d11t { GHC.Ptr.Ptr ds_d11n -> let { lq_anf__d11x :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Word.Word32 #) [LclId] lq_anf__d11x = \ (ds_d11q :: GHC.Prim.State# GHC.Prim.RealWorld) -> case {__pkg_ccall main strlen GHC.Prim.Addr# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Word# #)} ds_d11n ds_d11q of lq_anf__d11u { __DEFAULT -> case lq_anf__d11u of lq_anf__d11v { (# ds_d11p, ds_d11o #) -> let { lq_anf__d11w :: GHC.Word.Word32 [LclId] lq_anf__d11w = GHC.Word.W32# ds_d11o } in (# ds_d11p, lq_anf__d11w #) } } } in GHC.Types.IO @ GHC.Word.Word32 lq_anf__d11x }) It would appear, that the variable IS in scope (as it is bound by the case-expression just before it is used, but perhaps the binder is not added to the environment because of its type (# ... , ... #)? Or is there some other invariant I am breaking? Can anyone familiar with the scoping invariants of CoreExpr/CoreSyn give me a hint as to what might be happening? Many thanks in advance! Ranjit.

2 3

Annotating an AST with type checking / source line number info
by Craig Innes 14 Mar '13

14 Mar '13

Hi there, I am not hugely familiar with compilers or the particulars of GHC, but am interested in creating a few programs which manipulate Haskell source code in particular ways. Two things I would like to be able to do are: - Swap every occurrence of a particular type for a different / dummy value of that type. - Find the line / column number of every place a value of a particular type is used >From compiling Haskell programs, it seems clear that GHC performs type checking, and when I get a compile error it is able extract line and column information about where I had the error, so it appears as if GHC is annotating the source with this information as it compiles. I am struggling to find a lot in the way of learning materials for GHC, but from trawling through the API documentation (I am using GHC version 7.4.2), it seems like I can generate an abstract syntax tree via the method: parseModule :: GhcMonad<http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:GhcMon…>m => ModSummary<http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:ModSum…>-> m ParsedModule<http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:Parsed…> My question is this: what combination of functions do I have to use to get not only an AST for my source, but an AST annotated with typing information and line / column number annotations for values within it? Also, as I am a bit of a newbie to this whole GHC API thing, any pointers to resources to learn more about it would be enormously appreciated. Thanks, Craig

3 2