big hello world binary on 32bit intel MacOS
Hi, compiling a simple putStrLn Hello program creates binaries of size: ghc-6.12.3: 719K ghc-7.0.1: 7,4M ghc-7.0.2: 6,9M otool -L for the ghc-7 binaries displays: /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) where /usr/lib/libgcc_s.1.dylib is not referenced for the ghc-6.12.3 binary. I used: http://www.haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-apple-darwin.tar.bz2 http://www.haskell.org/ghc/dist/6.12.3/GHC-6.12.3-i386.pkg Any explanations? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
no testsuite? Re: ANNOUNCE: GHC version 7.0.2
I still cannot make sense out of this testsuite-7.0.2.tar.bz2 C. Am 04.03.2011 15:14, schrieb Christian Maeder: http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 This archive does not seem to have the actual tests inside the testsuite subdirectory. At least the README is identical to the top-level one. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: big hello world binary on 32bit intel MacOS
I've created a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/5008 C. Am 09.03.2011 14:06, schrieb Christian Maeder: Hi, compiling a simple putStrLn Hello program creates binaries of size: ghc-6.12.3: 719K ghc-7.0.1: 7,4M ghc-7.0.2: 6,9M otool -L for the ghc-7 binaries displays: /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) where /usr/lib/libgcc_s.1.dylib is not referenced for the ghc-6.12.3 binary. I used: http://www.haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-apple-darwin.tar.bz2 http://www.haskell.org/ghc/dist/6.12.3/GHC-6.12.3-i386.pkg Any explanations? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Exclusively For You
This is a good offer http://www.gogoamerica.com/info.html It's cool! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build error: cannot satisfy -package ghc-7.1.20110217
Hi Simon, thanks for the reply. Indeed it is reproducible with a maintainer-clean tree and to be sure I even set up a fresh repo. I'm still unclear what the underlying issue is, but I've worked around it by first running `make` until the error, then editing ./ghc/stage1/package-data.mk to remove the version from the ghc dep, and finally rerunning `make`. The resulting build performs comparably in the test suite to previous builds, so I think it's probably an okay workaround. Will On Tue, Mar 8, 2011 at 6:44 AM, Simon Marlow marlo...@gmail.com wrote: On 04/03/11 11:49, William Knop wrote: Hi all, Not to pester, but this problem has me stumped. All of the dependencies that ghc reports are broken/recursive are reported (with identical versions) by ghc-pkg/cabal as being part of my bootstrap install. Rerunning the offending command with -package ghc instead of -package ghc-7.1.20110217 suppresses the error, but `make` nonetheless insists on rerunning the command with the original arguments. Furthermore, I'm unsure if I'm actually working around a bug or if I'm instead just silencing an error that will slyly retaliate from the shadows. It certainly seems like there's a subtlety with cabal that I don't understand. Any help would be much appreciated. I don't know what might case this I'm afraid. Is it reproducible from a completely clean tree? (i.e. make maintainer-clean first). Cheers, Simon Will On Sun, Feb 27, 2011 at 11:26 PM, William Knop william.knop.nos...@gmail.com wrote: I'm not sure what happened with the quote formatting in my original message; sorry about that. Anyhow, I'd really appreciate it if someone would chime in about this issue. Is it something silly that I'm not comprehending about the build system or cabal, or is it a legitimate bug/deficiency? Thanks, Will On Thu, Feb 24, 2011 at 7:24 PM, William Knop william.knop.nos...@gmail.com wrote: Hi all, I'm building GHC HEAD, and I've encountered the following error a couple times: /usr/bin/ghc -M -dep-makefile ghc/stage1/build/.depend.haskell.tmp -include-pkg-deps -H32m -O -package-conf libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include -optPghc/stage1/build/autogen/cabal_macros.h -package array-0.3.0.2 -package base-4.3.1.0 -package bytestring-0.9.1.10 -package directory-1.1.0.0 -package filepath-1.2.0.0 -package ghc-7.1.20110217 -package process-1.0.1.4 -package unix-2.4.1.0 -Wall -XHaskell98 -XNondecreasingIndentation -XCPP -XPatternGuards -no-user-package-conf -rtsopts -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc ghc/./Main.hs command line: cannot satisfy -package ghc-7.1.20110217: ghc-7.1.20110217-b77087559342dd20dfcfb258ea8804c4 is unusable due to missing or recursive dependencies: Cabal-1.11.0-94afda515f19c403e7bc1e64b05e7f80 bin-package-db-0.0.0.0-e7fefdd6f3601d1ce130006fe020c686 hoopl-3.8.6.1-9f2c1afa2d4e6e1f5dd2821dfd6b919b hpc-0.5.0.6-71c33aa47ae2440fd78a2a606987bc82 (use -v for more information) make[1]: *** [ghc/stage1/build/.depend.haskell] Error 1 make: *** [all] Error 2 The last time I saw this, I realized that `make clean` and even `make maintainer-clean` failed to remove the old .hs and .o files in ./libraries. I ran `find ./libraries | grep \.hi$\|\.o$ | xargs -n 1 rm` which cleaned things up nicely. Then I had to fiddle around with `ghc-pkg` and unfortunately I don't remember exactly what I did, but everything built fine. This time, the error persists and I'm getting nowhere messing with `ghc-pkg` or manual builds of the offending libraries. It's odd that the dependencies are all shown, although ghc-7.1.20110217 is highlighted in blue (not sure what that means): $ ghc-pkg list -v using cache: /Users/wknop/.ghc/x86_64-darwin-7.1.20110217/package.conf.d/package.cache using cache: /Library/Frameworks/GHC.framework/Versions/7.1.20110217-x86_64/usr/lib/ghc-7.1.20110217/package.conf.d/package.cache /Library/Frameworks/GHC.framework/Versions/7.1.20110217-x86_64/usr/lib/ghc-7.1.20110217/package.conf.d Cabal-1.11.0 (Cabal-1.11.0-94afda515f19c403e7bc1e64b05e7f80) array-0.3.0.2 (array-0.3.0.2-82b79889a63c9f1c51bec752ba6e74c2) base-4.3.1.0 (base-4.3.1.0-772e705367f0e57fa35bb2732ef27d5f) bin-package-db-0.0.0.0 (bin-package-db-0.0.0.0-e7fefdd6f3601d1ce130006fe020c686) binary-0.5.0.2 (binary-0.5.0.2-0fc98c736c6f368bb204d82d52e9b985) bytestring-0.9.1.10 (bytestring-0.9.1.10-9ed25604136f5805a5307d3964bed1a2) containers-0.4.0.0 (containers-0.4.0.0-e65ebc811ae84f909e4426649d5305b6) directory-1.1.0.0 (directory-1.1.0.0-af496658c243f2bddd90748bc896b9cb) extensible-exceptions-0.1.1.2 (extensible-exceptions-0.1.1.2-d8c5b906654260efd7249f497d17a831) ffi-1.0 (builtin_ffi) filepath-1.2.0.0
Re: hoogling GHC
Hi Ranjit, It sounds like you've got quite far. Sadly the manual is a bit out of date with respect to generating databases, but generally you need to produce ghc.txt on your own (using tools such as GHC's make system), then you can do: hoogle convert ghc.txt default.hoo Then you can run the local server with: hoogle server --databases=. That will find databases from the current directory, and serve them. Alternatively, if you put ghc.hoo (or default.hoo) in $DATADIR/databases it will pick them up automatically (where $DATADIR is whatever Cabal configured it to be). If you name the database as default.hoo it will be searched by default, if you name it ghc.hoo then foo +ghc will search for foo in the GHC database. If a copy of ghc.txt was publicly available somewhere (and updated on some schedule), I'd be happy to make the official Hoogle server search it. Usually I just grab databases off Hackage, but I'll happily make an exception for GHC. Thanks, Neil On Sun, Mar 6, 2011 at 7:52 AM, Malcolm Wallace malcolm.wall...@me.com wrote: The final stumbling block is getting the local webserver (hoogle server) to also search the above database. I'm sure there must be some simple way I can pass the name of the database as an argument when I boot up the server, but I can't seem to find it... Have you found the various versions of the web deployment procedure yet? deploy.txt: instructions to follow manually (seems to be up-to-date) deploy.sh: a shell script version to run locally (may be old) Deploy.hs: a haskell version to run remotely (may also be old) Obviously those scripts are tailored to the official installation, but there are some clues in there, for instance the steps cabal configure --datadir=/srv/web/haskell.org/hoogle/ --datasubdir=datadir -O2 and Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/resources Upload datadir/databases/* to /srv/web/haskell.org/hoogle/datadir/databases Regards, Malcolm ___ 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: hoogling GHC
Hi Neil -- thanks, this is perfect!! Ranjit. On Mar 9, 2011, at 1:59 PM, Neil Mitchell wrote: Hi Ranjit, It sounds like you've got quite far. Sadly the manual is a bit out of date with respect to generating databases, but generally you need to produce ghc.txt on your own (using tools such as GHC's make system), then you can do: hoogle convert ghc.txt default.hoo Then you can run the local server with: hoogle server --databases=. That will find databases from the current directory, and serve them. Alternatively, if you put ghc.hoo (or default.hoo) in $DATADIR/databases it will pick them up automatically (where $DATADIR is whatever Cabal configured it to be). If you name the database as default.hoo it will be searched by default, if you name it ghc.hoo then foo +ghc will search for foo in the GHC database. If a copy of ghc.txt was publicly available somewhere (and updated on some schedule), I'd be happy to make the official Hoogle server search it. Usually I just grab databases off Hackage, but I'll happily make an exception for GHC. Thanks, Neil On Sun, Mar 6, 2011 at 7:52 AM, Malcolm Wallace malcolm.wall...@me.com wrote: The final stumbling block is getting the local webserver (hoogle server) to also search the above database. I'm sure there must be some simple way I can pass the name of the database as an argument when I boot up the server, but I can't seem to find it... Have you found the various versions of the web deployment procedure yet? deploy.txt: instructions to follow manually (seems to be up-to-date) deploy.sh: a shell script version to run locally (may be old) Deploy.hs: a haskell version to run remotely (may also be old) Obviously those scripts are tailored to the official installation, but there are some clues in there, for instance the steps cabal configure --datadir=/srv/web/haskell.org/hoogle/ --datasubdir=datadir -O2 and Upload datadir/resources to /srv/web/haskell.org/hoogle/datadir/resources Upload datadir/databases/* to /srv/web/haskell.org/hoogle/datadir/databases Regards, Malcolm ___ 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
Exclusively For You
This offer is really nice, isn't it? http://www.network4dummies.com/info.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build error: cannot satisfy -package ghc-7.1.20110217
I saw this same error, building GHC 7.0.2 from source on OS X. My builds are completely scripted, so I could attempt any experiments that would help. I always expect issues with major (here, 6 = 7) version changes; here all issues surrounded cabal-install in one way or another. My issues went away when I compiled GHC 7.0.2 using a bootstrap copy of GHC 7.0.2 (rather than from GHC 6.12.3). made the new install the active GHC, and then ran ./bootstrap.sh --global to install cabal-install-0.10.2. Either the change from cabal-install-0.10.0 helped (I couldn't track down release notes) or there is a subtle difference in a GHC 7.0.2 compiled from GHC 6.12.3, that gets exposed when one tries to install cabal-install. I still can't use cabal-install on one copy of 7.0.2 to install to another copy of 7.0.2, but it looks like something I'll manage to sort out without help. I use PREFIX to localize the installation to e.g. /usr/local/ghc-7.0.2c. This requires that my script edits bootstrap.sh, as there's no way to change PREFIX from outside in --global mode. On Mar 8, 2011, at 9:44 AM, Simon Marlow wrote: I don't know what might case this I'm afraid. Is it reproducible from a completely clean tree? (i.e. make maintainer-clean first). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC build error: cannot satisfy -package ghc-7.1.20110217
On Mar 9, 2011, at 9:44 PM, Dave Bayer wrote: I still can't use cabal-install on one copy of 7.0.2 to install to another copy of 7.0.2, but it looks like something I'll manage to sort out without help. cabal install cabal-install tries to install 0.8.2, and fails. cabal install cabal-install-0.10.2 works. Yes I ran cabal-update first. I have no idea where it gets the idea it should install 0.8.2 when newer versions are evident, particularly when this doesn't even work. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
