[Haskell-cafe] OS X ghci problem

[Carter Schonwald]

has anyone tried using ghci HEAD? If the problem is linker based... perhaps
ghci that uses the system Dylinker might resolve it?

-Carter


On Sat, Jul 13, 2013 at 8:32 PM, Anthony Cowley <acowley at gmail.com> wrote:

> On Jul 13, 2013, at 8:04 PM, Jason Dagit <dagitj at gmail.com> wrote:
>
> > On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner
> > <mark.lentczner at gmail.com> wrote:
> >> Bizarre - this just happened to me today, too. Anyone? Did you figure
> out a
> >> work around? For the record, I'm trying to bring Euterpea up.
> >
> > After some digging, experimenting, asking around, and head scratching
> > my best guesses are:
> >
> >  * GHCi's custom linker isn't doing the right thing (some versions of
> > llvm/clang gave crashes like this and it was a linker bug for them,
> > you can find reports on sites like StackOverflow).
> >  * We need to feed .m files to clang instead of ghc/gcc
> >  * GHCi needs to be built with Cocoa in mind (is it already?)
> >  * Some rts component of objective-c is not properly initialized (ARC
> > vs. -fobjc-gc vs. -fnext-step, etc)
> >
> >>
> >> My system is OS X 10.8.4, and I'm running HP 2013.2, so 7.6.3. And
> >> GLFW-0.5.1.0.
> >
> > In terms of experimentation, you can hand desugar the objective-c code
> > in the GLFW init and when I do that I get segfaults. Also, the address
> > mentioned in the objective-c exception has a suspicious value, which
> > would further implicate the linker. Add to that, it works for a
> > compile program (which uses the system linker, IIRC).
> >
> > Basically, I'm pretty sure it's GHCi's linker to blame here but I
> > don't have a smoking gun.
> >
> > Jason
>
> I thought I'd had some success desugaring the Objective-C code, but I
> never went the whole way, so perhaps I just didn't get to the segfault.
> What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish
> linker. The only wrinkle is figuring out where you want the dylib. I think
> homebrew will put one in /usr/local/lib, which works out nicely, but they
> don't have GLFW 3 yet. Another option is to build the dylib yourself from
> the GLFW source bundled with the GLFW-b package, then tell cabal where to
> find it.
>
> It's worth the trouble, as having a GHCi-based workflow for graphics work
> is wonderful. A fancy Setup.hs that works out installation paths could
> generate the dylib, and I thought such code existed in the past. Was some
> problem found with that approach?
>
> Anthony
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130713/04e2ab18/attachment.htm>