Re: [Haskell-cafe] OS X ghci problem
The ghci bug goes away when you use a ghc head snapshot from late summer? Great! On Wednesday, September 18, 2013, Jan-Philip Loos wrote: > Sadly I was not able to use your build directly, because ghc(i) > searched libs in a invalid path (it seems to be wired to one of your > directories). I tried to build this ghc version from source on my own, > without success beyond stage 1. This [1] is related to the build > failure. I tried new alex and happy versions, without any change. A > naive approach was to compile alex/happy with ghc_stage1 compiler, > without success (as I expected due missing TH). I tried several ghc > versions for bootstrapping and alex/happy rebuilding (i guess ghc > > 7.6 is necessary for a valid 7.7 alex/happy build with the new Bool > primops), without success too. > > Finally I ended in a fully self build ghc 7.7.20130730 ([2]) and with > this ghc I can confirm that this specific error with > Binding.GLFW.c'glfwInit is gone :) Thanks > > [1] http://www.mail-archive.com/ghc-devs@haskell.org/msg02357.html > [2] > http://darcs.haskell.org/ghcBuilder/uploads/tn23/ghc-7.7.20130730-src.tar.bz2 > > On Mon, Sep 16, 2013 at 2:52 PM, Christiaan Baaij > > wrote: > > Here's a binary dist of my build: > https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2 > > In case someone wants to confirm my findings. > > > > Cheers, > > > > Christiaan > > > > On Sep 16, 2013, at 2:24 PM, Christiaan Baaij < > christiaan.ba...@gmail.com > wrote: > > > >> Hi, > >> > >> I saw the same issue/crash on my machine using ghc 7.6.3. > >> > >> I just build a "perf" build of GHC-head with > >> "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit. > >> > >> Now running, I get: > >> 1) > cabal install bindings-glfw > >> 2) > ghci > >> 3) ghci> :m Bindings.GLFW > >> 4) ghci> Bindings.GLFW.c'glfwInit > >> 5) ghci> 1 > >> > >> And doing: > >> 1.) > cabal install GLFW-b > >> 2.) > ghci -package GLFW-b > >> 3.) ghci> import Graphics.UI.GLFW as GLFW > >> 4.) ghci> GLFW.init > >> 5.) ghci> True > >> > >> My platform: > >> - OSX 10.8.4 > >> - ghc(i) 7.7.20130915 > >> - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) > >> - xcode cltools 4.6.2 > >> > >> So it seems that the new ghci linking infrastructure fixes things > >> > >> Cheers, > >> > >> Christiaan > >> > >> On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos > >> > > wrote: > >> > 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. > >>> > >>> Hi, > >>> for me the problem relocates now to the "bindings-glfw" package, since > >>> the native bindings moved to this package and are wrapped up with > >>> "glfw-b". > >>> > >>> My way to the same exception already mentioned by Brian Lewis: > >>> 1) > cabal install bindings-glfw > >>> 2) > ghci > >>> 3) ghci> :m Bindings.GLFW > >>> 4) ghci> Bindings.GLFW.c'glfwInit > >>> 5) ghci terminates with exception: *** Terminating app due to uncaught > >>> exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool > >>> init]: unrecognized selector sent to instance 0x7fc443c01b30' > >>> > >>> Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no > >>> clue how to do this. I built the according glfw version on my own as a > >>> dylib and loaded ghci with it explicitly, this didn't help. I guess > >>> the compiled bindings-glfw is already statically packed up. > >>> > >>> How can I get ghci to use the native glfw dylib in combination with > >>> bindings-glfw? If I have to compile bindings-glfw with different > >>> settings, which settings? I have some oversight over haskell but no > >>> really deep knowledge according to bindings and lib-loading of ghci, > >>> but I'm willing to learn it ;) > >>> > >>> My Platform: > >>> - OSX 10.8.5 > >>> - ghc(i) 7.6.3 > >>> - cabal 1.18.0.1 > >>> - xcode dev tools 4.6.3 > >>> > >>> Thanks and Greetings > >>> > >>> Jan > >>> ___ > >>> 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
Re: [Haskell-cafe] OS X ghci problem
Christian, Yes, ghc 7.7/7.8 *should* fix all the ghci linker related problems on platforms that support dynamic linking! If (or anyone else) finds problems with the ghci linker on 7.7, please report them post haste! I'm also glad to hear that someone's finally tested out the new ghci functionality properly! -Carter On Mon, Sep 16, 2013 at 8:52 AM, Christiaan Baaij < christiaan.ba...@gmail.com> wrote: > Here's a binary dist of my build: > https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2 > In case someone wants to confirm my findings. > > Cheers, > > Christiaan > > On Sep 16, 2013, at 2:24 PM, Christiaan Baaij > wrote: > > > Hi, > > > > I saw the same issue/crash on my machine using ghc 7.6.3. > > > > I just build a "perf" build of GHC-head with > > "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit. > > > > Now running, I get: > > 1) > cabal install bindings-glfw > > 2) > ghci > > 3) ghci> :m Bindings.GLFW > > 4) ghci> Bindings.GLFW.c'glfwInit > > 5) ghci> 1 > > > > And doing: > > 1.) > cabal install GLFW-b > > 2.) > ghci -package GLFW-b > > 3.) ghci> import Graphics.UI.GLFW as GLFW > > 4.) ghci> GLFW.init > > 5.) ghci> True > > > > My platform: > > - OSX 10.8.4 > > - ghc(i) 7.7.20130915 > > - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) > > - xcode cltools 4.6.2 > > > > So it seems that the new ghci linking infrastructure fixes things > > > > Cheers, > > > > Christiaan > > > > On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos wrote: > > > >>> 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. > >> > >> Hi, > >> for me the problem relocates now to the "bindings-glfw" package, since > >> the native bindings moved to this package and are wrapped up with > >> "glfw-b". > >> > >> My way to the same exception already mentioned by Brian Lewis: > >> 1) > cabal install bindings-glfw > >> 2) > ghci > >> 3) ghci> :m Bindings.GLFW > >> 4) ghci> Bindings.GLFW.c'glfwInit > >> 5) ghci terminates with exception: *** Terminating app due to uncaught > >> exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool > >> init]: unrecognized selector sent to instance 0x7fc443c01b30' > >> > >> Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no > >> clue how to do this. I built the according glfw version on my own as a > >> dylib and loaded ghci with it explicitly, this didn't help. I guess > >> the compiled bindings-glfw is already statically packed up. > >> > >> How can I get ghci to use the native glfw dylib in combination with > >> bindings-glfw? If I have to compile bindings-glfw with different > >> settings, which settings? I have some oversight over haskell but no > >> really deep knowledge according to bindings and lib-loading of ghci, > >> but I'm willing to learn it ;) > >> > >> My Platform: > >> - OSX 10.8.5 > >> - ghc(i) 7.6.3 > >> - cabal 1.18.0.1 > >> - xcode dev tools 4.6.3 > >> > >> Thanks and Greetings > >> > >> Jan > >> ___ > >> 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
Here's a binary dist of my build: https://www.dropbox.com/s/d37rij0dnvjiqqy/ghc-7.7.20130915-x86_64-apple-darwin.tar.bz2 In case someone wants to confirm my findings. Cheers, Christiaan On Sep 16, 2013, at 2:24 PM, Christiaan Baaij wrote: > Hi, > > I saw the same issue/crash on my machine using ghc 7.6.3. > > I just build a "perf" build of GHC-head with > "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit. > > Now running, I get: > 1) > cabal install bindings-glfw > 2) > ghci > 3) ghci> :m Bindings.GLFW > 4) ghci> Bindings.GLFW.c'glfwInit > 5) ghci> 1 > > And doing: > 1.) > cabal install GLFW-b > 2.) > ghci -package GLFW-b > 3.) ghci> import Graphics.UI.GLFW as GLFW > 4.) ghci> GLFW.init > 5.) ghci> True > > My platform: > - OSX 10.8.4 > - ghc(i) 7.7.20130915 > - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) > - xcode cltools 4.6.2 > > So it seems that the new ghci linking infrastructure fixes things > > Cheers, > > Christiaan > > On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos wrote: > >>> 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. >> >> Hi, >> for me the problem relocates now to the "bindings-glfw" package, since >> the native bindings moved to this package and are wrapped up with >> "glfw-b". >> >> My way to the same exception already mentioned by Brian Lewis: >> 1) > cabal install bindings-glfw >> 2) > ghci >> 3) ghci> :m Bindings.GLFW >> 4) ghci> Bindings.GLFW.c'glfwInit >> 5) ghci terminates with exception: *** Terminating app due to uncaught >> exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool >> init]: unrecognized selector sent to instance 0x7fc443c01b30' >> >> Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no >> clue how to do this. I built the according glfw version on my own as a >> dylib and loaded ghci with it explicitly, this didn't help. I guess >> the compiled bindings-glfw is already statically packed up. >> >> How can I get ghci to use the native glfw dylib in combination with >> bindings-glfw? If I have to compile bindings-glfw with different >> settings, which settings? I have some oversight over haskell but no >> really deep knowledge according to bindings and lib-loading of ghci, >> but I'm willing to learn it ;) >> >> My Platform: >> - OSX 10.8.5 >> - ghc(i) 7.6.3 >> - cabal 1.18.0.1 >> - xcode dev tools 4.6.3 >> >> Thanks and Greetings >> >> Jan >> ___ >> 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
Re: [Haskell-cafe] OS X ghci problem
Hi, I saw the same issue/crash on my machine using ghc 7.6.3. I just build a "perf" build of GHC-head with "85a9e2468dc74b9e5ccde0dd61be86219fd323a2" as the latest commit. Now running, I get: 1) > cabal install bindings-glfw 2) > ghci 3) ghci> :m Bindings.GLFW 4) ghci> Bindings.GLFW.c'glfwInit 5) ghci> 1 And doing: 1.) > cabal install GLFW-b 2.) > ghci -package GLFW-b 3.) ghci> import Graphics.UI.GLFW as GLFW 4.) ghci> GLFW.init 5.) ghci> True My platform: - OSX 10.8.4 - ghc(i) 7.7.20130915 - cabal 1.18.0.1 (using 1.18.0 of the Cabal library) - xcode cltools 4.6.2 So it seems that the new ghci linking infrastructure fixes things Cheers, Christiaan On Sep 14, 2013, at 9:00 PM, Jan-Philip Loos wrote: >> 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. > > Hi, > for me the problem relocates now to the "bindings-glfw" package, since > the native bindings moved to this package and are wrapped up with > "glfw-b". > > My way to the same exception already mentioned by Brian Lewis: > 1) > cabal install bindings-glfw > 2) > ghci > 3) ghci> :m Bindings.GLFW > 4) ghci> Bindings.GLFW.c'glfwInit > 5) ghci terminates with exception: *** Terminating app due to uncaught > exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool > init]: unrecognized selector sent to instance 0x7fc443c01b30' > > Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no > clue how to do this. I built the according glfw version on my own as a > dylib and loaded ghci with it explicitly, this didn't help. I guess > the compiled bindings-glfw is already statically packed up. > > How can I get ghci to use the native glfw dylib in combination with > bindings-glfw? If I have to compile bindings-glfw with different > settings, which settings? I have some oversight over haskell but no > really deep knowledge according to bindings and lib-loading of ghci, > but I'm willing to learn it ;) > > My Platform: > - OSX 10.8.5 > - ghc(i) 7.6.3 > - cabal 1.18.0.1 > - xcode dev tools 4.6.3 > > Thanks and Greetings > > Jan > ___ > 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
Re: [Haskell-cafe] OS X ghci problem
> 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. Hi, for me the problem relocates now to the "bindings-glfw" package, since the native bindings moved to this package and are wrapped up with "glfw-b". My way to the same exception already mentioned by Brian Lewis: 1) > cabal install bindings-glfw 2) > ghci 3) ghci> :m Bindings.GLFW 4) ghci> Bindings.GLFW.c'glfwInit 5) ghci terminates with exception: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSAutoreleasePool init]: unrecognized selector sent to instance 0x7fc443c01b30' Anthony Cowley mentioned to use ghci with GLFW as a dylib, I have no clue how to do this. I built the according glfw version on my own as a dylib and loaded ghci with it explicitly, this didn't help. I guess the compiled bindings-glfw is already statically packed up. How can I get ghci to use the native glfw dylib in combination with bindings-glfw? If I have to compile bindings-glfw with different settings, which settings? I have some oversight over haskell but no really deep knowledge according to bindings and lib-loading of ghci, but I'm willing to learn it ;) My Platform: - OSX 10.8.5 - ghc(i) 7.6.3 - cabal 1.18.0.1 - xcode dev tools 4.6.3 Thanks and Greetings Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
relatedly: johnW has nightly builds of GHC head for OS X 10.8 available for download for those who would be up for braving such experimentation ghc.newartisans.com On Sat, Jul 13, 2013 at 10:16 PM, Jason Dagit wrote: > On Sat, Jul 13, 2013 at 6:44 PM, Carter Schonwald > wrote: > > has anyone tried using ghci HEAD? If the problem is linker based... > perhaps > > ghci that uses the system Dylinker might resolve it? > > If someone gets brave and tries this I'd love to hear if it works. > Although, that's too new for something we hope most people can use. > I'm already feeling sheepish about requiring a minimum of 7.2.1 on OSX > (that was the first version that knew what to do with .m files). > > Jason > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
On Sat, Jul 13, 2013 at 6:44 PM, Carter Schonwald wrote: > has anyone tried using ghci HEAD? If the problem is linker based... perhaps > ghci that uses the system Dylinker might resolve it? If someone gets brave and tries this I'd love to hear if it works. Although, that's too new for something we hope most people can use. I'm already feeling sheepish about requiring a minimum of 7.2.1 on OSX (that was the first version that knew what to do with .m files). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
On Sat, Jul 13, 2013 at 5:32 PM, Anthony Cowley wrote: > On Jul 13, 2013, at 8:04 PM, Jason Dagit wrote: > >> On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner >> 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. Thanks. It hadn't occurred to me that the previous packaging had better success precisely because it built a dylib first. > 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? Yes, I wrote the Setup.hs/Makefile in the previous GLFW-b version that built glfw as a dylib. The problem is that Hackage no longer accepts that packaging because it doesn't like the extra-lib-dirs. Working around the (somewhat) arbitrary constraints that cabal/hackage imposes is rather annoying. There is no "trust me, this package works" option. It just assumes that a relative path in extra-lib-dirs can never work and rejects the package upload :( Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
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 wrote: > On Jul 13, 2013, at 8:04 PM, Jason Dagit wrote: > > > On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner > > 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
Re: [Haskell-cafe] OS X ghci problem
On Jul 13, 2013, at 8:04 PM, Jason Dagit wrote: > On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner > 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
Re: [Haskell-cafe] OS X ghci problem
On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner 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. What version of the xcode command line tools do you have? Anything older than 4.6.2 might have had the linker bugs I mention. On the other hand, I've tried with the latest version installed and it didn't help (probably because ghci doesn't use it). 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
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. 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. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
