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 <acow...@gmail.com> wrote: > On Jul 13, 2013, at 8:04 PM, Jason Dagit <dag...@gmail.com> wrote: > > > On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner > > <mark.lentcz...@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@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
