OS X ghci problem - Haskell-Cafe - Haskell.org

newer
Re: [Haskell-cafe] Deriving with...

OS X ghci problem

older
build failure on Hackage

Brian Lewis

12 Jul 2013 12 Jul '13

12:31 a.m.

Here's a problem variations of which have been plaguing the Haskell community for as long as I can remember. To see it for yourself: 1.) Be running OS X 2.) install GLFW-b-1.0.0 (you may need to cabal update) [1] 3.) ghci -package GLFW-b 4.) import Graphics.UI.GLFW as GLFW 5.) GLFW.init Security camera footage of the crime in progress: https://gist.github.com/dagit/5980438/raw/2e92a63135008921040478566e56ac7c05... One of the first things GLFW.init does on OS X is ... = [[NSAutoreleasePool alloc] init]; That causes -[NSAutoreleasePool init]: unrecognized selector sent to instance ... which seems to mean that NSAutoreleasePool doesn't understand the "init" message/method. But [[NSAutoreleasePool alloc] init] is really basic stuff. What is going on? [1]: http://hackage.haskell.org/package/GLFW-b

Reply

Sign in to reply online Use email software

Show replies by date

Mark Lentczner

13 Jul 13 Jul

7:39 p.m.

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

Reply

Sign in to reply online Use email software

Jason Dagit

8:04 p.m.

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

Reply

Sign in to reply online Use email software

Anthony Cowley

8:32 p.m.

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

Reply

Sign in to reply online Use email software

Carter Schonwald

9:44 p.m.

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

Reply

Sign in to reply online Use email software

Jason Dagit

10:16 p.m.

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

Reply

Sign in to reply online Use email software

Carter Schonwald

14 Jul 14 Jul

2:02 a.m.

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:

...
has anyone tried using ghci HEAD? If the problem is linker based...

On Sat, Jul 13, 2013 at 6:44 PM, Carter Schonwald wrote: 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

Reply

Sign in to reply online Use email software

Jason Dagit

13 Jul 13 Jul

10:13 p.m.

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

Reply

Sign in to reply online Use email software

4333

Age (days ago)

4335

Last active (days ago)

Download

7 comments

5 participants

tags

participants (5)

Anthony Cowley
Brian Lewis
Carter Schonwald
Jason Dagit
Mark Lentczner