Re: Mac Port
On Sunday, June 1, 2003, at 05:15 AM, Wolfgang Thaller wrote: Seth Kurtzberg wrote: Is there, or is anyone working on, ports for Mac OSX and/or Mac OS9? I'm currently responsible for the Mac OS X version of GHC. I'll upload a GHC 6.0 binary for Mac OS X binary as soon as possible, but I'm short on time and processor cycles, so it might take a few more days. I could definitely use more people who regularily build GHC on MacOS X and do some testing, and alert me of any breakage _before_ I make a buggy release... I don't have the computing capacity to do nightly builds. Dear Wolfgang, I maintain the Hugs port for the darwinports system (a cousin of fink and perhaps the successor to the *bsd ports system). I'd like to add a port for ghc-6.0. I tried to build it but ran into some problems. 1. configure doesn't pass the CPPFLAGS and LDFLAGS environment variables to the haskell build. This means you can't have libreadline and libdl in non-standard locations. This is a problem for darwinports and fink because of their automatic dependency management. 2. Even if I put symlinks to the above libraries in the standard locations, I still get a build failure. This is building 6.0 using 5.04.3. (5.04.3 was built from source successfully using your 5.04.2 binary.) The build ends with ../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.0 -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/absCSyn -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/nativeGen -istage2/ghci -DGHCI -package haskell-src -package unix -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include hschooks.h' -no-link-chk stage2/absCSyn/AbsCSyn.o stage2/absCSyn/AbsCUtils.o stage2/absCSyn/CLabel.o stage2/absCSyn/CStrings.o stage2/absCSyn/Costs.o stage2/absCSyn/MachOp.o stage2/absCSyn/PprAbsC.o stage2/basicTypes/BasicTypes.o stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o stage2/basicTypes/FieldLabel.o stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o stage2/basicTypes/Module.o stage2/basicTypes/Name.o stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o stage2/basicTypes/VarSet.o stage2/codeGen/Bitmap.o stage2/codeGen/CgBindery.o stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o stage2/codeGen/CgConTbls.o stage2/codeGen/CgExpr.o stage2/codeGen/CgHeapery.o stage2/codeGen/CgLetNoEscape.o stage2/codeGen/CgMonad.o stage2/codeGen/CgRetConv.o stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o stage2/codeGen/CgUpdate.o stage2/codeGen/CgUsages.o stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o stage2/codeGen/SMRep.o stage2/compMan/CompManager.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o stage2/coreSyn/Subst.o stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o stage2/deSugar/Desugar.o stage2/deSugar/DsBinds.o stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o stage2/hsSyn/Convert.o stage2/hsSyn/HsBinds.o stage2/hsSyn/HsCore.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o stage2/main/BinIface.o stage2/main/CmdLineOpts.o stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o stage2/main/DriverFlags.o stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o stage2/main/DriverPipeline.o stage2/main/DriverState.o stage2/main/DriverUtil.o stage2/main/ErrUtils.o stage2/main/Finder.o stage2/main/GetImports.o stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o
Re: Mac Port
Dear Wolfgang, I maintain the Hugs port for the darwinports system (a cousin of fink and perhaps the successor to the *bsd ports system). I'd like to add a port for ghc-6.0. I tried to build it but ran into some problems. 1. configure doesn't pass the CPPFLAGS and LDFLAGS environment variables to the haskell build. This means you can't have libreadline and libdl in non-standard locations. Grmpf... I know I don't like configure scripts. I prefer IDEs. Do you know how to fix it/have time to do it? If not, would somebody else _PLEASE_ do that for us? (It wouldn't enjoy digging into the build system code to fix that; in fact, I would positively hate it). This is a problem for darwinports and fink because of their automatic dependency management. 2. Even if I put symlinks to the above libraries in the standard locations, I still get a build failure. This is building 6.0 using 5.04.3. (5.04.3 was built from source successfully using your 5.04.2 binary.) The build ends with [...] Ahem, yes. I didn't have a chance to test GHC 6 in the last five days before the release, and, of course, the last commit broke the Mac OS X build. I have meanwhile committed a fix to CVS, but that was a day after the official relase for 6.0. If you check out the newest stable branch from CVS (or ask me to send you diffs tomorrow), it should work. (That last commit made GHC quote all arguments it passes on to GHC; for Mac OS X, it passed -framework HaskellSupport instead of -framework HaskellSupport. GCC doesn't report an error but it just ignores the former. Strange.) The HaskellSupport framework (which is not used if it's not detected at configure time; there should really be a configure switch for that) is just an aggregation of libgmp and libdl packaged as a framework. I figured that would be easier for end users of Haskell programs, as libgmp is required for all Haskell programs, and libdl is used by the Posix library (and how do you install a dylib using the Finder?). For something like darwinports, it might be better to just rely on the gmp and dl libraries installed with darwinports, but that makes programs compiled using ghc dependent on darwinports, too. And you just reminded me that I still haven't uploaded the 10 line shell script for creating the HaskellSupport.framework anywhere, because I could never figure out the appropriate place in CVS: #!/bin/sh cd dlcompat-20020413 cp dlfcn.o ../ make cd ../gmp-4.0.1 ./configure make ld -r -d ./libs/libgmp.a -o ../libgmp.o cd .. ld -dylib -o HaskellSupport.framework/Versions/A/HaskellSupport libgmp.o dlfcn.o /usr/lib/dylib1.o -lSystem OK, that's all for now... Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0 (Broken Doc link)
In the release notes, the link to Data.Generics is broken, both under the latest branch and under the 6.0 branch. On 29 May, Simon Marlow wrote: The (Interactive) Glasgow Haskell Compiler -- version 6.0 We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.0. As with all .0 releases, this release should be considered beta-quality; if you want real stability, then stick with 5.04.3 for the time being. http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html (Is this the right place to send such notes?) Thanks, -- Brett G. Giles Grad Student, University of Calgary Formal Methods, Category Theory, Semantics of Programming http://www.cpsc.ucalgary.ca/~gilesb mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Mac Port
On Sunday, June 1, 2003, at 07:36 PM, Wolfgang Thaller wrote: Dear Wolfgang, I maintain the Hugs port for the darwinports system (a cousin of fink and perhaps the successor to the *bsd ports system). I'd like to add a port for ghc-6.0. I tried to build it but ran into some problems. 1. configure doesn't pass the CPPFLAGS and LDFLAGS environment variables to the haskell build. This means you can't have libreadline and libdl in non-standard locations. Grmpf... I know I don't like configure scripts. I prefer IDEs. Do you know how to fix it/have time to do it? If not, would somebody else _PLEASE_ do that for us? (It wouldn't enjoy digging into the build system code to fix that; in fact, I would positively hate it). I will take a look at the configuration issue for ghc-6.0 + Mac OS X. I was able to hand edit the makefiles to pass the correct include and library paths; it's not too big a job to pass the appropriate configuration variables. This is a problem for darwinports and fink because of their automatic dependency management. 2. Even if I put symlinks to the above libraries in the standard locations, I still get a build failure. This is building 6.0 using 5.04.3. (5.04.3 was built from source successfully using your 5.04.2 binary.) The build ends with [...] Ahem, yes. I didn't have a chance to test GHC 6 in the last five days before the release, and, of course, the last commit broke the Mac OS X build. I have meanwhile committed a fix to CVS, but that was a day after the official relase for 6.0. If you check out the newest stable branch from CVS (or ask me to send you diffs tomorrow), it should work. (That last commit made GHC quote all arguments it passes on to GHC; for Mac OS X, it passed -framework HaskellSupport instead of -framework HaskellSupport. GCC doesn't report an error but it just ignores the former. Strange.) I'll check it out from the CVS in the morning. The HaskellSupport framework (which is not used if it's not detected at configure time; there should really be a configure switch for that) is just an aggregation of libgmp and libdl packaged as a framework. I figured that would be easier for end users of Haskell programs, as libgmp is required for all Haskell programs, and libdl is used by the Posix library (and how do you install a dylib using the Finder?). For something like darwinports, it might be better to just rely on the gmp and dl libraries installed with darwinports, but that makes programs compiled using ghc dependent on darwinports, too. For darwinports, I'll probably just install gmp and dl as dependencies. There is also provision to install frameworks in $prefix/Frameworks. I'll have to think about which is more appropriate. And you just reminded me that I still haven't uploaded the 10 line shell script for creating the HaskellSupport.framework anywhere, because I could never figure out the appropriate place in CVS: #!/bin/sh cd dlcompat-20020413 cp dlfcn.o ../ make cd ../gmp-4.0.1 ./configure make ld -r -d ./libs/libgmp.a -o ../libgmp.o cd .. ld -dylib -o HaskellSupport.framework/Versions/A/HaskellSupport libgmp.o dlfcn.o /usr/lib/dylib1.o -lSystem OK, that's all for now... Cheers, Wolfgang Thanks for the help! Best Wishes, Greg ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0
Sven Panne [EMAIL PROTECTED] writes: Hmm. Perhaps you should rename the long form of -L to --list-local-packages. Just a small note: This was a buglet in System.Console.GetOpt.getOpt, which has been fixed since GHC 5.04.3. Consequently this does not happen if you use a GHC = 5.04.3 for compiling GHC 6.0. But to be on the safe side, SimonM has renamed the option, anyway... OK. The official ghc-6.0 binary distribution for Linux seems to have been built with ghc-4.08.2, hence the apparent fault. Was there a reason for choosing to bootstrap with such an old version? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0
Hmm. Perhaps you should rename the long form of -L to --list-local-packages. Just a small note: This was a buglet in System.Console.GetOpt.getOpt, which has been fixed since GHC 5.04.3. Consequently this does not happen if you use a GHC = 5.04.3 for compiling GHC 6.0. But to be on the safe side, SimonM has renamed the option, anyway... OK. The official ghc-6.0 binary distribution for Linux seems to have been built with ghc-4.08.2, hence the apparent fault. Was there a reason for choosing to bootstrap with such an old version? Strange, isn't the official binary distribution a stage-2 compiler with ghci enabled? In this case, ghc-6.0 should have been compiled by itself, or am I missing something? Just surprised ... Andres ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
long constant list of pairs (was Re: Ways and Build Tags for Optimisation)
4. Re: Ways and Build Tags for Optimisation (Ashley Yakeley) From: Ashley Yakeley [EMAIL PROTECTED] Subject: Re: Ways and Build Tags for Optimisation Date: Thu, 29 May 2003 20:40:59 -0700 Sorry for replying from a digest. (Replying from the archive is not better, is it?) Inside the module is an Array Char String created from a [(Char,String)] that is a long list of Unicode character names. We had very long compilation times when optimization or profiling was switched on, for a [(String, Int)] list with about 5000 entries. We worked around the problem by changing the list into a String (escaping doublequotes) and using read to convert it to a list. (Eventually we converted it to a Map.) getCharacterName '\x189F' MONGOLIAN LETTER MANCHU ALI GALI DDHA We had latin1 characters in our strings. Cheers Christian For some reason, even though only getCharacterName is exported, when optimisation is switched on, the interface file balloons a thousandfold: $ ls -l UnicodeNames.*hi -rw-r--r--1 ashley ashley5854480 May 28 02:49 UnicodeNames.hi -rw-r--r--1 ashley ashley5854497 May 28 06:56 UnicodeNames.p_hi -rw-r--r--1 ashley ashley 2385 May 28 15:59 UnicodeNames.q_hi What's the best way to stop this? Is it reasonable to simply switch off profiling just for these few files? Also, I'd like to make all that data disappear when a binary program that doesn't use it is stripped; currently it doesn't. Any ideas? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.0 Release: sparc-solaris2 binaries
On Fri, 30 May 2003, Simon Marlow wrote: A binary version of GHC6 is available for sparc-solaris2 machines at: http://www.isi.edu/~hdaume/ghc-6.0-sparc-solaris2.tar.bz2 17.5 mb I'd appreciate it if the maintainers could copy it and make it available locally off of the GHC web page so as to not kill bandwidth here :). Uploaded, thanks! Are the notes about libcurses etc. still relevant? (see the download page). Uhmmm When I installed the dist and tried it I got the following message: ghci: /nfs/moussor/hdaume/lib/ghc-6.0/ghc-6.0: not found The fix is easy, just change the scripts ghc-6.0 and ghci-6.0. Would be nice if you could ship a correct binary dist though... All the best, /Josef ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC version 6.0
Sven Panne [EMAIL PROTECTED] writes: Hmm. Perhaps you should rename the long form of -L to --list-local-packages. Just a small note: This was a buglet in System.Console.GetOpt.getOpt, which has been fixed since GHC 5.04.3. Consequently this does not happen if you use a GHC = 5.04.3 for compiling GHC 6.0. But to be on the safe side, SimonM has renamed the option, anyway... OK. The official ghc-6.0 binary distribution for Linux seems to have been built with ghc-4.08.2, hence the apparent fault. Was there a reason for choosing to bootstrap with such an old version? The ghc-pkg utility was built with 4.08.2; GHC itself was bootstrapped. The reason is the new bootstrapping facility in the build system, which means that we don't have to compile the entire tree again for each bootstrapping stage - I hadn't considered that this might have disadvantages :-) Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.0
20030530()0006 Simon Marlow : We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 6.0. Thanks for the release! :-) I have built rpms of ghc-6.0 on Red Hat Linux 9. I didn't build the libraries with profiling this time, however the package includes the docs, the xlib binding from hslibs and hence green-card from cvs too (a number of patches/hacks were needed for this and they can be found in the nosrc rpm). The packages are currently lying at http://haskell.cs.yale.edu/~petersen/rpms/i386/ghc-6.0-1_rhl9.i386.rpm http://haskell.cs.yale.edu/~petersen/rpms/i386/ghc-doc-6.0-1.i386.rpm http://haskell.cs.yale.edu/~petersen/rpms/srpms/ghc-6.0-1.nosrc.rpm (Note the nosrc rpm doesn't include the ghc-6.0 tarball, you'll have to download that separately if you wish to rebuild the package.) Enjoy and let me know if you have any problems, Jens ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
