Re: [Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-09-27 Thread Gregory Collins 
Tom Tobin  writes:

> On Tue, Sep 1, 2009 at 3:14 AM, Christian
> Maeder wrote:
>>
>> It seems, bootstrapping cabal went wrong. Does
>> http://hackage.haskell.org/platform/2009.2.0.2/haskell-platform-2009.2.0.2-i386.dmg
>> work?
>
> Installing the Haskell Platform package, combined with adding the
> previously mentioned options to /usr/bin/ghc (-optc-m32 -opta-m32
> -optl-m32), seems to have done the trick.  Thank you!

N.B. everybody, you also need to patch /usr/bin/hsc2hs to read:

exec 
/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/hsc2hs \
$tflag $HSC2HS_EXTRA --cflag="-m32" --lflag="-m32" ${1+"$@"} "$Iflag"

if you want FFI to work. See details on
http://hackage.haskell.org/trac/ghc/ticket/3400#comment:9.

G.
-- 
Gregory Collins 
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-10 Thread Brian Sniffen 
My problems were resolved by removing MacPorts from the system and
adding 32-bit flags to runhaskell---apparently its zlib was
interfering, as well as the runhaskell/runghc problems.

Thank you for the advice,
Brian

On Wed, Sep 9, 2009 at 3:49 AM, Christian Maeder
 wrote:
> If compiling template haskell of Pandoc still does not work, please make
> a ticket as Simon wrote in:
>
> http://hackage.haskell.org/trac/ghc/ticket/2965#comment:24
>
> Cheers Christian
>
> Christian Maeder wrote:
>> Maybe runhaskell is used for template haskell?
>>
>> HTH Christian
>>
>> Brian Sniffen wrote:
>>> No, my ghci is now "exec
>>> /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc-6.10.4
>>> -optc-m32 -opta-m32 -optl-m32 --interactive ${1+"$@"}" and I still see
>>> the same result.  Also, I have switched to "--ld-options" instead of
>>> "--ld-option," which appears to have been a typo---cabal and setup
>>> never parsed it.
>>>
>>> -Brian
>>>
>>> On Fri, Sep 4, 2009 at 9:51 AM, Christian Maeder
>>>  wrote:
 Does adding -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci
 as well not help? (as I've posted before)

 Cheers Christian

 Brian Sniffen wrote:
> Having edited the Haskell Platform's /usr/bin/ghc in place, most
> packages install fine.  I'm still having trouble with Pandoc, even
> given the advice:
>
>> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
>> may be used. These options may also be passed to "./Setup configure"
> The problem appears to come when linking an incompatible zlib version:
>
> src/Text/Pandoc/ODT.hs:49:26:
>   Exception when trying to run compile-time code:
>     user error (Codec.Compression.Zlib: incompatible zlib version)
>     Code: ($) makeZip "data"  "odt-styles"
>   In the first argument of `read', namely
>       `$(makeZip $ "data"  "odt-styles")'
>   In the expression: read ($(makeZip $ "data"  "odt-styles"))
>   In the definition of `refArchive':
>       refArchive = read ($(makeZip $ "data"  "odt-styles"))
>
> The same problem occurs when making any call to Codec.Archive.Zip or
> Codec.Compression.Zlib.
>
> I do have a universal zlib installed by MacPorts, as well as the
> universal zlib that shipped with Snow Leopard and the universal zlib
> that came with Cabal.  I'm not sure whether this message indicates
> that TH code is searching a different library path than non-TH code or
> what.  Advice is most welcome.  I'm particularly interested in finding
> out which zlib versions are being found at the construction of
> Codec.Compression.Zlib and at runtime (Pandoc compile time).
>
>
>
>
>>>
>>>
>



-- 
Brian Sniffen
http://evenmere.org/~bts/

___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-09 Thread Christian Maeder 
If compiling template haskell of Pandoc still does not work, please make
a ticket as Simon wrote in:

http://hackage.haskell.org/trac/ghc/ticket/2965#comment:24

Cheers Christian

Christian Maeder wrote:
> Maybe runhaskell is used for template haskell?
> 
> HTH Christian
> 
> Brian Sniffen wrote:
>> No, my ghci is now "exec
>> /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc-6.10.4
>> -optc-m32 -opta-m32 -optl-m32 --interactive ${1+"$@"}" and I still see
>> the same result.  Also, I have switched to "--ld-options" instead of
>> "--ld-option," which appears to have been a typo---cabal and setup
>> never parsed it.
>>
>> -Brian
>>
>> On Fri, Sep 4, 2009 at 9:51 AM, Christian Maeder
>>  wrote:
>>> Does adding -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci
>>> as well not help? (as I've posted before)
>>>
>>> Cheers Christian
>>>
>>> Brian Sniffen wrote:
 Having edited the Haskell Platform's /usr/bin/ghc in place, most
 packages install fine.  I'm still having trouble with Pandoc, even
 given the advice:

> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
> may be used. These options may also be passed to "./Setup configure"
 The problem appears to come when linking an incompatible zlib version:

 src/Text/Pandoc/ODT.hs:49:26:
   Exception when trying to run compile-time code:
 user error (Codec.Compression.Zlib: incompatible zlib version)
 Code: ($) makeZip "data"  "odt-styles"
   In the first argument of `read', namely
   `$(makeZip $ "data"  "odt-styles")'
   In the expression: read ($(makeZip $ "data"  "odt-styles"))
   In the definition of `refArchive':
   refArchive = read ($(makeZip $ "data"  "odt-styles"))

 The same problem occurs when making any call to Codec.Archive.Zip or
 Codec.Compression.Zlib.

 I do have a universal zlib installed by MacPorts, as well as the
 universal zlib that shipped with Snow Leopard and the universal zlib
 that came with Cabal.  I'm not sure whether this message indicates
 that TH code is searching a different library path than non-TH code or
 what.  Advice is most welcome.  I'm particularly interested in finding
 out which zlib versions are being found at the construction of
 Codec.Compression.Zlib and at runtime (Pandoc compile time).




>>
>>
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-04 Thread Tom Tobin 
On Fri, Sep 4, 2009 at 10:38 AM, Christian
Maeder wrote:
> Or "runghc" form /usr/bin?

/usr/bin/runghc is a symlink to the same file as runhaskell.
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-04 Thread Christian Maeder 
Or "runghc" form /usr/bin?

Christian Maeder wrote:
> Maybe runhaskell is used for template haskell?
> 
> HTH Christian
> 
> Brian Sniffen wrote:
>> No, my ghci is now "exec
>> /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc-6.10.4
>> -optc-m32 -opta-m32 -optl-m32 --interactive ${1+"$@"}" and I still see
>> the same result.  Also, I have switched to "--ld-options" instead of
>> "--ld-option," which appears to have been a typo---cabal and setup
>> never parsed it.
>>
>> -Brian
>>
>> On Fri, Sep 4, 2009 at 9:51 AM, Christian Maeder
>>  wrote:
>>> Does adding -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci
>>> as well not help? (as I've posted before)
>>>
>>> Cheers Christian
>>>
>>> Brian Sniffen wrote:
 Having edited the Haskell Platform's /usr/bin/ghc in place, most
 packages install fine.  I'm still having trouble with Pandoc, even
 given the advice:

> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
> may be used. These options may also be passed to "./Setup configure"
 The problem appears to come when linking an incompatible zlib version:

 src/Text/Pandoc/ODT.hs:49:26:
   Exception when trying to run compile-time code:
 user error (Codec.Compression.Zlib: incompatible zlib version)
 Code: ($) makeZip "data"  "odt-styles"
   In the first argument of `read', namely
   `$(makeZip $ "data"  "odt-styles")'
   In the expression: read ($(makeZip $ "data"  "odt-styles"))
   In the definition of `refArchive':
   refArchive = read ($(makeZip $ "data"  "odt-styles"))

 The same problem occurs when making any call to Codec.Archive.Zip or
 Codec.Compression.Zlib.

 I do have a universal zlib installed by MacPorts, as well as the
 universal zlib that shipped with Snow Leopard and the universal zlib
 that came with Cabal.  I'm not sure whether this message indicates
 that TH code is searching a different library path than non-TH code or
 what.  Advice is most welcome.  I'm particularly interested in finding
 out which zlib versions are being found at the construction of
 Codec.Compression.Zlib and at runtime (Pandoc compile time).




>>
>>
> 
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-04 Thread Christian Maeder 
Maybe runhaskell is used for template haskell?

HTH Christian

Brian Sniffen wrote:
> No, my ghci is now "exec
> /Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc-6.10.4
> -optc-m32 -opta-m32 -optl-m32 --interactive ${1+"$@"}" and I still see
> the same result.  Also, I have switched to "--ld-options" instead of
> "--ld-option," which appears to have been a typo---cabal and setup
> never parsed it.
> 
> -Brian
> 
> On Fri, Sep 4, 2009 at 9:51 AM, Christian Maeder
>  wrote:
>> Does adding -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci
>> as well not help? (as I've posted before)
>>
>> Cheers Christian
>>
>> Brian Sniffen wrote:
>>> Having edited the Haskell Platform's /usr/bin/ghc in place, most
>>> packages install fine.  I'm still having trouble with Pandoc, even
>>> given the advice:
>>>
 Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
 may be used. These options may also be passed to "./Setup configure"
>>> The problem appears to come when linking an incompatible zlib version:
>>>
>>> src/Text/Pandoc/ODT.hs:49:26:
>>>   Exception when trying to run compile-time code:
>>> user error (Codec.Compression.Zlib: incompatible zlib version)
>>> Code: ($) makeZip "data"  "odt-styles"
>>>   In the first argument of `read', namely
>>>   `$(makeZip $ "data"  "odt-styles")'
>>>   In the expression: read ($(makeZip $ "data"  "odt-styles"))
>>>   In the definition of `refArchive':
>>>   refArchive = read ($(makeZip $ "data"  "odt-styles"))
>>>
>>> The same problem occurs when making any call to Codec.Archive.Zip or
>>> Codec.Compression.Zlib.
>>>
>>> I do have a universal zlib installed by MacPorts, as well as the
>>> universal zlib that shipped with Snow Leopard and the universal zlib
>>> that came with Cabal.  I'm not sure whether this message indicates
>>> that TH code is searching a different library path than non-TH code or
>>> what.  Advice is most welcome.  I'm particularly interested in finding
>>> out which zlib versions are being found at the construction of
>>> Codec.Compression.Zlib and at runtime (Pandoc compile time).
>>>
>>>
>>>
>>>
> 
> 
> 
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-04 Thread Brian Sniffen 
No, my ghci is now "exec
/Library/Frameworks/GHC.framework/Versions/610/usr/bin/ghc-6.10.4
-optc-m32 -opta-m32 -optl-m32 --interactive ${1+"$@"}" and I still see
the same result.  Also, I have switched to "--ld-options" instead of
"--ld-option," which appears to have been a typo---cabal and setup
never parsed it.

-Brian

On Fri, Sep 4, 2009 at 9:51 AM, Christian Maeder
 wrote:
> Does adding -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci
> as well not help? (as I've posted before)
>
> Cheers Christian
>
> Brian Sniffen wrote:
>> Having edited the Haskell Platform's /usr/bin/ghc in place, most
>> packages install fine.  I'm still having trouble with Pandoc, even
>> given the advice:
>>
>>> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
>>> may be used. These options may also be passed to "./Setup configure"
>>
>> The problem appears to come when linking an incompatible zlib version:
>>
>> src/Text/Pandoc/ODT.hs:49:26:
>>   Exception when trying to run compile-time code:
>>     user error (Codec.Compression.Zlib: incompatible zlib version)
>>     Code: ($) makeZip "data"  "odt-styles"
>>   In the first argument of `read', namely
>>       `$(makeZip $ "data"  "odt-styles")'
>>   In the expression: read ($(makeZip $ "data"  "odt-styles"))
>>   In the definition of `refArchive':
>>       refArchive = read ($(makeZip $ "data"  "odt-styles"))
>>
>> The same problem occurs when making any call to Codec.Archive.Zip or
>> Codec.Compression.Zlib.
>>
>> I do have a universal zlib installed by MacPorts, as well as the
>> universal zlib that shipped with Snow Leopard and the universal zlib
>> that came with Cabal.  I'm not sure whether this message indicates
>> that TH code is searching a different library path than non-TH code or
>> what.  Advice is most welcome.  I'm particularly interested in finding
>> out which zlib versions are being found at the construction of
>> Codec.Compression.Zlib and at runtime (Pandoc compile time).
>>
>>
>>
>>
>



-- 
Brian Sniffen
http://evenmere.org/~bts/

___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-04 Thread Christian Maeder 
Does adding -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci
as well not help? (as I've posted before)

Cheers Christian

Brian Sniffen wrote:
> Having edited the Haskell Platform's /usr/bin/ghc in place, most
> packages install fine.  I'm still having trouble with Pandoc, even
> given the advice:
> 
>> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
>> may be used. These options may also be passed to "./Setup configure"
> 
> The problem appears to come when linking an incompatible zlib version:
> 
> src/Text/Pandoc/ODT.hs:49:26:
>   Exception when trying to run compile-time code:
> user error (Codec.Compression.Zlib: incompatible zlib version)
> Code: ($) makeZip "data"  "odt-styles"
>   In the first argument of `read', namely
>   `$(makeZip $ "data"  "odt-styles")'
>   In the expression: read ($(makeZip $ "data"  "odt-styles"))
>   In the definition of `refArchive':
>   refArchive = read ($(makeZip $ "data"  "odt-styles"))
> 
> The same problem occurs when making any call to Codec.Archive.Zip or
> Codec.Compression.Zlib.
> 
> I do have a universal zlib installed by MacPorts, as well as the
> universal zlib that shipped with Snow Leopard and the universal zlib
> that came with Cabal.  I'm not sure whether this message indicates
> that TH code is searching a different library path than non-TH code or
> what.  Advice is most welcome.  I'm particularly interested in finding
> out which zlib versions are being found at the construction of
> Codec.Compression.Zlib and at runtime (Pandoc compile time).
> 
> 
> 
> 
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard breaks GHC

2009-09-04 Thread Brian Sniffen 
Having edited the Haskell Platform's /usr/bin/ghc in place, most
packages install fine.  I'm still having trouble with Pandoc, even
given the advice:

> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
> may be used. These options may also be passed to "./Setup configure"

The problem appears to come when linking an incompatible zlib version:

src/Text/Pandoc/ODT.hs:49:26:
  Exception when trying to run compile-time code:
user error (Codec.Compression.Zlib: incompatible zlib version)
Code: ($) makeZip "data"  "odt-styles"
  In the first argument of `read', namely
  `$(makeZip $ "data"  "odt-styles")'
  In the expression: read ($(makeZip $ "data"  "odt-styles"))
  In the definition of `refArchive':
  refArchive = read ($(makeZip $ "data"  "odt-styles"))

The same problem occurs when making any call to Codec.Archive.Zip or
Codec.Compression.Zlib.

I do have a universal zlib installed by MacPorts, as well as the
universal zlib that shipped with Snow Leopard and the universal zlib
that came with Cabal.  I'm not sure whether this message indicates
that TH code is searching a different library path than non-TH code or
what.  Advice is most welcome.  I'm particularly interested in finding
out which zlib versions are being found at the construction of
Codec.Compression.Zlib and at runtime (Pandoc compile time).




-- 
Brian Sniffen
http://evenmere.org/~bts/

___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-09-03 Thread Christian Maeder 
It might help to add -optc-m32 -opta-m32 -optl-m32 to /usr/bin/ghci,
too. (TH uses ghci)

Cheers Christian

Brian Sniffen wrote:
> Having edit the Haskell Platform's /usr/bin/ghc in place, most
> packages install fine.  I'm still having trouble with Pandoc, even
> given the advice:
> 
>> Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
>> may be used. These options may also be passed to "./Setup configure"
> 
> The problem appears to come when linking an incompatible zlib version:
> 
> src/Text/Pandoc/ODT.hs:49:26:
> Exception when trying to run compile-time code:
>   user error (Codec.Compression.Zlib: incompatible zlib version)
>   Code: ($) makeZip "data"  "odt-styles"
> In the first argument of `read', namely
> `$(makeZip $ "data"  "odt-styles")'
> In the expression: read ($(makeZip $ "data"  "odt-styles"))
> In the definition of `refArchive':
> refArchive = read ($(makeZip $ "data"  "odt-styles"))
> 
> I do have a universal zlib installed by MacPorts, as well as the
> universal zlib that shipped with Snow Leopard and the universal zlib
> that came with Cabal.  I'm not sure whether this message indicates
> that TH code is searching a different library path than non-TH code or
> what.  Advice is most welcome.
> 
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-09-01 Thread Tom Tobin 
On Tue, Sep 1, 2009 at 3:14 AM, Christian
Maeder wrote:
>
> It seems, bootstrapping cabal went wrong. Does
> http://hackage.haskell.org/platform/2009.2.0.2/haskell-platform-2009.2.0.2-i386.dmg
> work?

Installing the Haskell Platform package, combined with adding the
previously mentioned options to /usr/bin/ghc (-optc-m32 -opta-m32
-optl-m32), seems to have done the trick.  Thank you!
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-09-01 Thread Christian Maeder 

It seems, bootstrapping cabal went wrong. Does
http://hackage.haskell.org/platform/2009.2.0.2/haskell-platform-2009.2.0.2-i386.dmg
work?

Once cabal works, options --ld-option=-m32 (and also --gcc-option=-m32)
may be used. These options may also be passed to "./Setup configure"

C.

Tom Tobin wrote:
> Hmm ... running Snow Leopard here, I added these arguments to my
> /usr/bin/ghc (and my /usr/bin/ghci, and /usr/bin/runhaskell, for good
> measure), and I end up getting the following error on "cabal update"
> after installing cabal-install:
> 
> *
> cabal: user error (Codec.Compression.Zlib: incompatible version)
> *
> 
> Earlier in the cabal-install bootstrap process, I get the following line:
> 
> *
> ld: warning: in
> /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/libgmp.a,
> file is not of required architecture
> *
> 
> I'm guessing something's still not being set to 32-bit?
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-08-31 Thread Tom Tobin 
On Mon, Aug 31, 2009 at 7:18 PM, Dmitri Sosnik wrote:
>
> On 31/08/2009, at 9:02 PM, Christian Maeder wrote:
>
>> Dmitri Sosnik wrote:
>>>
>>> How I can tell gcc to generate 32 bit code? I've tried to set
>>> CFLAGS=-m32, but it doesn't work.
>>
>> (Flags do not work -- without Makefile) Pass
>>
>
> Stupid me :-)
>
>> -optc-m32 -opta-m32 -optl-m32
>>
>
> Yep, it work. Thanks!

Hmm ... running Snow Leopard here, I added these arguments to my
/usr/bin/ghc (and my /usr/bin/ghci, and /usr/bin/runhaskell, for good
measure), and I end up getting the following error on "cabal update"
after installing cabal-install:

*
cabal: user error (Codec.Compression.Zlib: incompatible version)
*

Earlier in the cabal-install bootstrap process, I get the following line:

*
ld: warning: in
/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/libgmp.a,
file is not of required architecture
*

I'm guessing something's still not being set to 32-bit?
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-08-31 Thread Dmitri Sosnik 


On 31/08/2009, at 9:02 PM, Christian Maeder wrote:


Dmitri Sosnik wrote:

How I can tell gcc to generate 32 bit code? I've tried to set
CFLAGS=-m32, but it doesn't work.


(Flags do not work -- without Makefile) Pass



Stupid me :-)


-optc-m32 -opta-m32 -optl-m32



Yep, it work. Thanks!

Cheers,
D

___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-08-31 Thread David Leimbach 
That works here just fine.  Thanks!

On Mon, Aug 31, 2009 at 4:02 AM, Christian Maeder
wrote:

> Dmitri Sosnik wrote:
> > How I can tell gcc to generate 32 bit code? I've tried to set
> > CFLAGS=-m32, but it doesn't work.
>
> (Flags do not work -- without Makefile) Pass
>
>  -optc-m32 -opta-m32 -optl-m32
>
> through ghc (as pointed out before) for gcc, the assembler "as" and the
> linker "ld" resp. (I think, gcc is only used for -via-C)
>
> These options can be added to the script "/usr/local/bin/ghc" (if it was
> installed there).
>
> HTH Christian
>
> >
> > Cheers,
> > D
> >
> >
> > On 31/08/2009, at 12:06 AM, David Leimbach wrote:
> >
> >> Well the old binaries for Leopard already work on Snow Leopard.  The
> >> problem is the code generated by the GHC compiler doesn't create
> >> correct 64bit code when invoking gcc, and gcc on Snow Leopard defaults
> >> to 64bit code now.  The solution is to use -m32 in the invocation of
> >> gcc by default for Snow Leopard, or to make it emit correct 64bit code.
> >>
> >> Given all of the above, I don't think there's any "porting" work to be
> >> done.
> >>
> >> On Sun, Aug 30, 2009 at 2:22 AM, Dmitri Sosnik  >> > wrote:
> >>
> >> Hm, don't think so, you have to build for a new platform
> >> - http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
> >>
> >> D
> >>
> >>
> >> On 30/08/2009, at 2:10 AM, David Leimbach wrote:
> >>
> >>> Well if I build GHC on Leopard from HEAD and then copy it to Snow
> >>> Leopard would that not work?
> >>>
> >>> Dave
> >>>
> >>> On Sat, Aug 29, 2009 at 1:52 AM, Dmitri Sosnik  >>> > wrote:
> >>>
> >>> Here - http://hackage.haskell.org/trac/ghc/wiki/Building, but
> >>> it won't help, cause you need working ghc to build ghc.
> >>>
> >>> D
> >>>
> >>>
> >>> On 29/08/2009, at 6:33 PM, Thomas Davie wrote:
> >>>
> >>>
> >>> If it is closed, it is fixed in the HEAD.
> >>>
> >>>
> >>> Any ideas how to get hold of a copy of HEAD, when my
> >>> Haskell compiler currently outputs rubbish?
> >>>
> >>> Bob
> >>> ___
> >>> Haskell-Cafe mailing list
> >>> [email protected] 
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>>
> >>> ___
> >>> Haskell-Cafe mailing list
> >>> [email protected] 
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>>
> >>>
> >>
> >>
> >
> >
> > 
> >
> > ___
> > Haskell-Cafe mailing list
> > [email protected]
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Snow Leopard Breaks GHC

2009-08-31 Thread Christian Maeder 
Dmitri Sosnik wrote:
> How I can tell gcc to generate 32 bit code? I've tried to set
> CFLAGS=-m32, but it doesn't work.

(Flags do not work -- without Makefile) Pass

 -optc-m32 -opta-m32 -optl-m32

through ghc (as pointed out before) for gcc, the assembler "as" and the
linker "ld" resp. (I think, gcc is only used for -via-C)

These options can be added to the script "/usr/local/bin/ghc" (if it was
installed there).

HTH Christian

> 
> Cheers,
> D
> 
> 
> On 31/08/2009, at 12:06 AM, David Leimbach wrote:
> 
>> Well the old binaries for Leopard already work on Snow Leopard.  The
>> problem is the code generated by the GHC compiler doesn't create
>> correct 64bit code when invoking gcc, and gcc on Snow Leopard defaults
>> to 64bit code now.  The solution is to use -m32 in the invocation of
>> gcc by default for Snow Leopard, or to make it emit correct 64bit code.
>>
>> Given all of the above, I don't think there's any "porting" work to be
>> done.
>>
>> On Sun, Aug 30, 2009 at 2:22 AM, Dmitri Sosnik > > wrote:
>>
>> Hm, don't think so, you have to build for a new platform
>> - http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
>>
>> D
>>
>>
>> On 30/08/2009, at 2:10 AM, David Leimbach wrote:
>>
>>> Well if I build GHC on Leopard from HEAD and then copy it to Snow
>>> Leopard would that not work?
>>>
>>> Dave
>>>
>>> On Sat, Aug 29, 2009 at 1:52 AM, Dmitri Sosnik >> > wrote:
>>>
>>> Here - http://hackage.haskell.org/trac/ghc/wiki/Building, but
>>> it won't help, cause you need working ghc to build ghc.
>>>
>>> D
>>>
>>>
>>> On 29/08/2009, at 6:33 PM, Thomas Davie wrote:
>>>
>>>
>>> If it is closed, it is fixed in the HEAD.
>>>
>>>
>>> Any ideas how to get hold of a copy of HEAD, when my
>>> Haskell compiler currently outputs rubbish?
>>>
>>> Bob
>>> ___
>>> Haskell-Cafe mailing list
>>> [email protected] 
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>> ___
>>> Haskell-Cafe mailing list
>>> [email protected] 
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
> 
> 
> 
> 
> ___
> Haskell-Cafe mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe