On Nov 6, 2007, at 12:43 PM, Christian Maeder wrote:

I've tried to install your package, but already configure failed with:

I successfully installed this package a few times on the same machine. -- http://wagerlabs.com

Christian Maeder:

Manuel M T Chakravarty wrote:

...

A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2

The name of a binary distribution for Mac OS X 10.4 (Tiger) would be the same.

I've tried to install your package, but already configure failed with:

checking build system type... i386-apple-darwin8.10.1 checking host system type... i386-apple-darwin8.10.1 checking target system type... i386-apple-darwin8.10.1 Which we'll further canonicalise into: i386-apple-darwin checking for path to top of build tree... configure: error: cannot determine current directory

because "utils/pwd/pwd" results in a "Bus error"

I wasn't expecting any backwards compatibility from Leopard-built software to Tiger, but then I am also a Mac-noob and maybe there are ways to achieve that that I don't know of. Any suggestions? As for the name of the file. The GNU-style arch-vendor-os triples do generally not distinguish between OS versions (same deal on Linux). Hence, I added the version information as meta information in my email. What we really need is a proper .mpkg, but at the moment, I don't have time for that. The above binary first of all was meant to help bootstrapping GHC for people who upgraded to Leopard and have problems (which it seemed on irc, there were a few of). Manuel PS: Some people asked about a pcc binary. I am sorry, but I only have got an x86 mac.

Christian Maeder:

Manuel M T Chakravarty wrote:

...

I wasn't expecting any backwards compatibility from Leopard-built software to Tiger, but then I am also a Mac-noob and maybe there are ways to achieve that that I don't know of. Any suggestions?

Could you, or someone else with Leopard, check if my Tiger binary distribution is useable? (or what the problems are?)

I didn't try, but I guess, it would lead to the same problems as your GHC 6.6.1 distribution caused on Leopard (ie, linker error complaining about _environ). The problem there was, I think, the GMP framework.

...

What we really need is a proper .mpkg, but at the moment, I don't have time for that.

I've found that page http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html

It would help if we could at least agree on using frameworks or dylibs for readline and gmp. That'll be important for any installer.

