Re: ghci finding include files exported from other packages?
Duncan Coutts wrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: This sounds like a chicken and egg problem. To know which package include directories to use GHCi needs to know which packages your module uses. However to work out which packages it needs it has to load the module which means pre-processing it! With cabal we get round this problem because Cabal calls ghc with -package this -package that etc and so when ghc cpp's the module it does know which package include directories to look in. Perhaps I'm missing something, but if applicative-numbers is an exposed package, shouldn't we be adding its include-dirs when invoking CPP? Yes, if we know we're using it. If we specify -package blah on the command line then we do know we're using it and everything works (because ghc uses the include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle. I don't see a reason why we shouldn't pass *all* the include paths for the exposed packages to CPP. Indeed that's what I thought we did, but I've just checked and I see we don't. Wouldn't that fix Conal's problem? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci finding include files exported from other packages?
On Tue, 2009-03-17 at 08:53 +, Simon Marlow wrote: Duncan Coutts wrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: Yes, if we know we're using it. If we specify -package blah on the command line then we do know we're using it and everything works (because ghc uses the include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle. I don't see a reason why we shouldn't pass *all* the include paths for the exposed packages to CPP. Indeed that's what I thought we did, but I've just checked and I see we don't. Wouldn't that fix Conal's problem? Yes it probably would. On my system that'd only be between 25-50 include directories, which I guess is not too bad. Lets hope not too many packages decide they need a config.h file. So, presumably by passing all include dirs for all exposed packages that takes into account -package flags, so when Cabal does -hide-all-packages then it gets its desired behaviour. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Under Solaris: GHC 6.10.2 Release Candidate 1
GHC 6.10.2 will have a problem with cabal-install-0.6.2!
When I tried to install cabal-install-0.6.2 for ghc-6.10.1.20090314
I needed to change #!/bin/sh to #!/bin/bash in bootstrap.sh to avoid the
following errors:
-bash-3.00$ ./bootstrap.sh
Checking installed packages for ghc-6.10.1.20090314...
./bootstrap.sh: !: not found
parsec is already installed and the version is ok.
./bootstrap.sh: !: not found
network is already installed and the version is ok.
./bootstrap.sh: !: not found
Cabal is already installed and the version is ok.
./bootstrap.sh: !: not found
HTTP is already installed and the version is ok.
./bootstrap.sh: !: not found
zlib is already installed and the version is ok.
./bootstrap.sh: !: not found
./bootstrap.sh: !: not found
./bootstrap.sh: !: not found
Under Solaris sh is not bash!
Next, ghc-6.10.1.20090314 comes with package unix-2.4.0.0, but
cabal-install.cabal requests:
unix = 2.0 2.4
Changing to = 2.4 was not sufficient, so I changed it to = 2.5.
This will affect any OS!
Testsuite results are bad for ghc-6.10.1.20090314, see
http://hackage.haskell.org/trac/ghc/ticket/3106
Cheers Christian
Christian Maeder wrote:
Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 6.10.2:
http://www.haskell.org/ghc/dist/6.10.2-rc1/
Under Solaris grep does not understand -q in configure:
checkMake380() {
if $1 --version 21 | head -1 | grep -q 'GNU Make 3\.80'
it fails with:
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
grep: illegal option -- q
Usage: grep -hblcnsviw pattern file . . .
C.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Developer Wiki Buildbots
Dear all, It seems that the front page of the developer wiki is rather out-of-date. Considering that 6.10.2 is now at rc1-stage, I was rather hoping to find some updated notes on release plans for 6.10.2 and what will be in 6.12, but those notices are still at 6.8.3 and 6.10, resp. On another matter: I've been trying to contact Ian on rejoining the buildbot network, but haven't heard from him in response to any of messages. Ian, I figured I may have - somehow - ended up in your spam-box, so I thought it a good idea to go through the mailing list. Could you maybe check your spam-box for my e-mails? Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under Solaris: GHC 6.10.2 Release Candidate 1
Christian Maeder wrote: Testsuite results are bad for ghc-6.10.1.20090314, see http://hackage.haskell.org/trac/ghc/ticket/3106 Patch for the cygpath not found issue is attached to the ticket. Please (Windows/Cygwin/Mingw users especially) test it. Thanks, Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Developer Wiki Buildbots
Philip K.F. Hölzenspies wrote: It seems that the front page of the developer wiki is rather out-of-date. Considering that 6.10.2 is now at rc1-stage, I was rather hoping to find some updated notes on release plans for 6.10.2 and what will be in 6.12, but those notices are still at 6.8.3 and 6.10, resp. Good point, I've just updated it. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: testing 6.10.2-candidate
Serge D. Mechveliani wrote: I have tested ghc-6.10.1.20090314 on Debian Linux, i386-unknown, on making from source by ghc-6.10.1, making itself from source, DoCon. It looks all right. Thanks Serge! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Solaris 8 and libm.so.2
Hi everyone. I'm trying to build GHC 6.8.3 on a Solaris 8 machine. I'd love to upgrade Solaris to 10, which I believe would solve the problem I'm having by making /usr/lib/libm.so.2 available, but that's not an option at this time. Here's the output of uname -a on the system. SunOS bwddev1 5.8 Generic_117350-53 sun4u sparc SUNW,Ultra-80 The GCC I'm using is gcc Target: sparc-sun-solaris2.8 Configured with: /usr/local/src/gnu/gcc-4.0.1/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --prefix=/usr/local/gcc4 Thread model: posix gcc version 4.0.1 The GHC binary I'm bootstrapping with is 6.4.1. It works fine for compiling complex haskell programs and packages. I've already worked through a couple of problems to get to where I'm at now. What I had to do was... changed #define SIZET_FMT d to #define SIZET_FMT d in includes/mkDerivedConstances.c. change #include stdint.h to #include inttypes.h in includes/HsFFI.h added mk/build.mk containing SRC_HC_OPTS=-opta-mcpu=v9 My latest attempt at a build involved the following, where BOS_ROOT points at the root of my build tree, and $BOS_ROOT/gcc4 is where my gcc lives, and $BOS_ROOT/ghc is where the ghc binary lives. This is only the latest attempt. The libm.so.2 symbolic link and the LDFLAGS and LD_LIBRARY_PATH values were added on the most recent attempt. ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 PATH=$BOS_ROOT/gcc4/bin:$BOS_ROOT/ghc/bin:$BOS_ROOT/bin:/usr/bin:/bin LD_LIBRARY_PATH=$BOS_ROOT/gcc4/lib:$BOS_ROOT/ghc/lib:$BOS_ROOT/lib:/usr/lib LDFLAGS=-static -L$BOS_ROOT/lib CFLAGS= export PATH LD_LIBRARY_PATH LDFLAGS CFLAGS fp_prog_ld_raw=/usr/ccs/bin/ld ./configure \ --prefix=$BOS_ROOT \ --with-ghc=$BOS_ROOT/ghc/bin/ghc \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --with-gcc=$BOS_ROOT/gcc4/bin/gcc \ --with-gmp-includes=$BOS_ROOT/include \ --with-gmp-libraries=$BOS_ROOT/lib \ --with-readline-includes=$BOS_ROOT/include \ --with-readline-libraries=$BOS_ROOT/lib Once I made these changes, the build goes on for a number of hours then dies with what's listed below. I understand that this is because the build is looking for libm.so.2, while the lib on Solaris 8 is /usr/lib/libm.so.1. No matter what I do - including the kludge above attempting to create a libm.so.2 symbolic link, I can't get rid of the errors. Any help at all would be very much appreciated. Please. Here's the error listing. make[3]: Entering directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' ../compiler/stage1/ghc-inplace -no-user-package-conf -opta-mcpu=v9 -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp-c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi ghc: 450131408 bytes, 1127 GCs, 6839050/13262620 avg/max bytes residency (8 samples), 35M in use, 0.00 INIT (0.01 elapsed), 13.34 MUT (40.52 elapsed), 8.42 GC (8.81 elapsed) :ghc ../compiler/stage1/ghc-inplace -no-user-package-conf -o stage2/ghc-6.8.3 -opta-mcpu=v9 -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recompstage2/main/Main.o Undefined first referenced symbol in file cosf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__169.o) expf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__173.o) logf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__172.o) powf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__161.o) sinf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__170.o) tanf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__168.o) acosf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__166.o) asinf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__167.o) atanf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__165.o) coshf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__163.o) dlsym /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) sinhf
Re: Solaris 8 and libm.so.2
Ralph Crawford wrote: ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 You need an actual libm.so.2 library that contains the missing symbols. To this library you set a link libm.so in a directory that is in the front of your LD_LIBRARY_PATH, so that libm.so.2 instead of libm.so.1 is found via libm.so. HTH Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Solaris 8 and libm.so.2
On 2009 Mar 17, at 10:36, Christian Maeder wrote: Ralph Crawford wrote: ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 You need an actual libm.so.2 library that contains the missing symbols. To this library you set a link libm.so in a directory that is in the front of your LD_LIBRARY_PATH, so that libm.so.2 instead of libm.so. 1 is found via libm.so. It's a bit more complex than that: if you have the appropriate service contract you can request the C9X patch cluster, otherwise you can't get libm.so.2 at all, as far as I can determine. I came up with an ugly hack to work around it, but would prefer to find a better solution. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Bootstrapping the compiler
I have just downloaded a darcs snapshot, pulled patches and followed the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart When I got to do make it didn't work. The tail of the output looks like this: [55 of 55] Compiling Main ( cabal-bin.hs, /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking cabal-bin ... echo [] bootstrapping.conf.tmp cd extensible-exceptions /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean --distpref=dist-bootstrapping unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: [bootstrapping.conf] Error 1 (ignored) cd extensible-exceptions /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 configure --distpref=dist-bootstrapping --with-compiler=ghc --make -fno-warn-unrecognised-pragmas --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/home/colin/ghc/libraries' make: *** [stage1] Error 2 I then tried the following: [co...@susannah ghc]$ ls libraries/bootstrapping.conf ls: cannot access libraries/bootstrapping.conf: No such file or directory [co...@susannah ghc]$ ls libraries/bootstrapping.conf.tmp libraries/bootstrapping.conf.tmp It looks to me like all I have to do is to rename libraries/bootstrapping.conf.tmp to libraries/bootstrapping.conf but I don't see why this is happening. -- Colin Adams Preston Lancashire ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under Solaris: GHC 6.10.2 Release Candidate 1
On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote: GHC 6.10.2 will have a problem with cabal-install-0.6.2! When I tried to install cabal-install-0.6.2 for ghc-6.10.1.20090314 I needed to change #!/bin/sh to #!/bin/bash in bootstrap.sh to avoid the following errors: -bash-3.00$ ./bootstrap.sh Checking installed packages for ghc-6.10.1.20090314... ./bootstrap.sh: !: not found Under Solaris sh is not bash! Indeed. According to the OpenGroup that syntax should be fine: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02 It works for me under Solaris 10. Perhaps Solaris 9 or older do not have a standard compliant /bin/sh program. What do you suggest we use instead as a workaround? Next, ghc-6.10.1.20090314 comes with package unix-2.4.0.0, but cabal-install.cabal requests: unix = 2.0 2.4 Changing to = 2.4 was not sufficient, so I changed it to = 2.5. This will affect any OS! Hmm, it's a bit suspicious that the major version number is changing in a minor ghc release. Do we know what the API breakage is? This could affect any program. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Under Solaris: GHC 6.10.2 Release Candidate 1
On 2009 Mar 17, at 20:28, Duncan Coutts wrote:
On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote:
Under Solaris sh is not bash!
Indeed.
According to the OpenGroup that syntax should be fine:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_02
It works for me under Solaris 10. Perhaps Solaris 9 or older do not
have
a standard compliant /bin/sh program. What do you suggest we use
instead
as a workaround?
For backward compatibility reasons sh in Solaris 9 and earlier is not
POSIX compliant. Use /usr/xpg4/bin/sh or /bin/bash instead.
(Unfortunately you can't cheat and define a shell function, although
you could create a program called !:
#! /bin/sh
if ${1+$@}; then
exit 1
else
exit 0
fi
.)
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH
PGP.sig
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
