Re: hsc2hs on Mac OS 10.6 unreliable?

2010-06-09 Thread Max Bolingbroke
On 8 June 2010 22:03, Axel Simon axel.si...@in.tum.de wrote:
 The offsets that hsc2hs calculates are too large, so it is probably in
 x86_64 mode.

Is it just this problem: http://hackage.haskell.org/trac/ghc/ticket/3400

If you use an older GHC you will need to manually patch the hsc2hs
script to pass the right command line options.

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


Re: hsc2hs on Mac OS 10.6 unreliable?

2010-06-09 Thread Chris Kuklewicz
The story on OS X 10.6 with ghc-6.12 on x86 hardware seems to be this:

Apple's gcc: Defaults to i386 or ppc on Mac OS X 10.5 and earlier,
depending on the CPU type detected at runtime. On Mac OS X 10.6 the
default is x86_64 if the CPU supports it, i386 otherwise. Passing -arch
i386 or -arch x86_64 explicitly chooses the mode explicitly.  Passing
BOTH -arch i386 AND -arch x86_64 creates something special which is a
universal binary that holds both versions in a single file.

MacPorts: The provides an easy way to compile and install a plethora of
mostly unix-y software from source.  It handles the arch problem by
allowing +universal to be specified when installing a package or set by
default in /opt/local/etc/macports/variants.conf, which is what I have
done.  Without +universal the default arch can be specified in
/opt/local/etc/macports/macports.conf.

gtk: I have build gtk2-2.20.1 with macports as a universal library.

ghc: Unlike ghc on Linux, ghc on OS X is not capable of creating x86_64
libraries and programs.  Using ghc before 6.12 on OS X 10.6 used to
require some small option hacks to explicitly set -arch i386.  Now ghc
is invoked directly. ( http://hackage.haskell.org/trac/ghc/ticket/2965 )

hsc2hs: On OS 10.6 ghc is calling hsc2hs without any special -arch
option, and hsc2hs is calculating offsets in x86_64 mode.  This is
breaking the interface between ghc and c-structures for various
libraries.  In particular I ran into this with gtk2hs.

It may suffice to get '--cc-flag=-m32 --ld-flag=-m32' to hsc2hs as a
work around.  While ticket #2965 is not yet fixed it would be better if
hsc2hs understood the default arch on OS X 10.6 is not compatible with ghc.

-- 
Chris


On 08/06/2010 22:03, Axel Simon wrote:
 Hi all,
 
 we're facing serious problems (the seg'faulting kind) with Gtk2Hs on Mac
 OS 10.6. Chris has tracked this down to incorrect structure offsets that
 hsc2hs calculates.
 
 The offsets that hsc2hs calculates are too large, so it is probably in
 x86_64 mode. The offsets with which Gtk+ was compiled are smaller, so it
 must have been compiled with something like -arch i386. My question is
 the following: What is the right way to compile unixy software on Mac OS
 10.6. Is the Gtk+ library incorrectly compiled or is hsc2hs not
 producing its C file in the correct way? It seems that a C Gtk+ program
 works correctly when compiled with no special flags.
 
 The only thing we could do is to pass some magic option to hsc2hs when
 it creates the C program that calculates the offsets. Detecting how Gtk+
 was compiled would require some sort of autoconf magic which is beyond a
 simple cabal file. So I probably cannot hope for an easy fix.
 
 Any comments or experience appreciated,
 cheers,
 Axel
 
 

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


Re: hsc2hs on Mac OS 10.6 unreliable?

2010-06-09 Thread Christian Maeder
Chris Kuklewicz schrieb:
 hsc2hs: On OS 10.6 ghc is calling hsc2hs without any special -arch
 option, and hsc2hs is calculating offsets in x86_64 mode.  This is
 breaking the interface between ghc and c-structures for various
 libraries.  In particular I ran into this with gtk2hs.
 
 It may suffice to get '--cc-flag=-m32 --ld-flag=-m32' to hsc2hs as a
 work around.  While ticket #2965 is not yet fixed it would be better if
 hsc2hs understood the default arch on OS X 10.6 is not compatible with ghc.

