Re: Preparing a Registered hc-file-bundle (Was Bootstrapping with HC files)
Well, I gave it a blast anyway. All went well creating the hc files until the last command: > $ make hc-file-bundle Project=Ghc at which point it failed with tar czf ghc-6.4.1-x86_64-unknown-linux-hc.tar.gz `cat hc-files-to-go` tar: ghc-6.4.1/ghc/rts/AutoApply_thr.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/AutoApply_thr_p.hc: Cannot stat: No such file or directory tar: ghc-6.4.1/ghc/rts/AutoApply_debug.hc: Cannot stat: No such file or directory tar: Error exit delayed from previous errors make: *** [hc-file-bundle] Error 2 Googling suggests this might be harmless, so I tried bootstrapping on the target machine using the created tarball, but that failed with /bin/ld: cannot find -lghccompat collect2: ld returned 1 exit status make[1]: *** [stage1/ghc-6.4.1] Error 1 make: *** [all] Error 1 make: Leaving directory `/home/andrew/test/ghc/bs/target/ghc-6.4.1/ghc' Any pointers gladly accepted! Andrew Walrond ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC wish list.
Hi Lemmih, Might be a good idea to add these as feature requests: http://hackage.haskell.org/trac/ghc/newticket?type=feature+request Cheers, Simon On 13 December 2005 15:17, Lemmih wrote: > I've been using the GHC library in hIDE and HASP for some time now and > there are a few things I'd love to see implemented: > > * Changeable lexer/parser (just like DynFlags.log_action) > Not very important but it would be convenient in HASP. > * Cabalization of the library. > Not having a profiling version of the library and not being able to > rebuild it easily is a bit limiting. > * GHCi compatibility. > hIDE is currently using ghc-api[1] because the real library exports > symbols that clashes with GHCi. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC wish list.
Hiya, I've been using the GHC library in hIDE and HASP for some time now and there are a few things I'd love to see implemented: * Changeable lexer/parser (just like DynFlags.log_action) Not very important but it would be convenient in HASP. * Cabalization of the library. Not having a profiling version of the library and not being able to rebuild it easily is a bit limiting. * GHCi compatibility. hIDE is currently using ghc-api[1] because the real library exports symbols that clashes with GHCi. -- Friendly, Lemmih [1] ghc-api: http://scannedinavian.com/~lemmih/ghc-api ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Preparing a Registered hc-file-bundle (Was Bootstrapping with HC files)
Ok, so now we know its possible! Now the question is how to create and use a _registered_ hc file bundle. The Build manual describes the process of cross compiling an _unregistered_ hc file bundle, but has nothing to say about creating the simpler registered hc file bundle for the purpose of bootstrapping GHC on an equivalent supported platform but without a preinstalled ghc. So, reading between the lines a little, here is what I propose trying. Please take a look, and give me your thoughts if you think I am on the wrong track! HOST: Has ghc, happy, alex installed. TARGET: Same as host, but without ghc, happy alex. On the HOST - Unpack src tree, and cd into it. Configure with necessary options $ ./configure --prefix=... Section 10.2.1'Cross-compiling to produce an unregisterised GHC' in the build manual suggests creating an mk/build.mk with following contents: GhcUnregisterised = YES GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcLibWays = SplitObjs = NO GhcWithNativeCodeGen = NO GhcWithInterpreter = NO GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fvia-C -keep-hc-files SRC_HC_OPTS += -H32m GhcBootLibs = YES Reading between the lines somewhat, for a full registered version we might need something like GhcUnregisterised = NO GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcLibWays = SplitObjs = NO GhcWithNativeCodeGen = YES GhcWithInterpreter = YES GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fvia-C -keep-hc-files SRC_HC_OPTS += -H32m GhcBootLibs = YES Advice on this bit gratefully received! The manual next suggests copying some target generated include files into the host ghc source, but since they are the same I guess we can ignore that bit. Now building exactly as described in the manual: $ pushd glafp-utils && make boot && make && popd $ pushd ghc && make boot && make && popd Manual suggests the build might fail in RTS, but probably not for our registered version ? $ pushd libraries && make boot && make && popd $ pushd ghc/compiler && make boot stage=2 && make stage=2 && popd $ pushd ghc/lib/compat $ make clean $ rm .depend $ make boot UseStage1=YES $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ popd $ pushd ghc/utils $ make clean $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ popd $ make hc-file-bundle Project=Ghc That should provide us with our hc-file-bundle, *-hc.tar.gz On the TARGET Unpack src tree, unpack the hc file bundle on top of it. Cd into the src tree. Now it should be a simple matter of $ distrib/hc-build --prefix=dir $ make install Any comments/suggestions before I give it a try? Thanks for all help so far, and in anticipation of more! Andrew Walrond ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Bootstrapping with HC files
On 12 December 2005 18:21, Andrew Walrond wrote: > 3) Why don't you guys supply hc tarballs for bootstrapping on common > platforms? They would seem to be rather more versatile than the usual > rpms and binary tarballs. A couple of reasons, neither of which is very convincing: 1. the HC files are sensitive to platform differences, so I'm not sure that HC files generated for one flavour of Linux would necessarily work on other flavours, for example. 2. building from HC files isn't well supported, and tends to be rather fragile, so we don't like to encourage it. The reason it isn't well supported is just lack of time. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Bootstrapping with HC files
On 12 December 2005 22:47, Donald Bruce Stewart wrote: > andrew: >> I run a source based linux distro called Heretix, and I want to make >> a ghc package which will install with or without an existing ghc. At >> the moment, we supply a binary-ghc package, whch is a prerequisite >> of the from-source ghc package. >> >> It seems to me that I can prepare HC tarballs for my target >> platforms (x86, x86_64) which will remove the need for the >> ghc-binary package. My questions: >> >> 1) Can I produce 'registered' hc files? The build manual bangs on >> about cross compiling unregistered hc files, which isn't really what >> I need. >> >> 2) Would a ghc built from registered hgc files every bit as good and >> complete as a normally bootstrapped ghc? > > Yes, the OpenBSD versions of GHC build from registerised .hc tar > balls. It's fast. > > If you're interested in this path, check out: > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That port is for 6.2.2 - do you have a 6.4.1 port too? Many thanks for keeping the .hc bootstrapping route working, BTW. It's a great help. Cheers, SImon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping with HC files
Donald Bruce Stewart wrote: Most distros are using binary bootstrapping. I think OpenBSD is the only one building from .hc src. And NetBSD. -- Lennart ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
