[Haskell-cafe] OSX, ghci, dylib, what is the correct way?

[Raeez Lorgat]

If anyone is curious, I've posted a possible solution at the stack
overflow post:

http://stackoverflow.com/questions/6323755/osx-ghci-dylib-what-is-the-correct-way/6439016#6439016

I'd appreciate any feedback (and/or refutations), especially regarding
the commentary re: ghci and loading static archives.

Excerpts from Simon Marlow's message of Wed Jun 15 16:55:05 +0200 2011:
> On 15/06/2011 15:41, Jason Dagit wrote:
> > On Wed, Jun 15, 2011 at 2:16 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
> >> On 14/06/2011 17:57, Jason Dagit wrote:
> >>>
> >>> On Tue, Jun 14, 2011 at 4:26 AM, Simon Marlow<marlowsd at gmail.com>    wrote:
> >>>>
> >>>> On 12/06/2011 20:17, Jason Dagit wrote:
> >>>>>
> >>>>> On Sun, Jun 12, 2011 at 11:45 AM, Brandon Allbery<allbery.b at gmail.com>
> >>>>>   wrote:
> >>>>>>
> >>>>>> On Sun, Jun 12, 2011 at 14:31, Jason Dagit<dagitj at gmail.com>      wrote:
> >>>>>>>
> >>>>>>> If I build the C library as a .a, then ghci comlains that it cannot
> >>>>>>> open the .dylib.  My first question is: Why does ghci need a .dylib
> >>>>>>> and does it really use it?
> >>>>>>
> >>>>>> Static libraries are... static.  ghci would have to rebuild itself
> >>>>>> against the static archive to use it; that's how static archives work.
> >>>>>>   Dynamic libraries are dynamic because they can be loaded at runtime
> >>>>>> instead of compile time.
> >>>>>
> >>>>> Interesting.  When I use dtruss to see what files ghci opens, it
> >>>>> definitely opens .a files.  That gave me the impression it knows how
> >>>>> to open a .a and use it at run-time.
> >>>>
> >>>> GHC as of version 7.0 can load .a files into GHCi.
> >>>>
> >>>>>>> When I build a dylib I get a [segfault when loading the code into
> >>>>>>> ghci][2].
> >>>>
> >>>> I don't know what the cause of that is - when you load a .dylib into
> >>>> GHCi,
> >>>> the normal system dynamic linker is used.
> >>>
> >>> How would you track it down?  I'd really like to fix this and I don't
> >>> mind debugging it, but I've tried all the things I could think of
> >>> (valgrind, dtruss, gdb and printf).  Valgrind didn't help because ghci
> >>> couldn't read from stdin.  gdb isn't so great because I was missing
> >>> debug symbols for everything.
> >>>
> >>> I don't really believe it is an error in the RTS or the library code
> >>> so it seems like gdb won't ever help here.
> >>>
> >>> Ideas?
> >>
> >> Can you build a simple .dylib, load it into GHCi and call it from Haskell?
> >>   If that works, then see if you can gradually evolve the tiny example
> >> towards the real failure case and see at which point it fails.
> >
> > I can try this.  I was hesitant to go down that road simply because
> > this dylib does work if I remove the memset and any code that writes
> > to that area of memory.
> >
> >> Can you build GHC yourself?  If so, you can link GHC with -debug, and that
> >> will give you access to the debugging output from the linker (+RTS -Dl) and
> >> gdb will have source information about the RTS.
> >
> > Building GHC myself is no problem.  I usually do that on OSX anyway so
> > that I can link with iconv from macports.  This is the first time I've
> > used the Haskell Platform version of GHC on osx.
> >
> >
> >> I don't know who is generating those messages about "Reading symbols for
> >> shared libraries ...", or the ones about "Could not find object file", maybe
> >> those are generated by the system linker?
> >
> > I'm 99% sure those are from GDB.  I don't see them unless I run ghci inside gdb.
> >
> >> Did you compile the source files with -fPIC? (I presume that's necessary,
> >> but I don't know much about OS X).
> >
> > I've tried with each -fPIC and -fno-common.  The makefile I use is
> > linked in the original question, but here is the link again incase you
> > want to look at it:
> > https://github.com/dagit/GLFW-b/blob/master/Makefile
> >
> > The current flag configuration matches what is in the git repo for
> > GLFW.  When I tried with -fPIC I didn't notice any difference.
> 
> The symptoms don't look quite right, but I wonder if it is related to 
> this at all?
> 
>    http://hackage.haskell.org/trac/ghc/ticket/781
> 
> Cheers,
>     Simon
>