On Sat, Jul 13, 2013 at 5: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-
>> 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 :(


Haskell-Cafe mailing list

Reply via email to