Maybe ghc could also support private frameworks (in conjunction with http://hackage.haskell.org/trac/ghc/ticket/1798).

...

The above binary first of all was meant to help bootstrapping GHC for people who upgraded to Leopard and have problems (which it seemed on irc, there were a few of).

Fair enough, but the current state under http://www.haskell.org/ghc/download_ghc_681.html#macosxintel is worse compared to version 6.6.1 when http://hackage.haskell.org/trac/ghc/ticket/1540 was created.

I agree, we need to do something about that. There are two reasons why I haven't done anything yet. Firstly, I have been to busy with other things, but that hopefully changes when all my teaching obligations for this year are discharged (ie, in about two weeks). Secondly, the really unsatisfactory thing about frameworks for readline and gmp is that it entails that programs compiled with GHC will also depend on at least the GMP framework. I'd really like to have a story that extends nicely to programs built with GHC. Otherwise, if we produce a mpkg, I don't it doesn't matter much what the internal structure is. An mpkg can contain sub-packages for frameworks internally (which will be automatically installed) if not yet present. Manuel

On Nov 6, 2007, at 4:06 PM, Manuel M T Chakravarty wrote:

I wasn't expecting any backwards compatibility from Leopard-built software to Tiger, but then I am also a Mac-noob and maybe there are ways to achieve that that I don't know of. Any suggestions?

Sorry, I missed this the first time around... To build binaries on Leopard that are compatible with previous releases of Mac OS X, you need to use the appropriate SDK parameters when invoking gcc (for includes) and the linker (for libraries). This is described in the context of building a universal binary in: http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/comp... /apple_ref/doc/uid/TP40002850-BAJCFEBA but the same concepts (-isysroot for gcc and -Wl,-syslibroot for ld) apply to building against any SDK. An SDK is basically a copy of the frameworks and libraries for a particular OS release, but the libraries are just stubs to link against. By pointing gcc and ld at an SDK, you use the correct headers and entry points for a particular release. Caveat: I don't know how use of SDKs interacts with use of non-system libraries (e.g., in /opt/local or /Library/Frameworks). Another approach is to set MAC_OS_X_VERSION_MIN_REQUIRED to MAC_OS_X_VERSION_10_4 (or whatever). You then have to be careful about how you use APIs that are new in Leopard. I would think the SDK approach would be easier for something like ghc. If you don't do anything, by default binaries built on a particular Mac OS X release will only run on that release or later. Deborah

setting MACOSX_DEPLOYMENT_TARGET=10.4 or MACOSX_DEPLOYMENT_TARGET=10.3 on an Intel Leopard produced binaries executable on Intel Tigers (we have no Intel Panther, though) Without MACOSX_DEPLOYMENT_TARGET binaries from Leopard yield "Bus Error" on Tiger. The binary was built using my own binary-dist for Intel Tiger (Mac OS 10.4) (with GMP and GNUreadline frameworks). Christian Deborah Goldsmith wrote:

On Nov 6, 2007, at 4:06 PM, Manuel M T Chakravarty wrote:

...

I wasn't expecting any backwards compatibility from Leopard-built software to Tiger, but then I am also a Mac-noob and maybe there are ways to achieve that that I don't know of. Any suggestions?

Sorry, I missed this the first time around...

To build binaries on Leopard that are compatible with previous releases of Mac OS X, you need to use the appropriate SDK parameters when invoking gcc (for includes) and the linker (for libraries). This is described in the context of building a universal binary in:

http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/comp...

but the same concepts (-isysroot for gcc and -Wl,-syslibroot for ld) apply to building against any SDK.

An SDK is basically a copy of the frameworks and libraries for a particular OS release, but the libraries are just stubs to link against. By pointing gcc and ld at an SDK, you use the correct headers and entry points for a particular release.

Caveat: I don't know how use of SDKs interacts with use of non-system libraries (e.g., in /opt/local or /Library/Frameworks).

Another approach is to set MAC_OS_X_VERSION_MIN_REQUIRED to MAC_OS_X_VERSION_10_4 (or whatever). You then have to be careful about how you use APIs that are new in Leopard. I would think the SDK approach would be easier for something like ghc.

If you don't do anything, by default binaries built on a particular Mac OS X release will only run on that release or later.

Deborah

Manuel M T Chakravarty wrote:

What we really need is a proper .mpkg

How about a simple disk image (.dmg) that can be moved around as long as the relative paths within the image remain the same? This would require to allow relative paths in package.conf files (which would be useful, anyway). The wrapper scripts for ghc, ghci and ghc-pkg could be easily rewritten. I'm not sure if ranlib needs to be called, whenever the archives are moved. Are there other problems? Cheers Christian

Ian,

Is there a way for GHC on OS X to find where it was run from, so that it can find package.conf?

The command: ghc --print-libdir should do it. Cheers, Chris.

Ian Lynagh wrote:

On Sat, Nov 17, 2007 at 03:02:55PM +0000, C.M.Brown wrote:

...

...

Is there a way for GHC on OS X to find where it was run from, so that it can find package.conf? The command:

ghc --print-libdir

should do it.

But the way that knows what to print on unix machines is that ghc is a shell script wrapper which passes -B<libdir> to the real GHC binary. If you want to be able to move GHC around then the wrapper can't have the path hardcoded.

The wrapper could call `pwd` to find out the current path. Christian

Simon Marlow wrote:

Christian Maeder wrote:

...

Ian Lynagh wrote:

...

...

...

Is there a way for GHC on OS X to find where it was run from, so that it can find package.conf? The command:

ghc --print-libdir

should do it. But the way that knows what to print on unix machines is that ghc is a shell script wrapper which passes -B<libdir> to the real GHC binary. If you want to be able to move GHC around then the wrapper can't have the

On Sat, Nov 17, 2007 at 03:02:55PM +0000, C.M.Brown wrote: path hardcoded.

The wrapper could call `pwd` to find out the current path.

pwd gives you the directory that the script was invoked *from*, not the directory in which the script resides. This is a common problem on Unix: there's no general way to find out the location of a binary.

Next attempt: How about `dirname $0`? Christian

On Nov 19, 2007 10:51 AM, Alfonso Acosta wrote:

Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones.

I meant _use_ the first argument of the script ($0) for absolute paths and combine it with pwd for relative ones.

Christian Maeder wrote:

Alfonso Acosta wrote:

...

On Nov 19, 2007 10:51 AM, Alfonso Acosta wrote:

...

Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones. I meant _use_ the first argument of the script ($0) for absolute paths and combine it with pwd for relative ones.

#!/bin/sh reldir=`dirname $0` topdir=`(cd $reldir; pwd)`

There's no guarantee that $0 holds anything reasonable: you can set $0 to whatever you like when calling exec*(). Cheers, Simon

An additional sanity check of "topdir" makes sense then. Christian Alfonso Acosta wrote:

Simon, as usual, is right. It's been quite a while since I last seriously coded in C. From the exec* man page:

"The first argument, *by convention*, should point to the file name associated with the file being executed."

However, if nothing better is found I guess it's better to rely on an extended convention rather than hardcoding paths.

On Nov 19, 2007 11:40 AM, Simon Marlow wrote:

...

Christian Maeder wrote:

...

Alfonso Acosta wrote:

...

On Nov 19, 2007 10:51 AM, Alfonso Acosta wrote:

...

Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones. I meant _use_ the first argument of the script ($0) for absolute paths and combine it with pwd for relative ones. #!/bin/sh reldir=`dirname $0` topdir=`(cd $reldir; pwd)` There's no guarantee that $0 holds anything reasonable: you can set $0 to whatever you like when calling exec*().

Cheers, Simon

Deborah Goldsmith wrote,

If you want to get the path to the main executable on Mac OS X, use _NSGetExecutablePath. See:

man 3 dyld

That's exactly what we need. The man page is on the web for those without a mac: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/dyld... Thanks Deborah! Manuel

On Nov 19, 2007, at 4:07 AM, Christian Maeder wrote:

...

An additional sanity check of "topdir" makes sense then.

Christian

Alfonso Acosta wrote:

...

Simon, as usual, is right. It's been quite a while since I last seriously coded in C. From the exec* man page:

"The first argument, *by convention*, should point to the file name associated with the file being executed."

However, if nothing better is found I guess it's better to rely on an extended convention rather than hardcoding paths.

On Nov 19, 2007 11:40 AM, Simon Marlow wrote:

...

Christian Maeder wrote:

...

Alfonso Acosta wrote:

...

On Nov 19, 2007 10:51 AM, Alfonso Acosta wrote: > Well, you can always combine the first argument of the script > ($0) for > absolute paths and combine it with with pwd for relative ones. I meant _use_ the first argument of the script ($0) for absolute paths and combine it with pwd for relative ones. #!/bin/sh reldir=`dirname $0` topdir=`(cd $reldir; pwd)` There's no guarantee that $0 holds anything reasonable: you can set $0 to whatever you like when calling exec*().

Cheers, Simon

---

Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

may i suggest a different approach? most shells have commands to list programs in PATH beyond the first match, such as 'whereis ssh', 'which -a ssh', or 'type -a ssh'. now, this won't help directly because the ghc tool in question might not be on the PATH. but as this issue is so widespread, one could extend one of the existing haskell package registries (ghc-pkg, cabal) to cover haskell tools as well. every haskell tool would know how to register itself with its current location, and how to query the haskell tool registry for the location of other tools (preferably from the same build/version). since we're on the ghc list: ghc-tools (un-)register <path>/ghc<version> ghc-tools list ghc<version> ghc-tools describe runhaskell ghc-tools field location ghc-6.9 ghc-tools field user_guide ghc-6.9 .. pros: - knowing your version would be sufficient to find all the tools from your bundle - finding all available haskell tools would be easy downsides: - tools would have to register themselves after installation/relocation, and unregister during uninstall - there is no single ghc-pkg/cabal instance to choose, but multiple versions.. the former is no worse than for packages, the latter is a runhaskell-style issue: we want a single ghc-tools in the path, but we don't care who provides it. claus ----- Original Message ----- From: "Simon Marlow" To: "Christian Maeder" Cc: "Manuel M T Chakravarty" ; "GHC List" Sent: Monday, November 19, 2007 9:35 AM Subject: Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)

Christian Maeder wrote:

...

Ian Lynagh wrote:

...

...

...

Is there a way for GHC on OS X to find where it was run from, so that it can find package.conf? The command:

ghc --print-libdir

should do it. But the way that knows what to print on unix machines is that ghc is a shell script wrapper which passes -B<libdir> to the real GHC binary. If you want to be able to move GHC around then the wrapper can't have the

On Sat, Nov 17, 2007 at 03:02:55PM +0000, C.M.Brown wrote: path hardcoded.

The wrapper could call `pwd` to find out the current path.

pwd gives you the directory that the script was invoked *from*, not the directory in which the script resides. This is a common problem on Unix: there's no general way to find out the location of a binary.

Well that's not entirely true. On Linux you have /proc/<pid>/exe, and on Solaris you have getexecname(). Does MacOS X have anything?

Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

registry sounds like overkill to me. If really an absolute hardcoded path is needed, I would appreciate if it is stored only in a single place (for ghc, ghci, ghc-pkg and package.conf).

that was my point: how do you find that 'single place', given the wide variety of versions, platforms, packagers, installation-specific availability, ..? the only half-way portable solution (without a special case for every platform) i can think of is a program in PATH. we don't always keep all versions of ghc tools in PATH, but we need one single tool "to bind them all"..;-) as long as that tool can be found in PATH, it can serve as a mediator/abstract interface for finding everything else, independent of platform.

Other tools have a "relocate" script, that only changes that location after unpacking (or move).

think of 'ghc-tools' as the guardian for your 'single place' and of 'ghc-tools relocate' as your relocate script. claus

Cheers Christian

Claus Reinke wrote:

...

may i suggest a different approach? most shells have commands to list programs in PATH beyond the first match, such as 'whereis ssh', 'which -a ssh', or 'type -a ssh'. now, this won't help directly because the ghc tool in question might not be on the PATH.

but as this issue is so widespread, one could extend one of the existing haskell package registries (ghc-pkg, cabal) to cover haskell tools as well. every haskell tool would know how to register itself with its current location, and how to query the haskell tool registry for the location of other tools (preferably from the same build/version). since we're on the ghc list:

ghc-tools (un-)register <path>/ghc<version> ghc-tools list ghc<version> ghc-tools describe runhaskell ghc-tools field location ghc-6.9 ghc-tools field user_guide ghc-6.9 ..

pros:

- knowing your version would be sufficient to find all the tools from your bundle - finding all available haskell tools would be easy

downsides: - tools would have to register themselves after installation/relocation, and unregister during uninstall - there is no single ghc-pkg/cabal instance to choose, but multiple versions..

the former is no worse than for packages, the latter is a runhaskell-style issue: we want a single ghc-tools in the path, but we don't care who provides it.

claus

----- Original Message ----- From: "Simon Marlow" To: "Christian Maeder" Cc: "Manuel M T Chakravarty" ; "GHC List" Sent: Monday, November 19, 2007 9:35 AM Subject: Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)

