Re: [Haskell-cafe] Re: Snow Leopard Breaks GHC
Tom Tobin korp...@korpios.com writes:
On Tue, Sep 1, 2009 at 3:14 AM, Christian
Maederchristian.mae...@dfki.de 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 g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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
christian.mae...@dfki.de 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
christian.mae...@dfki.de 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/
b...@evenmere.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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
christian.mae...@dfki.de 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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/ b...@evenmere.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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
christian.mae...@dfki.de 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/
b...@evenmere.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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
christian.mae...@dfki.de 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard breaks GHC
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
christian.mae...@dfki.de 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Snow Leopard breaks GHC
On Fri, Sep 4, 2009 at 10:38 AM, Christian Maederchristian.mae...@dfki.de wrote: Or runghc form /usr/bin? /usr/bin/runghc is a symlink to the same file as runhaskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard Breaks GHC
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard Breaks GHC
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard Breaks GHC
On Tue, Sep 1, 2009 at 3:14 AM, Christian Maederchristian.mae...@dfki.de 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard Breaks GHC
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 dim...@gmail.com mailto:dim...@gmail.com 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 dim...@gmail.com mailto:dim...@gmail.com 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 Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard Breaks GHC
That works here just fine. Thanks! On Mon, Aug 31, 2009 at 4:02 AM, Christian Maeder christian.mae...@dfki.dewrote: 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 dim...@gmail.com mailto:dim...@gmail.com 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 dim...@gmail.com mailto:dim...@gmail.com 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 Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Snow Leopard Breaks GHC
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Snow Leopard Breaks GHC
On Mon, Aug 31, 2009 at 7:18 PM, Dmitri Sosnikdim...@gmail.com 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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
