patch applied (ghc): Turn off dtrace unless you override USE_DTRACE

[Ian Lynagh]

On Wed, Jan 19, 2011 at 07:11:51PM -0800, Mark Lentczner wrote:
> 
> On Jan 19, 2011, at 4:45 PM, Ian Lynagh wrote:
> 
> > The alternative to an installer would be a bindist,..
> 
> This seems of no advantage to me. So, if you're building installers, I'll use those! (I like the certainty of HP is shipping precisely what GHC is!)

Maybe the best solution for GHC would be to build a bindist like normal,
and then to have standalone script that can make an installer from a
bindist.

That way we could easily make both bindists and installers that we know
are the same, so we'd have the best of both worlds.

> > It'll be 10.6-only unless someone sends a patch to make the dtrace stuff
> > work on 10.5.
> 
> I suspect it will be acceptable.
> 
> Question: Does the dtrace issue only affect the compiler itself, or also things built with it? Or in otherwords, if one uses the 64-bit compiler to produce 64-bit code on 10.6, will that resulting executable run on 10.5?

The executable will work fine on 10.5 as far as I know.

> Question: Am I right in thinking that GHC doesn't have support for producing multi-architecture libraries and executables?

You are right.

> Or is there a sneaky way to do this by using -fvia-C and passing multiple -arch args to gcc?

Well, I imagine that if you do enough work yourself (e.g. calling the
linker yourself etc) then it would be possible, but I don't know.

> So, if I'm interpreting this all correctly, you'll be producing two GHC installers for Mac OS X:
> 
> 1) 32-bit compiler, libs & tools, producing 32-bit object code, runs on 10.5 and 10.6
> 2) 64-bit compiler, libs & tools, producing 64-bit object code, runs only on 10.6

Yes.

> This means that HP will need to produce two such installers as well.... Good thing I have the process almost entirely automated! Can you confirm that this is the intent?

I think that makes most sense at the moment.


Thanks
Ian