...

Christian Maeder wrote:

...

Ian Lynagh wrote:

...

...

> Is there a way for GHC on OS X to find where it was run from, so > that it > can find package.conf? The command:

ghc --print-libdir

should do it. But the way that knows what to print on unix machines is that ghc is a shell script wrapper which passes -B<libdir> to the real GHC binary. If you want to be able to move GHC around then the wrapper can't have the

On Sat, Nov 17, 2007 at 03:02:55PM +0000, C.M.Brown wrote: path hardcoded.

The wrapper could call `pwd` to find out the current path.

pwd gives you the directory that the script was invoked *from*, not the directory in which the script resides. This is a common problem on Unix: there's no general way to find out the location of a binary.

Well that's not entirely true. On Linux you have /proc/<pid>/exe, and on Solaris you have getexecname(). Does MacOS X have anything?

Cheers, Simon _______________________________________________ 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

Christian Maeder:

Manuel M T Chakravarty wrote:

...

What we really need is a proper .mpkg

How about a simple disk image (.dmg) that can be moved around as long as the relative paths within the image remain the same?

This would require to allow relative paths in package.conf files (which would be useful, anyway). The wrapper scripts for ghc, ghci and ghc- pkg could be easily rewritten.

I'm not sure if ranlib needs to be called, whenever the archives are moved.

