ANN: Mac installer pkg for GHC - 6.8.2.20080211 trial release (Leopard, Intel)
Ladies and Gentlemen, Finally, you can have the glorious GHC in a format satisfying the discerning Mac user: http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg Installation instructions: nil This is *not* the same compiler as in the official 6.8.2 release. It is the state of the 6.8 branch at the 11th of February - hence, the funny version number. Once, 6.8.3 is being released, there'll be a clean release package. The package includes all extra libraries and full documentation. It installs GHC systemwide and requires an admin password. Happy Installing! Manuel -=- Extra details for the curious -=- GHC is being packaged as a framework bundle - GHC.framework - that is installed in /Library/Frameworks/. As far as I can tell this is the most appropriate way of bundling a compiler environment on the Mac. Frameworks are versioned and we use GHC's integer version number to assign framework versions - ie, the present package installs version 608. This is in line with Apple's recommendation to use version numbers that signify API changes for frameworks. The package installs appropriate links in /usr/bin, /usr/man/man1, and /usr/share/doc to make the binaries, ghc manpage, and html documentation easily accessible. Furthermore, it comes with a shell script that removes the GHC.framework and all symbolic links into the framework. The framework is currently not relocatable and an admin password is needed to install it. Contributions improving this situation would be most welcome. The GHC binary in the package links statically against GNU readline (to provide editing capabilities at the GHCi prompt). This is fine as GHC's BSD3 licence is compatible with readline's GPL, and it does *not* affect programs compiled with GHC at all. The above package is for Intel Leopard. I expect that a separate PPC version is easy to build (but cross-compilation and fat binaries are not supported by GHC). I am less sure about building packages on Tiger as I don't know whether the underlying Xcode project requires Xcode 3.0 - Tiger only has 2.5. However, it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.) Further information on GHC installer packages as well as instructions on how to build your own are at http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
Great! Does this mean we can submit GHC to be distributed from Apple's "hackage", http://www.apple.com/downloads/ ? (Click the "Submit Downloads" button). -- Don chak:
Ladies and Gentlemen,
Finally, you can have the glorious GHC in a format satisfying the discerning Mac user:
http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.2.20080211-i386.pkg
Installation instructions: nil
This is *not* the same compiler as in the official 6.8.2 release. It is the state of the 6.8 branch at the 11th of February - hence, the funny version number. Once, 6.8.3 is being released, there'll be a clean release package.
The package includes all extra libraries and full documentation. It installs GHC systemwide and requires an admin password.
Happy Installing! Manuel
-=- Extra details for the curious -=-
GHC is being packaged as a framework bundle - GHC.framework - that is installed in /Library/Frameworks/. As far as I can tell this is the most appropriate way of bundling a compiler environment on the Mac. Frameworks are versioned and we use GHC's integer version number to assign framework versions - ie, the present package installs version 608. This is in line with Apple's recommendation to use version numbers that signify API changes for frameworks. The package installs appropriate links in /usr/bin, /usr/man/man1, and /usr/share/doc to make the binaries, ghc manpage, and html documentation easily accessible. Furthermore, it comes with a shell script that removes the GHC.framework and all symbolic links into the framework.
The framework is currently not relocatable and an admin password is needed to install it. Contributions improving this situation would be most welcome.
The GHC binary in the package links statically against GNU readline (to provide editing capabilities at the GHCi prompt). This is fine as GHC's BSD3 licence is compatible with readline's GPL, and it does *not* affect programs compiled with GHC at all.
The above package is for Intel Leopard. I expect that a separate PPC version is easy to build (but cross-compilation and fat binaries are not supported by GHC). I am less sure about building packages on Tiger as I don't know whether the underlying Xcode project requires Xcode 3.0 - Tiger only has 2.5. However, it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.)
Further information on GHC installer packages as well as instructions on how to build your own are at
http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Don Stewart:
Great!
Does this mean we can submit GHC to be distributed from Apple's "hackage", http://www.apple.com/downloads/ ? (Click the "Submit Downloads" button).
Yes, I was thinking about that, too. However, I think we should wait until 6.8.3 and until we have a stable download url for the package. I'd also be nice to have a cool logo/icon. Manuel
chak:
Don Stewart:
Great!
Does this mean we can submit GHC to be distributed from Apple's "hackage", http://www.apple.com/downloads/ ? (Click the "Submit Downloads" button).
Yes, I was thinking about that, too. However, I think we should wait until 6.8.3 and until we have a stable download url for the package. I'd also be nice to have a cool logo/icon.
Someone want to clean up the "classic" GHC logo? http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg :)
Manuel M T Chakravarty wrote:
I'd also be nice to have a cool logo/icon.
Don Stewart wrote:
Someone want to clean up the "classic" GHC logo? http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg :)
The Clyde Arc in Glasgow, combined somehow with a lambda, could be the basis of a striking logo. Unfortunately, that bridge is suffering from some serious structural and safety issues these days, so perhaps that is ill-advised... -Yitz
On 2/12/08, Yitzchak Gale
Manuel M T Chakravarty wrote:
I'd also be nice to have a cool logo/icon.
Don Stewart wrote:
Someone want to clean up the "classic" GHC logo? http://www.cse.unsw.edu.au/~dons/images/happy-dino.jpg :)
The Clyde Arc in Glasgow, combined somehow with a lambda, could be the basis of a striking logo.
A logo involving some stylized version of the Clyde Arc drawn so that it looks like it's bridging between a lambda and a CPU, or something like that (shades of this cartoon by Phil Wadler: http://cs.wellesley.edu/~cs301/fall03/lambda-and-chip.gif) could be cool. I am a mediocre artist, but I'd be willing to give it a try if there are no better ones around.
Unfortunately, that bridge is suffering from some serious structural and safety issues these days, so perhaps that is ill-advised...
It seems perfectly appropriate to me. *ducks and runs* Also, this from Manuel's original message is just beautiful:
Installation instructions: nil
I'm almost tempted to switch back to a Mac. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I like my terminals like my women: VT100 compatible with Tektronix extensions." -- Sean "Teki" Dobbs
Manuel M T Chakravarty wrote:
I'd also be nice to have a cool logo/icon.
Tim Chevalier wrote:
I am a mediocre artist, but I'd be willing to give it a try if there are no better ones around.
Sounds great, please give it a whirl.
I'm almost tempted to switch back to a Mac.
Since you have been a Mac user, you are aware of how fidgety this platform is about aesthetics. We all appreciate the overall pleasant experience, but it creates a challenge if you want to do something seemingly simple like create a decent icon. I'm sure whatever you do will be great for our purposes. But FWIW, in case you don't have it, here is a link to the section devoted to icons in the "Apple Human Interface Guidelines": http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuid... http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuid... Thanks, Yitz
Manuel M T Chakravarty wrote:
The above package is for Intel Leopard. I expect that a separate PPC version is easy to build (but cross-compilation and fat binaries are not supported by GHC).
I have not seen any announcement that GHC 6.8.x is working on OS X Leopard running on PPC. I would be pleased to be corrected.
Chris Kuklewicz:
Manuel M T Chakravarty wrote:
The above package is for Intel Leopard. I expect that a separate PPC version is easy to build (but cross-compilation and fat binaries are not supported by GHC).
I have not seen any announcement that GHC 6.8.x is working on OS X Leopard running on PPC. I would be pleased to be corrected.
Sorry, but my statement was only wrt to the mechanism used to build installer packages. If general compilation problems still persist, they will prevent you from constructing installer packages as well. (I haven't got a PPC, so I didn't keep track of that.) Manuel
Chris Kuklewicz:
I have not seen any announcement that GHC 6.8.x is working on OS X
Leopard running on PPC. I would be pleased to be corrected.
I have Christian Maeder's distribution of 6.8.2 for Tiger (as found on the the GHC download page) running on my PowerBook G4 with Leopard. No deviations from the instructions were necessary. Manuel M T Chakravarty wrote:
If general compilation problems still persist, they will prevent you from constructing installer packages as well. (I haven't got a PPC, so I didn't keep track of that.)
I'm planning on setting up the GHC source for building when I have time. If this happens, I will try to build the PPC package. Sean
I am now testing that binary distribution for powerpc on my Leopard G4 notebook. It is not always working. It is my habit to compile the Setup.hs or Setup.lhs to "setup" with "ghc --make Setup.hs -o setup". The "./setup configure ..." is working. The "./setup build" causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents). The Cabal-1.2.3.0 used is supplied by the binary distribution of ghc 6.8.2 BUT "runghc Setup.hs build" is working. And while some things succeed, such as DList-0.4, the Network.FastCGI fails:
chrisk$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2
chrisk$ runghc Setup.lhs build Preprocessing library fastcgi-3001.0.1... Building fastcgi-3001.0.1... [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.o ) [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.p_o ) ar: creating archive dist/build/libHSfastcgi-3001.0.1.a ar: creating archive dist/build/libHSfastcgi-3001.0.1_p.a ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o
So I sadly say there is still no working ghc 6.8.x for powerpc Leopard. -- Chris
Hi Chris, It is my habit to compile the Setup.hs or Setup.lhs to "setup" with "ghc
--make Setup.hs -o setup".
The "./setup configure ..." is working.
The "./setup build" causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents). The Cabal-1.2.3.0 used is supplied by the binary distribution of ghc 6.8.2
I tried the same thing and got the same result. Could it be a problem with how Cabal itself was built instead of GHC? So I sadly say there is still no working ghc 6.8.x for powerpc Leopard.
I guess you're right. Sean
Chris Kuklewicz wrote:
The "./setup build" causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents).
I can at least reproduce the segmentation fault by running my PPC-Tiger binary on an i386-Leopard, by compiling with additional options "-optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc". m29:fastcgi-3001.0.1 maeder$ ghc -opta-arch -optappc -optl-arch -optlppc --make Setup.lhs Linking Setup ... m29:fastcgi-3001.0.1 maeder$ ./Setup configure Configuring fastcgi-3001.0.1... Warning: No license-file field. m29:fastcgi-3001.0.1 maeder$ ./Setup build Segmentation fault and even (after adding the above options to the bin/ghc-6.8.2 script) m29:fastcgi-3001.0.1 maeder$ runghc Setup.lhs build Preprocessing library fastcgi-3001.0.1... Building fastcgi-3001.0.1... [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.o ) ar: creating archive dist/build/libHSfastcgi-3001.0.1.a ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o Cheers Christian
Christian Maeder:
Chris Kuklewicz wrote:
The "./setup build" causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents).
I can at least reproduce the segmentation fault by running my PPC- Tiger binary on an i386-Leopard, by compiling with additional options "-optc-arch -optcppc -opta-arch -optappc -optl-arch -optlppc".
m29:fastcgi-3001.0.1 maeder$ ghc -opta-arch -optappc -optl-arch - optlppc --make Setup.lhs Linking Setup ... m29:fastcgi-3001.0.1 maeder$ ./Setup configure Configuring fastcgi-3001.0.1... Warning: No license-file field. m29:fastcgi-3001.0.1 maeder$ ./Setup build Segmentation fault
I can't see how ghc can generate a correct executable if you pass these cross-compilation options to GHC. Even if you can get GHC to generate proper PPC code, it will link against *Haskell* libraries that contain i386 code. (The options -optl-arch -optlppc will give you the PPC versions of the system libraries, but not the GHC packages.) Or am I missing something?
and even (after adding the above options to the bin/ghc-6.8.2 script)
m29:fastcgi-3001.0.1 maeder$ runghc Setup.lhs build Preprocessing library fastcgi-3001.0.1... Building fastcgi-3001.0.1... [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.o ) ar: creating archive dist/build/libHSfastcgi-3001.0.1.a ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o
According to Wolfgang Thaller's answer to a previous post by yourself, these atom sorting errors are harmless: http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013988.h... Manuel
Manuel M T Chakravarty wrote:
I can't see how ghc can generate a correct executable if you pass these cross-compilation options to GHC. Even if you can get GHC to generate proper PPC code, it will link against *Haskell* libraries that contain i386 code.
Of course I'm using a PPC haskell compiler on i368 with its PCC *Haskell* libraries. HTH Christian
Manuel M T Chakravarty wrote:
ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o
According to Wolfgang Thaller's answer to a previous post by yourself, these atom sorting errors are harmless:
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/013988.h...
Indeed, a final "runghc Setup.lhs install" worked for me. Christian m29:~ maeder$ ghc-pkg list /home/mac-bkb/ghc/ghc-6.8.2/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, HaXml-1.13.2, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, xhtml-3000.0.2.1 /home/maeder/.ghc/powerpc-darwin-6.8.2/package.conf: HAIFA-0.11, HTTP-3001.0.0.1, Shellac-0.9, Shellac-readline-0.9, fastcgi-3001.0.1, hxt-7.3, programatica-1.0, syb-generics-2.9 m29:~ maeder$ uname -a Darwin m29.informatik.uni-bremen.de 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT 2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
Could you create a ticket for this (or is there one already)? I'm willing to recompile ghc-6.8.2 with different options or patches on PPC Tiger, but even compiling via-C does not work (not to mention bootstrapping from hc sources). http://hackage.haskell.org/trac/ghc/ticket/2012 (Only few seem to be interested in getting PPC bugs fixed. Is this architecture dying out?) Cheers Christian Does ghc-6.8.1 or ghc-6.6.1 work on PPC leopard and can be used for compiling ghc-6.8.2? Chris Kuklewicz wrote:
I am now testing that binary distribution for powerpc on my Leopard G4 notebook.
It is not always working.
It is my habit to compile the Setup.hs or Setup.lhs to "setup" with "ghc --make Setup.hs -o setup".
The "./setup configure ..." is working.
The "./setup build" causes a segmentation fault. This is for every project I try (including ones with very default Setup.hs contents). The Cabal-1.2.3.0 used is supplied by the binary distribution of ghc 6.8.2
BUT "runghc Setup.hs build" is working.
And while some things succeed, such as DList-0.4, the Network.FastCGI fails:
chrisk$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2
chrisk$ runghc Setup.lhs build Preprocessing library fastcgi-3001.0.1... Building fastcgi-3001.0.1... [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.o ) [1 of 1] Compiling Network.FastCGI ( dist/build/Network/FastCGI.hs, dist/build/Network/FastCGI.p_o ) ar: creating archive dist/build/libHSfastcgi-3001.0.1.a ar: creating archive dist/build/libHSfastcgi-3001.0.1_p.a ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o ld: atom sorting error for _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuStream_closure_tbl and _fastcgizm3001zi0zi1_NetworkziFastCGI_FCGXzuRequest_closure_tbl in dist/build/Network/FastCGI.o
So I sadly say there is still no working ghc 6.8.x for powerpc Leopard.
Christian Maeder wrote:
Could you create a ticket for this (or is there one already)?
There have been a few tickets, some still outstanding, about leopard powerpc failures.
I'm willing to recompile ghc-6.8.2 with different options or patches on PPC Tiger, but even compiling via-C does not work (not to mention bootstrapping from hc sources).
http://hackage.haskell.org/trac/ghc/ticket/2012
(Only few seem to be interested in getting PPC bugs fixed. Is this architecture dying out?)
I submitted a patch that went into ghc-6.8.x to help fix assembly code generation (to keey the new cursed 'ld' happy) on powerpc 10.5.x Apple stopped creating and selling new PPC machines some time ago. But I think nearly half of the running machines are still PPC. But only people with previous PPC hardware who buy new OS X 10.5 and also want ghc-6.8 are getting bitten.
Cheers Christian
Does ghc-6.8.1 or ghc-6.6.1 work on PPC leopard and can be used for compiling ghc-6.8.2?
The ghc-6.6.1 I had under 10.4 still works like a champ after upgrading to 10.5 -- Chris
From: Christian Maeder
Could you create a ticket for this (or is there one already)? I'm willing to recompile ghc-6.8.2 with different options or patches on PPC Tiger, but even compiling via-C does not work (not to mention bootstrapping from hc sources).
http://hackage.haskell.org/trac/ghc/ticket/2012
(Only few seem to be interested in getting PPC bugs fixed. Is this architecture dying out?)
At least I'm still happily using ghc-6.8.2 with PPC Tiger because I know there are lots of lots of problems in Leopard. Please don't abandon PPC... _______________________________________________________ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72
Manuel M T Chakravarty wrote:
Finally, you can have the glorious GHC in a format satisfying the discerning Mac user
Fantastic news! Thanks!
The GHC binary in the package links statically against GNU readline (to provide editing capabilities at the GHCi prompt). This is fine as GHC's BSD3 licence is compatible with readline's GPL, and it does *not* affect programs compiled with GHC at all.
Thank you for clarifying this.
The above package is for Intel Leopard... it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.)
I volunteer. What do I need to do? Thanks, Yitz
The above package is for Intel Leopard... it should be possible to build packages on Leopard that run on both Tiger and Leopard. (I could give that a try if anybody with a Tiger box is willing to play guinea pig.)
I volunteer. What do I need to do?
Try this http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg It's a quick build of todays HEAD with only the boot libraries. Have a look whether that installs on Tiger (I am pretty sure it will) and whether you can run /usr/bin/ghci (not so sure about that). If it works that far, please compile some small Haskell program and see whether you can run the compiled program. If we are very lucky and all of this works, please try to compile ghc itself with the compiler in the package. Thanks, Manuel PS: It's a dmg this time around, because apparently only 10.5 packages are single file archives.
Manuel M T Chakravarty wrote:
Try this http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg
I got it, but there were some download problems. I hope the file is intact. It has exactly 44740924 bytes. Perhaps you could send me an md5sum to be certain.
Have a look whether that installs on Tiger (I am pretty sure it will)
It did.
and whether you can run /usr/bin/ghci (not so sure about that).
It didn't. $ /usr/bin/ghci Bus error In the readme, you say that I require Xcode 3.0. Tiger came with Xcode 2.4.1, and I have not updated it. (I tried once, but the download was so huge that I decided to forget it unless there was some real need.) Could that be part of the problem? Thanks, Yitz
Yitzchak Gale:
Manuel M T Chakravarty wrote:
Try this http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.9.20080213-i386.dmg
I got it, but there were some download problems. I hope the file is intact. It has exactly 44740924 bytes. Perhaps you could send me an md5sum to be certain.
The file length is correct. wireless-139 chak 2 (/Users/chak): md5 Public/Web/haskell/ GHC-6.9.20080213-i386.dmg MD5 (Public/Web/haskell/GHC-6.9.20080213-i386.dmg) = cc76dea615234aa83d85ef5c30021828
and whether you can run /usr/bin/ghci (not so sure about that).
It didn't.
$ /usr/bin/ghci Bus error
In the readme, you say that I require Xcode 3.0. Tiger came with Xcode 2.4.1, and I have not updated it. (I tried once, but the download was so huge that I decided to forget it unless there was some real need.) Could that be part of the problem?
If ghc worked in the past on your machine, then your Xcode version should be fine. (It's really only important that we have a version of gcc that plays nicely with ghc.) But you are right, I need to update that readme for Tiger (the recommendation for 3.0 really only applies to Leopard.) I had a closer look at cross compilation for 10.4 and I think I know why we get the bus error and how to avoid it. To avoid you having to download another GHC build, which may have problems again, I have compiled two versions of hello world and put them in a tar ball at http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to run them both. I believe HelloWorld-Leopard will also give you a bus error, but I hope HelloWorld-Tiger will work. (Interestingly HelloWorld-Tiger is about 8x bigger than HelloWorld- Leopard. I don't think this has anything to do with GHC, but is due to Apple's cross-compilation SDK.) Manuel
Manuel M T Chakravarty wrote:
The file length is correct. MD5 (Public/Web/haskell/GHC-6.9.20080213-i386.dmg) = cc76dea615234aa83d85ef5c30021828
Bingo! Thanks. I wrote:
In the readme, you say that I require Xcode 3.0. Tiger came with Xcode 2.4.1, and I have not updated it. Could that be part of the problem?
...your Xcode version should be fine.
OK, good.
http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to run them both. I believe HelloWorld-Leopard will also give you a bus error, but I hope HelloWorld-Tiger will work.
$ ./HelloWorld-Tiger Hello World! $ ./HelloWorld-Leopard Bus error Yay! Thanks, Yitz
Yitzchak Gale:
Manuel M T Chakravarty wrote:
http://www.cse.unsw.edu.au/~chak/HelloWorld.tar.bz2 It contains HelloWorld-Leopard and HelloWorld-Tiger. Please try to run them both. I believe HelloWorld-Leopard will also give you a bus error, but I hope HelloWorld-Tiger will work.
$ ./HelloWorld-Tiger Hello World! $ ./HelloWorld-Leopard Bus error
Great. Then, I think I know what to do. I'll add a new option to configure to specify what Apple calls the "deployment target" of a GHC build. By using 10.4 as the deployment target we can then build GHC distributions in any form (installer, binary dist, or local installs) for 10.4 on a 10.5 box. However, some extra fiddling will be required to make sure utilities, such as ghc-pkg, are also properly cross- compiled. I'll let you know when I have got a new GHC installer using this approach. Manuel
Manuel M T Chakravarty wrote:
$ ./HelloWorld-Tiger Hello World! $ ./HelloWorld-Leopard Bus error
only setting export MACOSX_DEPLOYMENT_TARGET=10.4 on Leopard during compilation should make it run on a Tiger, too. HTH Christian
Christian Maeder:
Manuel M T Chakravarty wrote:
$ ./HelloWorld-Tiger Hello World! $ ./HelloWorld-Leopard Bus error
only setting
export MACOSX_DEPLOYMENT_TARGET=10.4
on Leopard during compilation should make it run on a Tiger, too.
I tried that, too, but it somehow only works partially. If I build ghc with that environment setting, the GHC binary still has some Leopard symbols in it (though much less than without that setting). Specifically, I am seeing dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr = libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc on running env DYLD_PRINT_BINDINGS= compiler/stage2/ghc-6.9.20080219 Any idea why that may be? In contrast, if I instruct GHC's build system to use -optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk -optl-mmacosx- version-min=10.4 -optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk on all CC and LD targets, I don't seem to have any Leopard symbols anymore. FWIW, Xcode 3.0 also seem to use explicit SDK options. Manuel
Manuel M T Chakravarty wrote:
Christian Maeder:
export MACOSX_DEPLOYMENT_TARGET=10.4
Specifically, I am seeing
dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr = libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc
what tells you that this is Leopard specific?
on running
env DYLD_PRINT_BINDINGS= compiler/stage2/ghc-6.9.20080219
Any idea why that may be?
no, no idea.
-optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk -optl-mmacosx-version-min=10.4
Interesting, in contrast to you I had a problem with -mmacosx-version-min and had to use MACOSX_DEPLOYMENT_TARGET when building user programs on Leopard using my Tiger bindist. http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/014093.h...
-optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk
on all CC and LD targets, I don't seem to have any Leopard symbols anymore. FWIW, Xcode 3.0 also seem to use explicit SDK options.
I haven't built ghc on Leopard, yet, but I'll expect to use -isysroot and -syslibroot then, too. Cheers Christian
Christian Maeder:
Manuel M T Chakravarty wrote:
Christian Maeder:
export MACOSX_DEPLOYMENT_TARGET=10.4
Specifically, I am seeing
dyld: bind: ghc-6.9.20080219:_fcntl$UNIX2003$lazy_ptr = libSystem.B.dylib:_fcntl$UNIX2003, *0x0108a413 = 0x92c7b7bc
what tells you that this is Leopard specific?
http://lists.apple.com/archives/darwin-dev/2007/Nov/msg00108.html
-optl-isysroot -optl/Developer/SDKs/MacOSX10.4u.sdk -optl-mmacosx-version-min=10.4
Interesting, in contrast to you I had a problem with -mmacosx-version-min and had to use MACOSX_DEPLOYMENT_TARGET when building user programs on Leopard using my Tiger bindist.
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-January/014093.h...
I made a similar observation. Using -syslibroot in addition, fixed the problem for me.
-optl-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk
on all CC and LD targets, I don't seem to have any Leopard symbols anymore. FWIW, Xcode 3.0 also seem to use explicit SDK options.
I haven't built ghc on Leopard, yet, but I'll expect to use -isysroot and -syslibroot then, too.
Hold off another day or two and you get that automatically by just using --with-macos-deployment-target=10.4 with GHC's ./configure. (This will even enable you to generate a GHC build for 10.4 from a bootstrap compiler for 10.5, which is non-trivial due to the programs in utils/ and some other stuff.) Manuel
participants (8)
-
Chris Kuklewicz -
Christian Maeder -
Don Stewart -
Manuel M T Chakravarty -
PHO -
Sean Leather -
Tim Chevalier -
Yitzchak Gale