Sorry, I'm only on a 32bit Mac, but my (installed) hsc2hs (for
ghc-6.12.2.20100521) file contains:

HSC2HS_EXTRA=--cflag=-m32 --lflag=-m32 -I...

Is this not sufficient for 64bit Macs, too?

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


Re: hsc2hs on Mac OS 10.6 unreliable?

2010-06-09 Thread Axel Simon

Hi Christian,

On 09.06.2010, at 10:30, Christian Maeder wrote:


Chris Kuklewicz schrieb:

hsc2hs: On OS 10.6 ghc is calling hsc2hs without any special -arch
option, and hsc2hs is calculating offsets in x86_64 mode.  This is
breaking the interface between ghc and c-structures for various
libraries.  In particular I ran into this with gtk2hs.

It may suffice to get '--cc-flag=-m32 --ld-flag=-m32' to hsc2hs as a
work around.  While ticket #2965 is not yet fixed it would be  
better if
hsc2hs understood the default arch on OS X 10.6 is not compatible  
with ghc.


Sorry, I'm only on a 32bit Mac, but my (installed) hsc2hs (for
ghc-6.12.2.20100521) file contains:

HSC2HS_EXTRA=--cflag=-m32 --lflag=-m32 -I...

Is this not sufficient for 64bit Macs, too?


I guess it would be enough, but obiously ghc or cabal should do this  
correctly themselves.


What I would like to get out of this email thread is a set of rules  
that allows me to hack around this issue.


So far:

if os(darwin)  arch(x86_64)  impl(ghc =6.10 =6.12)
  cpp-options: -DHSC2HS_EXTRA=--cflag=-m32 --lflag=-m32

(although I'm not even sure the above works).

Is the above rule correct and future-proof?

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


Re: hsc2hs on Mac OS 10.6 unreliable?

2010-06-09 Thread Chris Kuklewicz
That was in the official hsc2hc binary but was commented out in my
macports hsc2hs.  I have uncommented the line and rebuilt a working gtk2hs.

Thanks!

On 09/06/2010 09:30, Christian Maeder wrote:
 Chris Kuklewicz schrieb:
 hsc2hs: On OS 10.6 ghc is calling hsc2hs without any special -arch
 option, and hsc2hs is calculating offsets in x86_64 mode.  This is
 breaking the interface between ghc and c-structures for various
 libraries.  In particular I ran into this with gtk2hs.

 It may suffice to get '--cc-flag=-m32 --ld-flag=-m32' to hsc2hs as a
 work around.  While ticket #2965 is not yet fixed it would be better if
 hsc2hs understood the default arch on OS X 10.6 is not compatible with ghc.
 
 Sorry, I'm only on a 32bit Mac, but my (installed) hsc2hs (for
 ghc-6.12.2.20100521) file contains:
 
 HSC2HS_EXTRA=--cflag=-m32 --lflag=-m32 -I...
 
 Is this not sufficient for 64bit Macs, too?
 
 Cheers Christian

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


hsc2hs on Mac OS 10.6 unreliable?

2010-06-08 Thread Axel Simon

Hi all,

we're facing serious problems (the seg'faulting kind) with Gtk2Hs on  
Mac OS 10.6. Chris has tracked this down to incorrect structure  
offsets that hsc2hs calculates.


The offsets that hsc2hs calculates are too large, so it is probably in  
x86_64 mode. The offsets with which Gtk+ was compiled are smaller, so  
it must have been compiled with something like -arch i386. My question  
is the following: What is the right way to compile unixy software on  
Mac OS 10.6. Is the Gtk+ library incorrectly compiled or is hsc2hs not  
producing its C file in the correct way? It seems that a C Gtk+  
program works correctly when compiled with no special flags.


The only thing we could do is to pass some magic option to hsc2hs when  
it creates the C program that calculates the offsets. Detecting how Gtk 
+ was compiled would require some sort of autoconf magic which is  
beyond a simple cabal file. So I probably cannot hope for an easy fix.


Any comments or experience appreciated,
cheers,
Axel


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