A dmg makes it potentially harder to deal with readline and gmp, as a mpkg can embed other sub-packages. Secondly, if you look at the installation process of binary distributions, it does run code in order to re-locate GHC. With an mpkg we can have a post-install script. Manuel

Brian P. O'Hanlon wrote:

On Nov 6, 2007 1:29 AM, Manuel M T Chakravarty wrote:

...

A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2

You do not perchance have one for powerpc, do you? I attempted to bootstrap from GHC 6.6.1, but I keep getting errors about "Illegal Instructions", both using the native gcc 4.0 and my own 4.2 compiler. The error is like this:

I am also failing to compile ghc-6.8.1 for a powerpc (G4 powerbook). I am giving a try to leave out the extra src tarball to see if that avoids it dying again while trying to compile parsec. Of course, it takes many hours to try to compile. -- Chris

haskell@list.mightyreason.com:

Brian P. O'Hanlon wrote:

...

On Nov 6, 2007 1:29 AM, Manuel M T Chakravarty wrote:

...

A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2

You do not perchance have one for powerpc, do you? I attempted to bootstrap from GHC 6.6.1, but I keep getting errors about "Illegal Instructions", both using the native gcc 4.0 and my own 4.2 compiler. The error is like this:

I am also failing to compile ghc-6.8.1 for a powerpc (G4 powerbook). I am giving a try to leave out the extra src tarball to see if that avoids it dying again while trying to compile parsec. Of course, it takes many hours to try to compile.

I have no experience with PPC. In any case, trying to compile a minimal system (ie, no extra libs) seems a good idea. Manuel

It seems 10.5/PPC/6.8 is currently a lethal combination. (not x86 though, nor 10.4/ppc). Here's the ticket, add yourself to the CC list. http://hackage.haskell.org/trac/ghc/ticket/1843 haskell:

I ultimately failed to get 6.8.1 working on OS X 10.5 (with XCode 3.0).

The compile finished, the only odd thing was the often multiply repeated message "unknown scattered relocation type 4" during compilation. I have the configure and build log, but I doubt it holds anything useful.

So now I have a compiler/stage1/ghc-6.8.1 and compiler/stage1/ghc-inplace whcih work, and a compiler/stage2/ghc-6.8.1 and compiler/stage2/ghc-inplace that Segmentation Fault when I try to run either.

"make install" works, but installs a Segmentation Faulting compiler.

I give up until someone else can report a recipe for success or posts a binary for powerpc G4 or has a really convincing hypothesis.

The good news is that the ghc-6.6.1 leftover from OS 10.4.x still works.

-- Chris

haskell@list.mightyreason.com wrote:

...

Brian P. O'Hanlon wrote:

...

On Nov 6, 2007 1:29 AM, Manuel M T Chakravarty wrote:

...

A full binary distribution of GHC 6.8.1 for Mac OS X 10.5 (Leopard) is available from

http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.1-i386-apple-darwin.tar.bz2 You do not perchance have one for powerpc, do you? I attempted to bootstrap from GHC 6.6.1, but I keep getting errors about "Illegal Instructions", both using the native gcc 4.0 and my own 4.2 compiler. The error is like this:

I am also failing to compile ghc-6.8.1 for a powerpc (G4 powerbook). I am giving a try to leave out the extra src tarball to see if that avoids it dying again while trying to compile parsec. Of course, it takes many hours to try to compile.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Nov 8, 2007, at 2:17 PM, Simon Marlow wrote:

We need a Mac hero (or heroes) who can diagnose and fix this problem. Any takers? You stand to earn the gratitude of the Mac/ GHC community!

My PPC Mac is thousands of miles away but if anyone can give me SSH access to their PPC/Leopard box, I could take a look. -- http://wagerlabs.com